
Damn Vulnerable Linux - The most vulnerable and exploitable distro - morazyx
http://www.damnvulnerablelinux.org/
======
mahmud
Securing 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
Just update packages to the latest, patched version. What so difficult about
it?

~~~
mahmud
If 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.

~~~
pavs
umm 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.

~~~
btilly
What pieces of software do you replace? How do you replace it? Remember that
it likely doesn't some with anything like apt to make this easy.

~~~
kaens
You wipe the disk and install OpenBSD.

~~~
mahmud
Good idea, but completely beside the point.

~~~
davidw
Why sit around replacing packages by hand when you're not really learning
anything? The best fix for a system like this is to nuke it from orbit and
reinstall. I mean, odds are, you'll miss something, and then spent hours
fooling around after getting hacked, when you could have just spent your time
concentrating on what's important: saving relevant data and configuration,
reinstalling, and securing the updated configuration.

~~~
rick_2047
This is a course in security and thats why the comment is completely beside
the point.

~~~
davidw
The important point, which I did miss, is that it's not just a "security
course", it's a course about how to break into things, so you need vulnerable
programs. If you're not specializing in security stuff, the best course of
action, is, however, to just keep your stuff up to date via apt or some
similar mechanism.

~~~
steveklabnik
But in order to properly understand what you could be vulnerable to and the
why/how, you should learn how to break into things. Yes, normally, you're
working at a higher level of abstraction, but if you want to understand how
things really work, you work at a lower level for a while.

------
sliverstorm
> Damn Vulnerable Linux - The most vulnerable and exploitable operating system
> ever!

Wait, they topped Windows 95 and Windows ME?

Is that even possible?

~~~
pjscott
I 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
Technically speaking, how would an OS avoid that issue, without breaking
compatibility (unless that is acceptable)?

~~~
mahmud
You 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
Sure you can—just let them stomp all over a _virtualized_ processor/memory
space.

~~~
dfox
You 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
It 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
What's the (efficient) alternative?

~~~
JoeAltmaier
A 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
Wouldn'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..

------
wwortiz
That actually sounds like a fun concept.

~~~
morazyx
Seems 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
OK 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?

~~~
datamonk
i 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
/dvl ;)

------
nhnifong
Whats with all the grammatical errors on that site? Is it a joke?

------
known
<http://en.wikipedia.org/wiki/Openbsd> is the most secure OS.

