6 ms·
Damn Vulnerable Linux - The most vulnerable and exploitable distro
- sliverstorm 16y ago> Damn Vulnerable Linux - The most vulnerable and exploitable operating system ever! Wait, they topped Windows 95 and Windows ME? Is that even possible?
- pjscott 16y agoI love how, on those OSes, you could freeze the whole thing solid with a three-byte program: cli # clears interrupts loop: goto loop This ballooned to a colossal four bytes if you put it in an EXE file, of course.
- yesimahuman 16y agoTechnically speaking, how would an OS avoid that issue, without breaking compatibility (unless that is acceptable)?
- mahmud 16y agoYou can't be bug compatible for things that violate the processor's protection protocol. Access to certain bits of the EFLAGS register is unavailable to unprivileged code. In fact. Just because you were allowed to raid and pillage by Microsoft for a few years doesn't mean it's the norm.
- derefr 16y agoSure you can—just let them stomp all over a virtualized processor/memory space.
- dfox 16y agoYou cannot meaningfully virtualize access to EFLAGS:IF. You can either emulate(/JIT) almost whole CPU or ignore this issue. And anyway, turning of interrupts is something that essentially does not make sense for user process, so it is better to just disallow that (which is what almost everything else but non-NT windows does)
- JoeAltmaier 16y agoIt was usually used as an ultra- critical section. It would have been fine to simulate it as a scheduler-freeze for that process, preserving the meaning without getting hung up on the hardware implementation. But instead, Intel decided to try to support actually messing with the interrupt enable state, resulting in years of highly-inefficient "solutions" e.g. trapping and simulating. Sigh.
- mfukar 16y agoWhat's the (efficient) alternative?
- JoeAltmaier 16y agoA big-hammer approach is to set thread affinity for your process to one hyperthread/processor. But that loses the opportunity for lovely parallelism. A finer-grained approach is to have a flag bit that prevents preemption, perhaps even just preemption by threads of the same process. This is weaker than CLI because it doesn't prevent I/O callbacks etc from preempting; ideally those would be suspended as well for the process. This assume a non-priviledge flag word i.e. user-mode code owns the "process flags", not the kernel. My favorite solution is a "process signal register" in hardware. Its a wide register full of test-and-set bits, shared by threads of a process. They can be used to implement critical section, semaphore, event, even waiting on a timer. All without a trip thru the kernel - essentially zero-latency kernel primitives.
- mfukar 16y agoWouldn't an unprivileged EFLAGS-lookalike cause problems of the CLI-HLT persuasion? And "process signal registers", while sounding attractive, aren't really a feasible alternative, given that the number of processes running even on uniprocessors are overwhelming, at least. Plus, if they're beyond CPU control, privilege issues arise again. In short, yes, there are many alternatives, but the current model works, and not just for x86. And you know what engineers say..
- mahmud 16y agoYou could do it from debug.com but that one doesn't have labels, so you will need to use an explicit jmp. C:\hack\lisp\cl-gdata\base>debug -a 13EA:0100 cli 13EA:0101 jmp 101 13EA:0103 -g 0100
- JoeAltmaier 16y agoAny OS on that early hardware had this problem, right?
- wwortiz 16y agoThat actually sounds like a fun concept.
- morazyx 16y agoSeems a decent educational tool too.. run in a virtual box and let your students go all out overflowing buffers and seeing the concepts in action. It comes with easy-to-follow guides.
- JoeAltmaier 16y agoOK for learning about what has been solved; kind of hacking-101. BUt the exploits involved have all been fixed in the products in that distro. What to use for the advanced class?
- nsfmc 16y agoan actual distribution
- mfukar 16y agoRefer to popular wargames. You could start here: http://www.smashthestack.org http://www.smashthestack.org
- datamonk 16y agoi have it on my VM, can someone point me to where these guides are? KDE confuses me :). i will RTFM, I just need to find it first. thanks.
- morazyx 16y ago/dvl ;)
- JoeAltmaier 16y agoOK for learning about what has been solved; kind of hacking-101. BUt the exploits involved have all been fixed in the products in that distro. What to use for the advanced class?
- mahmud 16y agoSecuring this beast should serve as a nice training course for any sysadmin; bonus points if you start handing out shell accounts to anonymous people in certain neighborhoods of EFNet.
- pavs 16y agoJust update packages to the latest, patched version. What so difficult about it?
- mahmud 16y agoIf this is based on a popular distro, maybe; but if you wanted to loosen up a Linux box, you can build a freak from pieces that no one would find lineage for, much less a repo.
- milkshakes 16y agoThere are other ways to update software..
- mahmud 16y agoRiiight, downloading individual packages, libraries and kernels and building them from source. Which is why I thought it would be a good exercise, however very boring. Running a Bastille script on the box would give you a quick TODO list. Pushing it to "production" and getting a few servers up and running, across version incompatibilities, would prove a bit more interesting. Running it under an older 2.4.x or 2.2.x kernel, doubly so.
- pavs 16y agoumm no. He specifically mentions that all the softwares are vulnerable: "Its developers have spent hours stuffing it with broken, ill-configured, outdated, and exploitable software that makes it vulnerable to attacks." Just replace them with the latest, patched, default configured version.
- known 16y agohttp://en.wikipedia.org/wiki/Openbsd http://en.wikipedia.org/wiki/Openbsd is the most secure OS.
- nhnifong 16y agoWhats with all the grammatical errors on that site? Is it a joke?