Message-ID: <20030727205121.17701.qmail@www.securityfocus.com>
Date: 27 Jul 2003 20:51:21 -0000
From: Vade 79 <v9@...ehalo.deadpig.org>
To: bugtraq@...urityfocus.com
Subject: [PAPER]: Address relay fingerprinting.




PAPER: "Address relay fingerprinting".

AUTHOR: vade79/v9 v9@...ehalo.deadpig.org (fakehalo).

HEADER: A small paper about how to use often discarded bugs. 


(sorry if this has been discussed already, found no information on this)

This paper discusses how to use values returned from programs to
create fingerprints.  Most of the information contained in this paper will
relate to off-by-one buffer miscalculations.  While they are very common,
not all are exploitable, and often get dismissed due to that.  As these
bugs may not always yield exploitable conditions, they do tend to relay
information about the machine.

Off-by-one buffer miscalculations, discussed here, occur when a said
program function does not account for the null-byte at the end of the
buffer.  So, when most functions read data from that buffer, it will 
continue reading until a null-byte is read.  In ascii terms, it will
look like this(in memory):

[data 1][null-byte][data 2][null-byte][data 3][null-byte]...

So, when "data 1"'s contents are allowed to overwrite the null-byte, most
functions will continue reading into "data 2".  "data 2" can be a variety
of things, depending on the program/situation.  This includes other
character arrays, numerics, memory addresses, and so on.  But, in most
situations, it will be memory addresses.

As a side note(1); Just because "data 2" is a memory address(real/in use),
does not totally rule out exploitation, for buffer expansion.  Although, 
often can be ruled out of the realm of probability.  Anyways, that 
discussion is for another paper all together.

A common way these bugs can occur, is when calling sizeof(buffer), or a
defined BUFSIZE as the limit to write to the buffer.  Which, in both cases,
does not account for the null-byte. (unless when the buffer is allocated,
adds +1 to BUFSIZE)

The only way these bugs can be useful, is when the information you write
to the buffer gets relayed back at some point, or can trigger the event.
This sounds limiting, but it is a lot more common than it seems.  If you 
commonly audit software, I'm sure you have noticed the volume of this
brand of bug.

Not all functions will allow this problem to occur.  For example, read(),
and strncpy() will allow further reading.  While similarly fgets(),
and snprintf() will not, under the same size limitations.

