h a l f b a k e r ySee website for details.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Many worms and other such malware programs rely upon using buffer overflows to overwrite key data structures. An essential part of such programs' operation is the ability to arrange things so that the overflowing data hits the key data structures in a predictable way. Although random overwriting can
easily be used to cause a crash, making the target machine run the malfactor's code requires that the overwriting be very precisely calculated.
I would propose that adding some randomly variation to certain memory allocation algorithms would make it much more difficult for a malefactor to predict exactly how buffer-overrun data must be placed for any given target. Because an incorrectly-figured buffer-overrun attempt would likely crash the 'victim' process, hackers may not be able to simply try random attacks until something works.<p>
Very simple OS change, but I would think it might reduce the spread of certain types of malware considerably.
(?) Bhatkar, DuVarney, Sekar: Address Obfuscation
http://www.seclab.c...s03-html/index.html
An Efficent Approach to Combat a Broad Range of Memory Error Exploits [jutta, Oct 04 2004, last modified Oct 05 2004]
Address Space Layout Randomization (ASLR)
http://pax.grsecurity.net/docs/aslr.txt
Part of a GPL'ed add-on to a linux kernel. [jutta, Oct 04 2004, last modified Oct 05 2004]
(?) Transparent Runtime Randomization (TRR)
http://www.crhc.uiu...S2003_final_trr.pdf
[jutta, Oct 04 2004, last modified Oct 05 2004]
(?) Operating System Randomization
http://www.cs.berke.../~mmc/papers/tr.pdf
[jutta, Oct 04 2004, last modified Oct 05 2004]
(?) Building Diverse Computer Systems
www.cs.unm.edu/~imm...ations/hotos-97.pdf
The code-level (as opposed to os-level) version of the idea - shuffle and vary code in ways that don't affect functionality. [jutta, Oct 04 2004, last modified Oct 05 2004]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
I'm not sure what data structures you mean. Buffer overruns typically work because the storage for local variables (eg strings) sits within the executable code of the program that uses them. If the original program code is badly written, a virus can input a much longer string than the storage can accomodate without the program noticing and truncating it automatically. The string thus runs past the boundary of its original allocation and overwrites the executable code of the program. By itself, this doesn't transfer control to the virus but the host program continues to run and eventually it attempts to execute the overwritten code. Whereupon, the virus can do pretty much what it wants. |
|
| |
The point is that all of this is done without the virus knowing where, in absolute terms, it is loaded. It is all relative to the start of the host program. |
|
| |
[gravelpit] Keeping the buffer with the code can make the system more vulnerable, but any tidy structure where the order of data in memory is known is vulnerable to buffer overrun. I agree with [sc] that inserting random sized gaps would make it harder to exploit buffer overruns. |
|
| |
While we are at it we should also randomize disk structure. Having the master boot sector always in the same place is asking for trouble. User should have to enter the location of the master boot sector when the computer boots. |
|
| |
//Very simple OS change// Have you lost your mind? This is a lot of things, but simple, it ain't. |
|
| |
Good idea (I know, because I came up with it, too). There's been quite some work in the area; a bunch of papers on different versions of the technique, and, of course, a linux kernel add-on. Have some links. |
|
| |
But this really doesn't fix anything, does it? I mean, instead of crashing/compromising a particular application reliably, you're now crashing/compromising any application that might store data or code in the overrun memory area. If the heap is well managed it might still only take out the target application, but there's no guarantee. Also, what's the overhead for a process like this? |
|
| |
It makes more sense to me to simply avoid software with know vulnerabilities. Error checking is tedious, but it's not that hard... |
|
| |
[phoenix] With the layer upon layer upon layer of code that you have these days I don't think time is an issue. I browsed through [jutta]'s links and seems to be plain negligence. |
|
| |
I'll probably delete this since it seems to have already been proposed, though I wonder why I've not heard of OS patches for Windows since it would seem a fairly straightforward patch. Although it's not good to leave programs open to targetted crashing (which they still would be), a system which can be capriciously crashed does not pose nearly as much danger to other systems as one that can made to run a worm. |
|
| |
It's been done for linux. |
|
| |