[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
This archive was generated by hypermail 2b30 : Mon Jan 21 2002 - 09:24:26 PST