As a side note(2); The conditions do not have to be limited to that of
off-by-one/null-byte removal.  These bugs can be achieved in a variety of
ways, including relaying unused buffers(before bzero'd/used), relaying
mis-casts, relaying buffer underruns, and so on.

Here is a local example of how these bugs work in action, and can be used
for fingerprinting:

# cat <<EOF>myecho.c
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
> int main(int argc,char **argv){
>  char buf[256];
>  memset(buf,0,sizeof(buf));
>  if(argc!=2)
>   printf("syntax: %s <argument>\n",argv[0]);
>  else{
>   /* common off-by-one limit style. */
>   strncpy(buf,argv[1],sizeof(buf));
>   /* echo the buffer back. */
>   printf("%s\n",buf);
>  }
>  exit(0);
> }
> EOF
# gcc myecho.c -o myecho
# ./myecho test
test
# ./myecho `perl -e 'print"x"x255'`
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# ./myecho `perl -e 'print"x"x256'`
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxøÈùÿ¿wá@
# ./myecho `perl -e 'print"x"x256'`|hexdump
0000000 7878 7878 7878 7878 7878 7878 7878 7878
*
0000100 9614 0804 96f8 0804 f9c8 bfff e177 4003
--------^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^
0000110 0a02
0000112
#

As you can see, when you write 255 bytes to the buffer, the information
gets relayed back properly.  However, when 256 bytes are written, it relays
some extra junk back.  If you notice the hexdump, there are memory
addresses(linux x86) dumped along with it.  Those addresses being
0x08049614, 0x080496f8, 0xbffff9c8, and 0x4003e177.

If we take "myecho" into gdb(GNU Debugger), and run the same command lines,
we can see exactly what happens:

(gdb) file ./myecho
Reading symbols from ./myecho...done.
(gdb) break strncpy
Breakpoint 1 at 0x80483e8
(gdb) break printf
Breakpoint 2 at 0x80483a8
(gdb) run `perl -e 'print"x"x255'`
Starting program: /root/./myecho `perl -e 'print"x"x255'`
Breakpoint 1 at 0x400a800b: file ../sysdeps/generic/strncpy.c, line 31.
Breakpoint 2 at 0x400815e6: file printf.c, line 32.

Breakpoint 1, strncpy (s1=0xbffff8b0 "",
    s2=0xbffffb41 'x' <repeats 200 times>..., n=256)
    at ../sysdeps/generic/strncpy.c:31
31      ../sysdeps/generic/strncpy.c: No such file or directory.
        in ../sysdeps/generic/strncpy.c
(gdb) cont
Continuing.

Breakpoint 2, printf (format=0x80485ff "%s\n") at printf.c:32
32      printf.c: No such file or directory.
        in printf.c
(gdb) x/c 0xbffff8b0+250
0xbffff9aa:     120 'x'
(gdb)
0xbffff9ab:     120 'x'
(gdb)
0xbffff9ac:     120 'x'
(gdb)
0xbffff9ad:     120 'x'
(gdb)
0xbffff9ae:     120 'x'
(gdb)
0xbffff9af:     0 '\000'
(gdb)
0xbffff9b0:     20 '\024'
(gdb) run `perl -e 'print"x"x256'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /root/./myecho `perl -e 'print"x"x256'`

Breakpoint 1, strncpy (s1=0xbffff8b0 "",
    s2=0xbffffb40 'x' <repeats 200 times>..., n=256)
    at ../sysdeps/generic/strncpy.c:31
31      ../sysdeps/generic/strncpy.c: No such file or directory.
        in ../sysdeps/generic/strncpy.c
(gdb) cont
Continuing.

Breakpoint 2, printf (format=0x80485ff "%s\n") at printf.c:32
32      printf.c: No such file or directory.
        in printf.c
(gdb) x/c 0xbffff8b0+250
0xbffff9aa:     120 'x'
(gdb)
0xbffff9ab:     120 'x'
(gdb)
0xbffff9ac:     120 'x'
(gdb)
0xbffff9ad:     120 'x'
(gdb)
0xbffff9ae:     120 'x'
(gdb)
0xbffff9af:     120 'x'
(gdb)
0xbffff9b0:     20 '\024'
(gdb)

You might be thinking this is completely useless.  But, remember many
operating systems/architectures use many different memory address values.
Now, you're probably thinking, what does this matter on a local level?  It
could have some minor uses on extremely limited environments, locally.
But, for the most part, is useless locally.

The main idea of this paper is for use on daemons, remotely.  Since it is
a very common coding practice, there is many-a-daemon that this can be
abused by.  Case in point, an example of randomly chosen daemon that
this can be done on is xfstt(X font server/true type):

# telnet localhost 7101
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
xxxxxxx
HDxxxxxxx

þ@Connection closed by foreign host.
# telnet localhost 7101|hexdump
0000000 7254 6979 676e 3120 3732 302e 302e 312e
0000010 2e2e 0a2e 6f43 6e6e 6365 6574 2064 6f74
0000020 6c20 636f 6c61 6f68 7473 6c2e 636f 6c61
0000030 6f64 616d 6e69 0a2e 7345 6163 6570 6320
0000040 6168 6172 7463 7265 6920 2073 5e27 275d
xxxxxxx
0000050 0a2e 0000 0002 0000 0000 0000 0000 0004
xxxxxxx
0000060 0000 0400 0002 0001 0000 4448 0000 0a01
Connection closed by foreign host.
0000070 0001 0004 0000 1f00 401b 82fe 4010
-----------------------^^^^ ^^^^ ^^^^ ^^^^
000007e
#

As you can see, memory addresses get sent back in reply.  0x401b1f00,
and 0x401082fe.  common memory addresses on linux/x86 are 0xbf??????,
0x40??????, and 0x08??????.  For a closer inspection;
0xbf<high value 0x??>????, 0x40<low value 0x??>????, and
0x08<low value 0x??>????.

Now, even if memory is set up the same way on multiple operating systems,
it can be broken down to the distribution level on the same operating
system(ie. linux).  This would be done by making a database of the memory
locations for each distribution/version.  Then, see how the addresses
dumped compare.

And here is where I stop, for now.  One could continue this by making
an address mapping program.  The idea would be to make this program
modular.  So, when an off-by-one/address relay bug(in the manner
described in this paper) is found, make a module for it to compare it to
a defined list of addresses.  Then, display what addresses matched, if
any, for each platform/distribution.


Vade79 -> v9@...ehalo.deadpig.org -> fakehalo.

Powered by blists - more mailing lists