On 04/27/2002, I disclosed on the Linux Kernel Mailing list, a vulnerability that would be come known as the 'etherleak' bug. In various situations an ethernet frame must be padded to reach a specific size or fall on a certain boundary. This task is left up to the driver for the ethernet device. The RFCs state that this padding must consist of NULLs. The bug is that at the time and still to this day, many device drivers do not pad will NULLs, but rather pad with unsanitized portions of kernel memory, oftentimes exposing sensitive information to remote systems or those savvy enough to coerce their targets to do so.
Proof of this can be found by googling for "remote memory reading using arp", or by visiting the original posting. Admittedly, I did not realize at the time the exact cause of the bug nor the scope, but to my knowledge this was the first public disclosure.
This was ultimately fixed in the Linux kernel, but over time this vulnerability reared its head numerous times, but at the core the vulnerability was the same as the one I originally published. The most public of these was CVE-2003-0001, which was assigned to address an official @stake advisory which did not credit my findings.
So, now, nearly 5 years later, I'm publishing the POC exploit code I've recently revamped that can demonstrate the issue. The good news is that the bug has been addressed by numerous vendors, but is still rampant and should be considered a threat.
Enjoy.
Posted by Jon Hart on March 23, 2007 12:20 AM | Permalink
Comments (2)
Being a security enthusiast, I find your blog extremely interesting and a fulfilling read, your articles are all excellent. Just thought I'd take time to say thanks.
Posted by CoryDambach | March 26, 2007 3:42 PM
Posted on March 26, 2007 15:42
Well this and the BOOTP exploit for our Linksys router were very interesting reading... I find it amazing that people are using non-specifically declared variables. The funny thing is that the source code probaly looks right on paper, but a lack of understanding the compiler's bugs or just plain inexperience with systems/firmware security causes this? I'm more than sure that my old (spare)Blitzz Netwave Base G4 router has the same kind of bugs too. If I find them, I'll submit a report to you. Not that many are using that one anymore. :)
I was told in a programming class that even if you don't plan on using the data in a variable, you really should clear it anyways. Of course in afterclass discussion, we talked about clearing it on RETURNING from a call if you don't want it floating around. The bug you mention seems to be something like this:
1) Call a function.
2) Return from it.
3) Wait while running other functions until getting 'lucky'...
4) Call another function using the same global variable or dynamic variable with the same position on the stack.
5) Function 'builds up' a packet to send and to save cycles/complexity, don't explicitly set 'useless' fields.
6) Send out a packet with the reserved bytes set to something random instead of zeros (NULLs).
This is a cute bug because it's so dang devious!
Mitigation techniques:
1) Explicitly set reserved values to zero. This makes the code harder to read, but if compiled right it should actually be faster or just as fast.
2) Declare and define all temporary variables before using them as an object. (Good practice anyways)
I'm sure there's other ways, but those two should do it, right?
Posted by Joe Whitehead | August 3, 2007 7:28 PM
Posted on August 3, 2007 19:28