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.

Just update packages to the latest, patched version. What so difficult about it?

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.

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.

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.

You wipe the disk and install OpenBSD.

Good idea, but completely beside the point.

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.

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

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.

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.

Or you could just get an iPad.

There are other ways to update software..

Riiight, 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.

I'm far from a security expert.

I have spent hundreds if not thousands of hours upgrading random packages in Linux for various reasons. Afterwards, I didn't feel any wiser in security or anything except how to build stuff (well, maybe a bit of systems stuff...).

If upgrading is main task here, what do you really learn? If upgrading isn't the main task here, what is?

Not update, but upgrade to another more secure distribution.

Or 4chan.

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

Wait, they topped Windows 95 and Windows ME?

Is that even possible?

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.

You 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

Technically speaking, how would an OS avoid that issue, without breaking compatibility (unless that is acceptable)?

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.

Sure you can—just let them stomp all over a virtualized processor/memory space.

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)

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.

What's the (efficient) alternative?

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.

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..

I would say that not writing code that requires this. Only valid reason for wrapping something in CLI/STI is when you want to directly control some timing-critical hardware, which is something that simply does not belong into userspace. I would say that in most cases such code does not even belong to kernel, but into some interface controller of said hardware. Other cases are pretty well handled by normal APIs presented by kernel (mutexes, signal flags...).

Any OS on that early hardware had this problem, right?

That actually sounds like a fun concept.

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.

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?

Refer to popular wargames. You could start here: http://www.smashthestack.org

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.

/dvl ;)

an actual distribution

It looks like a honeypot on steroids!

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

http://en.wikipedia.org/wiki/Openbsd is the most secure OS.