remote memory reading using arp?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Bryan Rittmeyer
It's not the ARP layer that's causing the padding... Ethernet has a minimum transmit size of 64 bytes (everything below that is disgarded by hardware as a fragment), so the network device driver or the hardware itself will pad any Linux skb smaller than 60 bytes up to that size (so that it's 64 bytes after appending CRC32). Apparently, in some cases that's done by just transmitting whatever uninitialized memory follows
skb->data, which, after the system has been running for a while, may be inside a page previously used by userspace.
The driver should be fixed in that case. I would consider it a driver bug. The cost of clearing the tail should be minimal, it is at most two cache lines.
Is it known which driver caused this?
Quoted 2 lines
This is NOT a "remote memory reading" exploit, since there is no way to
It really is.
-Andi
Quoted 11 lines · Andi Kleen
Quoted 8 lines · Bryan Rittmeyer
It's not the ARP layer that's causing the padding... Ethernet has a minimum transmit size of 64 bytes (everything below that is disgarded by hardware as a fragment), so the network device driver or the hardware itself will pad any Linux skb smaller than 60 bytes up to that size (so that it's 64 bytes after appending CRC32). Apparently, in some cases that's done by just transmitting whatever uninitialized memory follows
skb->data, which, after the system has been running for a while, may be inside a page previously used by userspace.
Quoted 2 lines
The driver should be fixed in that case. I would consider it a driver bug. The cost of clearing the tail should be minimal, it is at most
Yes, I wholeheartedly agree. Also, the notion that it's userspace's responsibility to clear memory before exiting is preposterous. That would involve just about every piece of software ever made to be rewritten (you could change glibc to clear memory on free()s but what about the stack?).
Quoted 8 lines
two cache lines.
Is it known which driver caused this?
Quoted 2 lines
This is NOT a "remote memory reading" exploit, since there is no way to
It really is.
Yes. If you snoop long enough, it becomes possible to read passords and other sensitive data. Granted, this is only on the local network, but it is still a major hole.
Quoted 9 lines
(quoted diff) +0
-2-Andi -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 13 lines · Calin A. Culianu
Quoted 11 lines · Andi Kleen
Quoted 8 lines · Bryan Rittmeyer
It's not the ARP layer that's causing the padding... Ethernet has a minimum transmit size of 64 bytes (everything below that is disgarded by hardware as a fragment), so the network device driver or the hardware itself will pad any Linux skb smaller than 60 bytes up to that size (so that it's 64 bytes after appending CRC32). Apparently, in some cases that's done by just transmitting whatever uninitialized memory follows
skb->data, which, after the system has been running for a while, may be inside a page previously used by userspace.
Quoted 7 lines
Quoted 2 lines
The driver should be fixed in that case. I would consider it a driver bug. The cost of clearing the tail should be minimal, it is at most
Yes, I wholeheartedly agree. Also, the notion that it's userspace's responsibility to clear memory before exiting is preposterous. That would involve just about every piece of software ever made to be rewritten (you could change glibc to clear memory on free()s but what about the stack?).
It actually requires more changes. The skbuff allocator needs to be fixed too to ensure a 64 bytes minimum length of the skb. (or alternatively if you don't want to penalize non ethernet protocols read minlen from a dev-> field similar to hard_header_len and compute it in the caller, but that's likely overkill)
But should be done.
-Andi
Dirty memory? (WAS Re: remote memory reading using arp?)
Quoted 22 lines · Andi Kleen
Quoted 13 lines · Calin A. Culianu
Quoted 11 lines · Andi Kleen
Quoted 8 lines · Bryan Rittmeyer
It's not the ARP layer that's causing the padding... Ethernet has a minimum transmit size of 64 bytes (everything below that is disgarded by hardware as a fragment), so the network device driver or the hardware itself will pad any Linux skb smaller than 60 bytes up to that size (so that it's 64 bytes after appending CRC32). Apparently, in some cases that's done by just transmitting whatever uninitialized memory follows
skb->data, which, after the system has been running for a while, may be inside a page previously used by userspace.Quoted 7 lines
Quoted 2 lines
The driver should be fixed in that case. I would consider it a driver bug. The cost of clearing the tail should be minimal, it is at most
Yes, I wholeheartedly agree. Also, the notion that it's userspace's responsibility to clear memory before exiting is preposterous. That would involve just about every piece of software ever made to be rewritten (you could change glibc to clear memory on free()s but what about the stack?).
Quoted 5 lines
It actually requires more changes. The skbuff allocator needs to be fixed too to ensure a 64 bytes minimum length of the skb. (or alternatively if you don't want to penalize non ethernet protocols read minlen from a dev-> field similar to
hard_header_lenand compute it in the caller, but that's likely overkill)
Well, that sounds pretty elegant. After all, it makes sense for the caller to ensure the data field in his skbuff is at least as big as the (MTU? is this the field we want in struct net_device?) for his dev...
Quoted 2 lines
But should be done.
I am glad you think so. More generally, once can make the argument that to be 100% secure, one needs to revisit a lot of the kernel memory allocations (not just in the networking code) and see if the following two criteria are met: any of the memory allocated could potentially be/remain 'dirty' for a while && there is a possibility that the contents of that memory could make their way into 'untrusted' hands. Things like giving the dirty memory to userspace or sending portions of it down the network wire are examples of placing it in untrusted hands.
I am not sure if this is a can of worms worth opening. While it would be nice for the kernel to reliably provide guarantees about memory and its 'cleanliness' and privateness (after all this is one third the reason for memory protection in the first place!), it may be a lot of trouble performancewise.... however it still is an interesting problem to look at...
I wonder if any other operating systems have addressed the issue of memory allocators and the possibility that the memory they return may contain sensitive data?
-Calin
Quoted 8 lines
(quoted diff) +0
-2-Andi -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dirty memory? (WAS Re: remote memory reading using arp?)
Actually nevermind. It looks like memory allocated for userspace is always zeroed out... hehe don't I feel dumb..
-Calin
Quoted 74 lines · Calin A. Culianu
Quoted 22 lines · Andi Kleen
Quoted 13 lines · Calin A. Culianu
Quoted 11 lines · Andi Kleen
Quoted 8 lines · Bryan Rittmeyer
It's not the ARP layer that's causing the padding... Ethernet has a minimum transmit size of 64 bytes (everything below that is disgarded by hardware as a fragment), so the network device driver or the hardware itself will pad any Linux skb smaller than 60 bytes up to that size (so that it's 64 bytes after appending CRC32). Apparently, in some cases that's done by just transmitting whatever uninitialized memory follows
skb->data, which, after the system has been running for a while, may be inside a page previously used by userspace.Quoted 7 lines
Quoted 2 lines
The driver should be fixed in that case. I would consider it a driver bug. The cost of clearing the tail should be minimal, it is at most
Yes, I wholeheartedly agree. Also, the notion that it's userspace's responsibility to clear memory before exiting is preposterous. That would involve just about every piece of software ever made to be rewritten (you could change glibc to clear memory on free()s but what about the stack?).
Quoted 5 lines
It actually requires more changes. The skbuff allocator needs to be fixed too to ensure a 64 bytes minimum length of the skb. (or alternatively if you don't want to penalize non ethernet protocols read minlen from a dev-> field similar to
hard_header_lenand compute it in the caller, but that's likely overkill)Well, that sounds pretty elegant. After all, it makes sense for the caller to ensure the data field in his skbuff is at least as big as the (MTU? is this the field we want in struct
net_device?) for his dev...Quoted 2 lines
But should be done.
I am glad you think so. More generally, once can make the argument that to be 100% secure, one needs to revisit a lot of the kernel memory allocations (not just in the networking code) and see if the following two criteria are met: any of the memory allocated could potentially be/remain 'dirty' for a while && there is a possibility that the contents of that memory could make their way into 'untrusted' hands. Things like giving the dirty memory to userspace or sending portions of it down the network wire are examples of placing it in untrusted hands.
I am not sure if this is a can of worms worth opening. While it would be nice for the kernel to reliably provide guarantees about memory and its 'cleanliness' and privateness (after all this is one third the reason for memory protection in the first place!), it may be a lot of trouble performancewise.... however it still is an interesting problem to look at...
I wonder if any other operating systems have addressed the issue of memory allocators and the possibility that the memory they return may contain sensitive data?
-Calin
Quoted 8 lines
(quoted diff) +0
-2-Andi -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greetings again,
I took the time today to gather as much arp traffic as my eyes could handle and enough to shed some valuable light on this issue.
While it doesn't show who/what is at fault, it may possibly prove that I'm missing something entirely or the problem is more widespread that was thought.
Anyway, here goes.
For test 1, I gathered ~1.5M of arp traffic from a monitoring port that sustains 4-5Mb/s traffic in a mixed solaris/linux/win2k environment of approximately 400 machines in an educational setting.
For test 2, I gathered ~.5M of arp traffic from a single interface of a RedHat machine located in a "Small Business" environment consisting of approximately 25 machines (linux/winXP).
That much arp data is pretty unruly, so I used grep to see if anything stuck out.
I grepped for our domain name (ccs.neu.edu) and found this string 15 times in test 1, and grepped for 'http' in test 2 and found that string 62 times.
Upon digging into the traffic a bit further, I saw an interesting trends. All of the arp packets that contained interesting data contained it in the last 18 bytes of the 60 byte arp packet. After googling and browsing the rfcs, I've seen these last 18 bytes referred to as both 'trailers' and 'padding'. It is not clear to me what purpose they serve, but seems clear that they can contain some potentially sensitive data.
I know this may be getting a bit off topic, but I figured I share my findings with the lists. If I am incorrect in any of my statements, please correct me.
thanks,
-jon
Quoted 5 lines
The driver should be fixed in that case. I would consider it a driver bug. The cost of clearing the tail should be minimal, it is at most two cache lines.
Is it known which driver caused this?
My testing yesterday was done with a Xircom RBEM58G-100 (10/100 + 56k) and an Aironet PC4800 (with xircom_tulip_cb and airo/airo_cs, respectively). Since this may be a driver problem, I should note that the airo drivers are from pcmcia-cs-3.1.33.
Quoted 3 lines
Quoted 1 line
This is NOT a "remote memory reading" exploit, since there is no way to
It really is.
I'm finding it really difficult to replicate this problem today, but if I find anything else that may be of use to help shed more light on this issue, I'll be sure and share it.
thanks