Damn Vulnerable Linux - The most vulnerable and exploitable distro(damnvulnerablelinux.org) |
Damn Vulnerable Linux - The most vulnerable and exploitable distro(damnvulnerablelinux.org) |
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?
Wait, they topped Windows 95 and Windows ME?
Is that even possible?
cli # clears interrupts
loop: goto loop
C:\hack\lisp\cl-gdata\base>debug
-a
13EA:0100 cli
13EA:0101 jmp 101
13EA:0103
-g 0100He 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.
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.
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.
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.
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..