[andrewg@tasmail.com: remote memory reading through tcp/icmp]

[andrewg@tasmail.com: remote memory reading through tcp/icmp]

[Martin Mačok]

Any comments on this?

----- Forwarded message from Andrew Griffiths <andrewg@tasmail.com> -----

Date: Sun, 20 Jan 2002 20:17:22 +1100 (EST)
From: "Andrew Griffiths" <andrewg@tasmail.com>
To: bugtraq@securityfocus.com
Subject: remote memory reading through tcp/icmp


Greets: (in no particular order)

        Marty (and others for their brilliant work with Snort)
        Fyodor (for nmap)
        LBNL Network Research Group
	zen-parse [4] and jaguar for looking over this and suggesting 
	improvements.

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. Consider this 
for example:

int main(int argc, char **argv[], char **envp[])
{
  char *ptr=0; /* We take a rather large chunk of memory and fill it with A's */
  int val, i;

  while(1) {
    sleep(1);
    val = 30000000; // ~ 30 M
    ptr = (char *)malloc(val);

    memset(ptr, 0x41, val-1);
    free(ptr);
  }
}

And then we modify nmap(1) (Around line 687) so it only transmits the
first fragment out of a fragmented scan. This will illict a ICMP TTL 
Exceeded message. Due to Linux including a lot more of the packet than most 
other OS's, we have around 20 bytes to read. From memory, Solaris includes 
a little bit extra on ICMP messages. 

Let's look at a sniffer trace from snort(2):
  (Ignore the time stamps, as the machine this was originally done had a date
  in 1994...) 

12/11-00:34:34.290903 127.0.0.1 -> 127.0.0.1
ICMP TTL:255 TOS:0xC0 ID:29812
TTL EXCEEDED
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

12/11-01:02:30.170720 127.0.0.1 -> 127.0.0.1
CMP TTL:255 TOS:0xC0 ID:31185
TTL EXCEEDED
00 00 00 00 45 00 00 24 32 25 20 00 3B 06 2F AD  ....E..$2% .;./.
7F 00 00 01 7F 00 00 01 AA 1E 01 11 50 FE C6 45  ............P..E
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

Also - to prove this is not Snort's fault I included a tcpdump(3) log.

01:06:02.640246   lo < 127.0.0.1 > 127.0.0.1: icmp: ip reassembly time exceeded
[tos 0xc0]
                         45c0 0054 7b85 0000 ff01 4161 7f00 0001
                         7f00 0001 0b01 77a3 0000 0000 4500 0024
                         d3e5 2000 3306 95ec 7f00 0001 7f00 0001
                         c027 055a 5fa5 73a5 0000 0000 5002 0800
                         4141 4141 4141 4141 4141 4141 4141 4141

AFFECTED:

I assume it would be any OS that includes more than the ipaddresses/ports.
 
USAGES:

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.

One specific use is for this could be identifying the endianness 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)).

FIX:

  hrmm.... well. 

  + 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.

  + Modifying the kernel so in its idle loop (or whatever) it wipes some
    (unused!) memory. Could lead to a race though...

  + A small program to continues malloc()/zero/free() stuff. A little like the
      program above, but zeroing it instead. (You could always take the 
      offensive stand by filling it with decoy data... that's left to the
      reader to implement. ;)

  + 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. 

  + Filter out various icmp error messages, but as usual that breaks 
    everything.


(1). Nmap   http://www.insecure.org/nmap

(2). Snort  http://www.snort.org
     snort -vd -i lo

(3) tcpdump -lnx
Lawrence Berkeley National Laboratory
Network Research Group
tcpdump@ee.lbl.gov
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

(4) Make sure you visit Chapel of Stilled Voices
                       .  .  _  _   _  _ .  .     _  _  _ .  .
 |_  _|_ _|_  _ .  / / |\/| |_| _| |  | ||\/|  / |  | ||_ |  |
 | |  |   |  |_|. / /  |  | |   _|.|_ |_||  | /  |_ |_| _| \/ 
             |
(5) Hey, there is no [5], so why are you reading this!?@!



--
www.tasmail.com


----- End forwarded message -----

-- 
         Martin Mačok                 http://underground.cz/
   martin.macok@underground.cz        http://Xtrmntr.org/ORBman/

Re: [andrewg@tasmail.com: remote memory reading through tcp/icmp]

[David S. Miller]

   From: Martin Mačok <martin.macok@underground.cz>
   Date: Mon, 21 Jan 2002 01:52:09 +0100

   Any comments on this?
   
Pretty simple to fix, from Andi Kleen:

