Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
0.5 and holding.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                             

Memory address randomizer

Randomly very addresses of data structures at load time
 
(0)
  [vote for,
against]

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.

supercat, Jun 27 2004

(?) 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]

[link]






       vary?
po, Jun 27 2004
  

       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, Jun 27 2004
  

       [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.
kbecker, Jun 27 2004
  

       //Very simple OS change// Have you lost your mind? This is a lot of things, but simple, it ain't.
zigness, Jun 27 2004
  

       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.
jutta, Jun 27 2004
  

       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, Jun 27 2004
  

       [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.
kbecker, Jun 27 2004
  

       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.
supercat, Jun 28 2004
  

       It's been done for linux.
silicon wizard, Mar 08 2005
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle