RE: remote memory reading through tcp/icmp

From: David LeBlanc (dleblancat_private)
Date: Sun Jan 20 2002 - 16:26:30 PST

  • Next message: Marc Slemko: "Mozilla Cookie Exploit"

    > From: Andrew Griffiths [mailto:andrewgat_private] 
    
    > It is possible to read parts of a remote machines memory. To 
    > be specific, 
    > it would have to be memory recently freed/swapped to disk. 
     
    > Let's look at a sniffer trace from snort(2):
    [snip]
     
    > 12/11-00:34:34.290903 127.0.0.1 -> 127.0.0.1
    
    IMHO, to really validate this, you need to use 2 systems. Localhost to
    localhost sometimes does things that don't happen in other ways.
    
    > AFFECTED:
    > 
    > I assume it would be any OS that includes more than the 
    > ipaddresses/ports.
    
    And doesn't bother to clear the memory before sending it over the
    network. It's of dubious value to put more in the packet than required
    (can't think why anyone would do this - perhaps some minimum in an RFC
    somewhere?), but it doesn't hurt anything if you zero it out first.
      
    > The ramifications from this could be great. You may get 
    > fragments of the 
    > shadow file, various plaintext passwords (greatly 
    > depends...), pieces of code, urls, random memory.
    
    Well, maybe - I'd check across an actual network before getting too
    excited. It would also be interesting to see if anything else does this.
     
    >   + Locking memory for important stuff (passwords etc.). I've 
    > forgotten the call to do that but it is possible. This will prevent 
    > swapping to disk which might make it better.
    
    The operating system should be clearing memory belonging to one process
    before handing it to another. If its not doing that, then there's a
    bigger problem than just this. The fact that IP handling is going to
    happen in the kernel could have something to do with it, but kernel mode
    processing needs to be careful with memory just because of this sort of
    thing. You shouldn't need to lock the memory (IMHO).
    
    >   + Make the network code zero out the packet before sending 
    > it. This would slow it down though, and make it even more obvious that
    
    > you are running linux. 
    
    IMHO, this is the most appropriate fix. Should take a fairly trivial
    amount of time to zero 60 bytes or so compared to the rest of the
    operations needed to create a response packet. Also, IMHO, there are
    enough weird foibles of IP handling to where anyone who really wants to
    know can figure out you're running [fill in blank], so that wouldn't
    bother me too much. OTOH, Ofir and I disagree on this point 8-)
    
    David LeBlanc
    dleblancat_private 
    



    This archive was generated by hypermail 2b30 : Tue Jan 22 2002 - 12:56:15 PST