[23911] in bugtraq
Re: remote memory reading through tcp/icmp
daemon@ATHENA.MIT.EDU (Fyodor)
Mon Jan 21 12:24:42 2002
Date: Mon, 21 Jan 2002 19:45:15 +0700
From: Fyodor <fygrave@tigerteam.net>
To: Andrew Griffiths <andrewg@tasmail.com>
Cc: bugtraq@securityfocus.com
Message-ID: <20020121194515.E1240@tigerteam.net>
Mail-Followup-To: Andrew Griffiths <andrewg@tasmail.com>,
bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200201200917.g0K9HMT05289@picton-ext.nt.tas.gov.au>; from andrewg@tasmail.com on Sun, Jan 20, 2002 at 08:17:22PM +1100
[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