--- linux-work/net/ipv4/icmp.c-o	Tue Jan 15 11:05:17 2002
+++ linux-work/net/ipv4/icmp.c	Sun Jan 20 23:31:29 2002
@@ -495,7 +495,7 @@
 	icmp_param.data.icmph.checksum=0;
 	icmp_param.csum=0;
 	icmp_param.skb=skb_in;
-	icmp_param.offset=skb_in->nh.raw - skb_in->data;
+	icmp_param.offset=skb_in->data - skb_in->nh.raw;
 	icmp_out_count(icmp_param.data.icmph.type);
 	icmp_socket->sk->protinfo.af_inet.tos = tos;
 	ipc.addr = iph->saddr;
--- linux-work/net/ipv6/icmp.c-o	Thu Sep 20 23:12:56 2001
+++ linux-work/net/ipv6/icmp.c	Sun Jan 20 23:40:03 2002
@@ -361,7 +361,7 @@
 	msg.icmph.icmp6_pointer = htonl(info);
 
 	msg.skb = skb;
-	msg.offset = skb->nh.raw - skb->data;
+	msg.offset = skb->data - skb->nh.raw; 
 	msg.csum = 0;
 	msg.daddr = &hdr->saddr;

Re: [andrewg@tasmail.com: remote memory reading through tcp/icmp]

[Dave Jones]

On Sun, Jan 20, 2002 at 05:52:04PM -0800, David S. Miller wrote:
 > Pretty simple to fix, from Andi Kleen:
 > 
 > --- linux-work/net/ipv4/icmp.c-o	Tue Jan 15 11:05:17 2002
 > +++ linux-work/net/ipv4/icmp.c	Sun Jan 20 23:31:29 2002
 > @@ -495,7 +495,7 @@
 >  	icmp_param.data.icmph.checksum=0;
 >  	icmp_param.csum=0;
 >  	icmp_param.skb=skb_in;
 > -	icmp_param.offset=skb_in->nh.raw - skb_in->data;
 > +	icmp_param.offset=skb_in->data - skb_in->nh.raw;

 With this fix, I'm seeing lots of really strange things happen.
 When eth0 comes up, the box slows down to a crawl.
 5 minutes later when it gets to starting NIS, the
 broadcast address is bombed with portmap connections.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [andrewg@tasmail.com: remote memory reading through tcp/icmp]

[David S. Miller]

   From: Dave Jones <davej@suse.de>
   Date: Mon, 21 Jan 2002 03:12:11 +0100

   On Sun, Jan 20, 2002 at 05:52:04PM -0800, David S. Miller wrote:
    > -	icmp_param.offset=skb_in->nh.raw - skb_in->data;
    > +	icmp_param.offset=skb_in->data - skb_in->nh.raw;
   
    With this fix, I'm seeing lots of really strange things happen.
    When eth0 comes up, the box slows down to a crawl.
    5 minutes later when it gets to starting NIS, the
    broadcast address is bombed with portmap connections.

Andi?

Re: [andrewg@tasmail.com: remote memory reading through tcp/icmp]

[Russell King]

On Sun, Jan 20, 2002 at 06:43:18PM -0800, David S. Miller wrote:
>    From: Dave Jones <davej@suse.de>
>    Date: Mon, 21 Jan 2002 03:12:11 +0100
> 
>    On Sun, Jan 20, 2002 at 05:52:04PM -0800, David S. Miller wrote:
>     > -	icmp_param.offset=skb_in->nh.raw - skb_in->data;
>     > +	icmp_param.offset=skb_in->data - skb_in->nh.raw;
>    
>     With this fix, I'm seeing lots of really strange things happen.
>     When eth0 comes up, the box slows down to a crawl.
>     5 minutes later when it gets to starting NIS, the
>     broadcast address is bombed with portmap connections.
> 
> Andi?

I've also seen:

127.0.0.1 sent an invalid ICMP error to a broadcast.

from the ipv4 stack after fixing these as per the Andi's patch.  I'm not
certain what's causing it; it only happens while the box is coming up.

In addition, there was another case in the icmp6 code that Andi confirmed
last night:

--- ref/net/ipv6/icmp.c	Fri Oct  5 17:53:04 2001
+++ linux/net/ipv6/icmp.c	Sun Jan 20 23:05:01 2002
@@ -258,7 +258,7 @@
 {
 	u8 optval;
 
-	offset += skb->nh.raw - skb->data;
+	offset += skb->data - skb->nh.raw;
 	if (skb_copy_bits(skb, offset, &optval, 1))
 		return 1;
 	return (optval&0xC0) == 0x80;

(another mail will be following this one with another patch...)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [andrewg@tasmail.com: remote memory reading through tcp/icmp]

[Russell King]

On Sun, Jan 20, 2002 at 06:43:18PM -0800, David S. Miller wrote:
> Andi?

Ok, final message - I found I was getting a fair number of

  ICMP redirect: packet too short

messages in the log while running IPv6.  It appears that I had icmp
redirects bouncing between two IPv6 routers (and the routers were updating
their routing tables, which is against RFC2461, but I'm not concerned
about that at the moment).

It appears that net/ipv6/ndisc.c forgets to convert the payload_len header
field to host byteorder before comparing it.

The following patch corrects this.

--- ref/net/ipv6/ndisc.c	Thu Dec 20 11:03:56 2001
+++ linux/net/ipv6/ndisc.c	Mon Jan 21 14:06:17 2002
@@ -957,6 +957,7 @@
 	struct nd_msg *msg = (struct nd_msg *) skb->h.raw;
 	struct neighbour *neigh;
 	struct inet6_ifaddr *ifp;
+	unsigned int payload_len;
 
 	__skb_push(skb, skb->data-skb->h.raw);
 
@@ -979,10 +980,11 @@
 	 *	(Some checking in ndisc_find_option)
 	 */
 
+	payload_len = ntohs(skb->nh.ipv6h->payload_len);
 	switch (msg->icmph.icmp6_type) {
 	case NDISC_NEIGHBOUR_SOLICITATION:
 		/* XXX: import nd_neighbor_solicit from glibc netinet/icmp6.h */
-		if (skb->nh.ipv6h->payload_len < 8+16) {
+		if (payload_len < 8+16) {
 			if (net_ratelimit())
 				printk(KERN_WARNING "ICMP NS: packet too short\n");
 			return 0;
@@ -1112,7 +1114,7 @@
 
 	case NDISC_NEIGHBOUR_ADVERTISEMENT:
 		/* XXX: import nd_neighbor_advert from glibc netinet/icmp6.h */
-		if (skb->nh.ipv6h->payload_len < 16+8 ) {
+		if (payload_len < 16+8 ) {
 			if (net_ratelimit())
 				printk(KERN_WARNING "ICMP NA: packet too short\n");
 			return 0;
@@ -1174,7 +1176,7 @@
 
 	case NDISC_ROUTER_ADVERTISEMENT:
 		/* XXX: import nd_router_advert from glibc netinet/icmp6.h */
-		if (skb->nh.ipv6h->payload_len < 8+4+4) {
+		if (payload_len < 8+4+4) {
 			if (net_ratelimit())
 				printk(KERN_WARNING "ICMP RA: packet too short\n");
 			return 0;
@@ -1184,7 +1186,7 @@
 
 	case NDISC_REDIRECT:
 		/* XXX: import nd_redirect from glibc netinet/icmp6.h */
-		if (skb->nh.ipv6h->payload_len < 8+16+16) {
+		if (payload_len < 8+16+16) {
 			if (net_ratelimit())
 				printk(KERN_WARNING "ICMP redirect: packet too short\n");
 			return 0;
@@ -1196,7 +1198,7 @@
 		/* No RS support in the kernel, but we do some required checks */
 
 		/* XXX: import nd_router_solicit from glibc netinet/icmp6.h */
-		if (skb->nh.ipv6h->payload_len < 8) {
+		if (payload_len < 8) {
 			if (net_ratelimit())
 				printk(KERN_WARNING "ICMP RS: packet too short\n");
 			return 0;

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [andrewg@tasmail.com: remote memory reading through tcp/icmp]

[Dave Jones]

On Mon, 21 Jan 2002, Russell King wrote:

> 127.0.0.1 sent an invalid ICMP error to a broadcast.
> from the ipv4 stack after fixing these as per the Andi's patch.  I'm not
> certain what's causing it; it only happens while the box is coming up.

Further investigation showed that 2.5.2-pre2 + andi's fix + a minimal
set of compile fixes made my problem disappear. Looks like a bad
interaction between something I had in -dj already, and the pre2 merge.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [andrewg@tasmail.com: remote memory reading through tcp/icmp]

[David S. Miller]

   From: Russell King <rmk@arm.linux.org.uk>
   Date: Mon, 21 Jan 2002 14:44:04 +0000
   
   It appears that net/ipv6/ndisc.c forgets to convert the payload_len header
   field to host byteorder before comparing it.
   
   The following patch corrects this.

Applied, thanks.