Bugtraq mailing list archives

Re: remote memory reading through tcp/icmp


From: Fyodor <fygrave () tigerteam net>
Date: Mon, 21 Jan 2002 19:45:15 +0700

[snip snip]

    ptr = (char *)malloc(val);
    memset(ptr, 0x41, val-1);
    free(ptr);

00 00 00 00 45 00 00 24 A2 15 20 00 3E 06 BC BC  ....E..$.. .>...
7F 00 00 01 7F 00 00 01 E1 C1 01 91 FB 73 6B E2  .............sk.
00 00 00 00 50 02 08 00 41 41 41 41 41 41 41 41  ....P...AAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41              AAAAAAAAAAAA

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.

The blind guess for what is happening here would be that memory from a
shared memory segment after being free()'ed in userland, returns to
kernel space and being (k)allocated again. When an ICMP message is
formed up, the memory chunk just isn't initialized. So the bits and
pieces which were there, would remain in the packet unless overwritten.

I doubt you'd find extremely sensitive information in packet contents,
an application which work with shadowed passwds, encryption keys/passwords,
are supposed (!) to lock the memory and wipe it upon release (otherwise
you could get that with local malloc's too). On some platforms the
released memory is 0xdeadbeef'ed as well.

Which Linux are you playing with by the way, 2.2.x-2.4.x or something?

One specific use is for this could be identifying the byte order of a remote 
machine because of the addresses are in memory. (Reading from Linux Magazine
November 2001, page 50, you have 0xef* for the stack on a big endian system as opposed to the 0xbf* on little endian. 
(linux-wise)).

Well, I doubt that you have a high chance of locating a stack address in
heap memory, but you could find some other pointers/data anyway. You also
could gather some 'intelligence' about the target system by trying to
figure out byte order of the ptrs themselves (i.g. a 0xbe00000 pointer
makes a better sense than 0x000000be, although the latter could be just
a regular data).

just my .02baht worth of rambling on the subject...

-- 
http://www.notlsd.net
PGP fingerprint = 56DD 1511 DDDA 56D7 99C7  B288 5CE5 A713 0969 A4D1


Current thread: