Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Flaw Found iIn Ethernet Device Drivers 429

Licensed2Hack writes "Security researchers have discovered a serious vulnerability that may be present in many Ethernet device drivers that is causing the devices to broadcast sensitive information over networks. Seems the device driver writers couldn't be bothered with a memset() call. Eweek has their typical (puffy, low on tech details) take on it here. Since they don't specify the OS, I'm assuming these are drivers for Windows." It's actually Linux, *BSD, and Windows.
This discussion has been archived. No new comments can be posted.

Flaw Found iIn Ethernet Device Drivers

Comments Filter:
  • Hah! (Score:2, Funny)

    by Anonymous Coward
    At least it didn't foil my first post.
  • Or maybe (Score:5, Informative)

    by Anonymous Coward on Thursday January 09, 2003 @08:12AM (#5046139)
    the flaws are in linux drivers too. Who knows, you might even want to read the article.
    • Re:Or maybe (Score:3, Informative)

      by packeteer ( 566398 )
      Exploitable drivers have been found for Windows, Linux, NetBSD, and a few other proprietary OS's which i would assume could mean something like Mac or Novell or OS/2... who knows really.
    • Re:Or maybe (Score:2, Insightful)

      by ottawanker ( 597020 )
      It's pretty bad when people who reply don't read the article, but shouldn't the poster himself at least read it? Excerpt from the article:

      "The Linux, NetBSD and Microsoft Windows operating systems are known to have vulnerable link layer implementations, and it is extremely likely that other operating systems are also affected."
    • Heck, maybe hell stop using ignorant sayings like "Seems the programmers couldnt be bothered with a memset()" and get his head out of his own arse whilst hes at RTFA.
    • Re:Or maybe (Score:3, Informative)

      by Ashran ( 107876 )
      A link [cert.org] from the article has a list of vulnerable vendors.
      Microsoft Corporation Not Vulnerable 3-Jan-2003
    • Clue. (Score:3, Informative)

      by twitter ( 104583 )
      Read the article, what a great idea! I'd never have thought that's what Slashdot was good for. Solid advice worthy of a +5 troll rating. So what do we find?
      Thanks to some vagueness in the standards defining IP datagram transmission on Ethernet networks, it's not entirely clear exactly how the padding should be done. Some implementations do it on the NIC, while others handle it in the software device driver

      Ding! This means that all NICs that have the problem have that problem under any OS unless the card can be overcome by software. Additionally, "software drivers" under any OS can have the same problem.

      Is the problem more likely under, M$ junk? Of course it is. The free software world will move to fix any driver problems, and there are only a few dozen drivers in the world to work the thousands of different brand name cards. The closed source world has thousands of drivers to fix by companies that may not even exist anymore, and because it's closed and the user won't know any better, why would anyone bother?

      Of course this completely ignores whole models that are available in the free software world to prevent such problems of untrusted networks in the first place. I don't really care if my NIC pads packets with chunks of the last SSH packet. Encryped noise is just that and you can have as many packets as you like of it. If you played it over a speaker it would sound like this "Shushshhshhhshhhhhshhhhsh!" and I sugest you do shush.

  • by Anonymous Coward on Thursday January 09, 2003 @08:13AM (#5046140)
    ...."iln" story title
  • You assume too much (Score:3, Informative)

    by GroovBird ( 209391 ) on Thursday January 09, 2003 @08:14AM (#5046145) Homepage Journal
    From the article (in case you haven't read it):

    "The Linux, NetBSD and Microsoft Windows operating systems are known to have vulnerable link layer implementations, and it is extremely likely that other operating systems are also affected."

    • by GroovBird ( 209391 ) on Thursday January 09, 2003 @08:17AM (#5046157) Homepage Journal
      In addition (I post too fast), the CERT has made available a list of vulnerable systems [cert.org] that they know of.
      Interesting fact: Microsoft Windows is mentioned as "not vulnerable".

      • > In addition (I post too fast)

        Don't believe you...

        You were just trying get TWO Score+5's and reap the karma...

        Blame it on packet fragmentation if you like...

      • by the_mice ( 163224 ) on Thursday January 09, 2003 @08:50AM (#5046277)
        Granted Windows is listed as "Not Vulnerable", but here's the MS statement regarding this issue (from the CERT advisory's vendor listing):
        Microsoft does not ship any drivers that contain the vulnerability. However, we have found samples in our documentation that, when compiled without alteration, could yield a driver that could contain this issue. We have made corrections to the samples in our documentation, and will include tests for this issue in our certification process.
        So the OS itself isn't vulnerable as it's own networking code doesn't handle Ethernet padding, but the OS vendor has in the past provided Windows NIC vendors (and hence driver developers) with documentation leading directly to this vulnerability... Sounds secure to me...
      • Interesting fact: Microsoft Windows is mentioned as "not vulnerable".

        You mean Microsoft said they aren't vulnerable. [cert.org] But look at these weasel words: "However, we have found samples in our documentation that, when compiled without alteration, could yield a driver that could contain this issue." Draw your own conclusions.
  • by Alranor ( 472986 ) on Thursday January 09, 2003 @08:16AM (#5046153)
    Since they don't specify the OS

    Straight from the article
    "The Linux, NetBSD and Microsoft Windows operating systems are known to have vulnerable link layer implementations, and it is extremely likely that other operating systems are also affected."

    OK, it's slashdot, so we expect people to post comments without reading the article, but it's a little ridiculous that the submitter didn't even bother.
    • This is even MORE stupid since the REAL advisory this article is based on specifically states that windows doesn't ship with any vulnerable drivers.

      The only point of interrogation is that SAMPLES that when compiled without changes, will have the reported problem (http://www.kb.cert.org/vuls/id/JPLA-5BGP7V)
    • by Drestin ( 82768 ) on Thursday January 09, 2003 @11:30AM (#5047366)
      If you read the actual CERT Vulnerability note [cert.org] and seen that Windows is not vulnerable.
    • Good point. Personally, I think there is something fundamentally broken with the whole system. To have your story submitted, you have to submit it fast (Even though this news is actually 3 days old). To have your post modded up to +5 area it has to be very fast - i.e. too fast to actually read the article. Does this seem broken to anyone else?
  • by Anonymous Coward on Thursday January 09, 2003 @08:16AM (#5046154)
    Anonymous Coward writes "English speakers have discovered a serious flaw that may be present in many Slashdot editors that is causing the devices to broadcast poor journalism over networks. Seems the editors couldn't be bothered with a Spellcheck call. Slashdot trolls have their typical (puffy, low on tech details) take on it here. Since a fault was found, Slashdot is assuming the problem is with Windows."
  • well (Score:5, Interesting)

    by REBloomfield ( 550182 ) on Thursday January 09, 2003 @08:16AM (#5046155)
    lets hope this isn't globally exploitable, as I can't imagine every manufacturer of every card is going to fix this....

    One wonders whether it would be possible to build a fix into the operating system, or would that be too great an abstraction?

    • Re:well (Score:3, Informative)

      by Ivan Raikov ( 521143 )
      lets hope this isn't globally exploitable, as I can't imagine every manufacturer of every card is going to fix this....

      One wonders whether it would be possible to build a fix into the operating system, or would that be too great an abstraction?

      Well, all you need to do is set your firewall to drop all ICMP packets. Theoretically, someone could exploit this over TCP, but because TCP allows piggybacking, and because it generally has more overhead than simple ICMP packets, it's unlikely that you can easily trick a remote system to respond with a TCP packet that's less than 48 bytes.

      And by the way, if you use Mandrake Linux and the firewall software that ships with it, Shorewall (basically a collection of iptables rules), ICMP packets are already being dropped when they reach your system.
      • Re:well (Score:3, Informative)

        by Ivan Raikov ( 521143 )
        What I wrote was wrong. ICMP is a necessary part of the IP protocol, so you can't really block all ICMP message. My firewall only drops ICMP Echo and Echo Reply packets, which are used by ping.
        • Re:well (Score:3, Informative)

          by Corgha ( 60478 )
          It's also wrong because this bug is in ethernet frame padding, not in IP padding. Your firewall shouldn't be leaking that layer 2 stuff anyway -- this is only exploitable on the local network. Now, if your firewall also has this bug, it could leak data to machines on the network segment of its external interface, but that's another matter, and an attacker a few hops away isn't likely to get anything useful.

          From the initial @stake advisory:
          It is important to note that the attacker must be on the same ethernet network as the vulnerable machine to receive the ethernet frames.
    • Re:well (Score:3, Insightful)

      by labratuk ( 204918 )
      ...I can't imagine every manufacturer of every card is going to fix this....

      And hence one of the greatnesses of open source. We don't have to wait for them to do it. Someone can go in and clear up the issue in all the Ethernet drivers just like that. No muss, no fuss. Fixed drivers.

  • CERT link (Score:4, Informative)

    by Jan-Pascal ( 21029 ) on Thursday January 09, 2003 @08:17AM (#5046156) Homepage
    You can find the CERT's take on this here:
    http://www.kb.cert.org/vuls/id/412115 [cert.org].
  • common fault (Score:5, Informative)

    by oliverthered ( 187439 ) <(oliverthered) (at) (hotmail.com)> on Thursday January 09, 2003 @08:18AM (#5046159) Journal
    Lots of applications have the same fault, e.g. Microsoft Access doesn't appear to memset so you get what ever happens to be kicking around in memory written to emptyness in the database.
    Also Access doesn't clean out deleted data.
  • Wow.. (Score:2, Funny)

    by brandonsr ( 550431 )
    Hey, that's super uhh.. Does slashdot broadcast my IP?
    • Re:Wow.. (Score:5, Informative)

      by NuMessiah ( 7486 ) on Thursday January 09, 2003 @08:31AM (#5046198) Journal
      Well, we are speaking about the ethernet packets here. As soon as the packet hits the router or bridge only the IP (or ICMP ...) protocol partition is transferred. So this bug actualy can't be globaly exploited, only within the switched eternet networks.


      • Re:Wow.. (Score:4, Informative)

        by Large Green Mallard ( 31462 ) <lgm@theducks.org> on Thursday January 09, 2003 @08:54AM (#5046292) Homepage
        Close. Hits a router, or something routing (ie a PC) and the ethernet frame becomes just another TCP/IP packet.

        A bridge doesn't route, it only segments ethernet segments and reduces the amount of traffic going to the section it is in front of.
      • Re:Wow.. (Score:2, Insightful)

        by Anonymous Coward
        ...Yes, so exactly how dangerous is this? If you're on the same segment, you can sniff everyone's traffic anyway... all it does is extend some fairly lame (gotta-get-lucky) sniffability across switches.

        A lame bug, but at least not a very exploitably-useful one.
      • Re:Wow.. (Score:2, Insightful)

        by NuMessiah ( 7486 )
        Oh, I hate when I have to reply to myself, but what a heck ... ;) ...

        So, even if we are on the ethernet switched network the window-of-oportunity to actualy sniff some data is 46 - 28 = 18 bytes (46 for the minimum ethernet packet and 28 for the minimum ICMP echo reply data within it). So we can intercept 18 bytes of random data from ethernet stack. What are the chances that there is some interesting data (passwords, keys ...) within it? Slim, it seems to me ...

        Furthermore the traffic can be encrypted in case of VLANs, Tuneling or ssh-ed connections.

        Anyway, why should we inspect mere 18 bytes of provoked packet (yes, we have to provoke the ICMP echo reply packet so it can be transfered to our NIC directly) data when we are directly on the ethernet segment? In this case it is enough to bump the NIC to promiscous mode and to read all the data we can get from the segment :) ...

        Well IMHO there is a lot more interesting data in (TCP|UDP)/IP packets then in some 18 byte buffer crap at the end of ICPM echo reply ethernet packet.

  • by tomlouie ( 264519 ) on Thursday January 09, 2003 @08:23AM (#5046176) Homepage
    Here's a link to the original article:

    http://www.atstake.com/research/advisories/2003/ at stake_etherleak_report.pdf

    Here's a link to the CERT notice:


    Both articles have more info than the article that was posted for this story. Silly rabbit.


  • I can read! (Score:5, Interesting)

    by 1010011010 ( 53039 ) on Thursday January 09, 2003 @08:24AM (#5046179) Homepage

    "This information leakage vulnerability is trivial to exploit and has potentially devastating consequences. Several different variants of this implementation flaw result in this vulnerability," the @stake researchers wrote in their paper on the flaw, released Monday. "The Linux, NetBSD and Microsoft Windows operating systems are known to have vulnerable link layer implementations, and it is extremely likely that other operating systems are also affected."

    The most likely exploitation of the vulnerability would be for an attacker to send ICMP (Internet Control Messaging Protocol) echo requests to a vulnerable machine. The machine would then send back replies containing portions of the device's memory. In tests, the researchers found that most often the pad data sent in error contains portions of network traffic that the vulnerable device is handling.
    ... how much? The pad of older data in a 46 byte header can't contain a lot of data.
    • SSH (Score:3, Insightful)

      by mmol_6453 ( 231450 )
      It could be enough for someone to snag the SSH private keys for a connection.

      Of course, since you have to read ethernet packets, they'd either be listening to traffic on a VPN, or they'd be on their target's LAN.

      More reasons to be afraid of your company's BOFH.
      • Re:SSH (Score:5, Informative)

        by 42forty-two42 ( 532340 ) <`bdonlan' `at' `gmail.com'> on Thursday January 09, 2003 @08:45AM (#5046248) Homepage Journal
        It can't sniff SSH keys from that; SSH is secure even if you sniff *all* packets.
        • Re:SSH (Score:5, Informative)

          by Tom ( 822 ) on Thursday January 09, 2003 @10:11AM (#5046760) Homepage Journal
          Wrong topic. This isn't about sniffing the SSH traffic, it's about sniffing the memory of the machine, which can well contain the key.
          Your hit-chance is pretty bad, though.
          • Re:SSH (Score:3, Informative)

            by ehiris ( 214677 )
            It reads the static memory allocated to the driver or other dynamic kernel memory. It is highly unlikely for the full SSH private key to be there but there is a small chance since the threads are being run in a pretty close time frame apart. Actually it also depends how large your key is and how much data is in the ICMP package. It is 8* more likely to retrieve a 128 bit SSL private key then there is to retrieve an 1024 bit SSH private key.
            I'd be more worried about secure credit card transactions on web servers that don't get patched soon and don't renew their private keys.
      • Re:SSH (Score:5, Informative)

        by thing12 ( 45050 ) on Thursday January 09, 2003 @09:31AM (#5046502) Homepage
        It could be enough for someone to snag the SSH private keys for a connection.

        No, the SSH private keys are never in an ethernet packet to begin with. You can only get information from the target system that it a) has already sent somewhere else; b) got from a pool of free memory and then sent you packet with fewer than 46 bytes of data in it (i.e. ICMP). I find it hard to believe that this is remotely useful since you only get up to 46 bytes - so your ssh key would have to be in a block of memory that had been deallocated back to the kernel memory pool - and the ethernet driver has to be lucky enough to then allocate that memory when it needed more buffer. But why would it need to allocate more buffer when all you're asking from it is a packet that contains less than 46 bytes?

        The idea that it's a useful exploit from that standpoint that you can read a remote systems memory is a bit preposterous. It all seems like it requires a coincidence on the order of planetary alignment for any valuable information to be extracted from this bug. Yes, you can grab parts of previously sent packets - but in a world where all sensitive information is encrypted prior to transmission this flaw is just moot. Fix it, move on, nothing to see here.

      • Re:SSH (Score:4, Insightful)

        by Daniel Phillips ( 238627 ) on Thursday January 09, 2003 @09:54AM (#5046646)
        It could be enough for someone to snag the SSH private keys for a connection.

        The chance of fishing a usable key out of 256 Meg of memory soup, given a random look at a handful of leaking bytes in each packet, is slim indeed. The attacker has no way to control which bytes leak and doesn't know where in memory they came from. This is nothing remotely as serious as a buffer overflow, where the attacker gets to choose which bytes overflow into executable memory, and thus can exercise a great deal of control. Still, by sitting and watching long enough, maybe, just maybe the attacker will be able to piece together something useful.

        Now, this is where Linux, BSD et al really show show their strength: this driver leak either has already been patched (sorry, I'm too lazy to check the change logs just now) or will be by the end of the day, and the patched kernel will be immediately available for download. Or I can get the patch and apply it myself if I'm in a panic (which I'm not for the above reasons).

        Microsoft on the other hand has to round up dozens of vendors and get them all to apply fixes, and there will be stragglers. Then there is the question of how to get the patches onto customer's machines. It's a safe bet that the majority of home users will never patch this vulnerability, so if attackers need plenty of time to exploit the leak on Windows, they've got it.

        Of course, Microsoft's favored solution to the latter problem is to take the liberty of patching your system for you, having required you to agree to this when you installed. You must then trust Microsof not to go further and install additional, unasked-for code, for example, something to send back all your web search terms to Microsoft HQ. [theregister.co.uk] I don't know about you, but for me, but that's too high an asking price for automatic security updates.
        • Microsoft on the other hand has to round up dozens of vendors and get them all to apply fixes, and there will be stragglers. Then there is the question of how to get the patches onto customer's machines.

          Don't forget that after the vendors fixed it, the new drivers have to be re-certified and signed by Microsoft or their Great OSes[tm] will bark on everyone installing them - which wouldn't shine a bright light on the vendor.

          Last thing I remember was that having a new driver certified by Microsoft takes several weeks to months.

          An interesting question aside: If so many drivers (if you believe in the article's wording) are affected, why did they pass the Microsoft quality/security "certification" in the first place?

          Seems to me that their certification tests aren't worth the bits they're written on - probably they just check that the drivers don't crash the system and so on. (well, and sometimes, not even this.)

    • Re:I can read! (Score:5, Informative)

      by Raphael ( 18701 ) on Thursday January 09, 2003 @08:55AM (#5046294) Homepage Journal
      The pad of older data in a 46 byte header can't contain a lot of data.

      In addition, you also have to be able to get this data. As mentioned by mmol_6453, you can only get the Ethernet frames if you are on the same LAN or if the victim is tunneling the Ethernet frames through a VPN. If there is an IP router between you and the victim, you will probably not be able to get the leaked bytes (and I am glad to see that several routers listed in the CERT advisory [cert.org] are not vulnerable).

      The advisory says: "the leaked information may originate from dynamic kernel memory, from static system memory allocated to the device driver, or from a hardware buffer located on the network interface card.". If you are using a broadcast Ethernet medium, then the leaked information collected from the static memory of the device driver or from the hardware buffer on the NIC will probably be much less than what could be collected by running a packet sniffer on the same Ethernet segment, because the leaked bytes will come from previous packets. However, this is different if you are running a switched Ethernet network (not broadcast) because the packet sniffers are less useful in this case.

      As I see it, the only real potential for information leakage comes from the device drivers that are leaking bytes from the dynamically allocated kernel memory. Then you could get almost anything from that machine, not only something that is supposed to be sent over the network. On the other hand, it is probably very hard to predict what will be leaked.

      It would be interesting if the advisory could give a list of operating systems that are leaking random information from the kernel versus those that are leaking information from the previous packets (in the driver or in the NIC). I would be more worried about the former than the latter.

      • Re:I can read! (Score:5, Insightful)

        by fucksl4shd0t ( 630000 ) on Thursday January 09, 2003 @09:40AM (#5046548) Homepage Journal

        On top of this, and everybody seems to be ignoring this basic fact, but after you get up to 18 bytes of information out of an ethernet packet, you *still* have to chain enough of these together to be a useful chunk of data. The problem drops significantly when you add more machines to the network, because it gets steadily harder and harder to put them together in order from the same machine. (Yeah, I know, you can use the mac or IP address to chain them together, but ethernet allows out-of-order packet delivery)

    • Re:I can read! (Score:5, Interesting)

      by thogard ( 43403 ) on Thursday January 09, 2003 @10:28AM (#5046870) Homepage
      I can sniff most low end cicso switches....
      The 2924xl and 2950 allow you to block any mac address except broadcast addresses. So if you you flood the network with packets with one broadcast address and one real mac address you overflow its table it goes into a nice bridge mode. With a decent box it takes nearly two whole minutes to crack a single vendors mac codes.

      As long as US compaines keep selling out to the short term stock price and sending critical stuff off 1/2 way around the world to be designed by people with no clue about real security, their products are going to be crap and full of holes. At one point I could trust Cisco and Sun but now they are almost at the level of most beige box builders but with them I know who I can go visit to get my money back.

      All the new gear I've been buying is Kiwi designed stuff made by ATI. After a decade of dealing with cisco, I can't recomend any of their newer gear. the Current cisco mac address overflow was fixed by real engineers back in 1993. I'm not sure what kind of idiots they get to write their current code since bug history means nothing to them.

      Why don't I put this on bugtraq and get it fixed? Its simple, The idiots that put the bug together have good jobs and the good people that know this stuff don't because of cost cutting.
  • by Arethan ( 223197 ) on Thursday January 09, 2003 @08:25AM (#5046182) Journal
    If this bugs you, just make a change to the link layer drivers. Pad with nuls again, like it is supposed to, rather than garbage data. The downside to this is there will be a speed hit, since you are wasting time fscking with small packets to make sure they are secured. But, given the speed of modern systems vs the speed of ethernet, I highly doubt you'll notice.

    Honestly, the big problem here is going to be MS. I doubt they'll introduce a fix at all.
    • Read the CERT advisory:

      Microsoft Corporation Not Vulnerable 3-Jan-2003

      So are they such the big problem you thought they were going to be?
    • Microsoft does not ship any drivers that contain the vulnerability. However, we have found samples in our documentation that, when compiled without alteration, could yield a driver that could contain this issue. We have made corrections to the samples in our documentation, and will include tests for this issue in our certification process. From Cert Site...
  • Details from @stake (Score:5, Informative)

    by Unfallen ( 114859 ) on Thursday January 09, 2003 @08:31AM (#5046200) Homepage
    • by 1010011010 ( 53039 ) on Thursday January 09, 2003 @08:44AM (#5046247) Homepage
      So, @Stake is just figuring this out [google.com], eh?

      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) {
      val = 30000000; // ~ 30 M
      ptr = (char *)malloc(val);

      memset(ptr, 0x41, val-1);
      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 ->
      ICMP TTL:255 TOS:0xC0 ID:29812
      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 ->
      CMP TTL:255 TOS:0xC0 ID:31185
      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 < > 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

      I assume it would be any OS that includes more than the ip addresses/ports.

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

      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.
      ... from January, 2002.
      • I've found another similar vulnerability in Windows IP stack. I'm sure that I am not the first to discover this but, it has existed for a long time and has never been fixed. I have verified the vulnerability on all Windows platforms except XP, which I simply haven't bothered to look at.

        The "vulnerability" is very similar in behavior to the one described in the article but, is at the IP level rather than the link layer. The vulnerability has to do with padding of IP packets on Windows systems. Windows uses the contents of one of its buffers (sorry I can't say which one) to pad IP packets.

        This is very easily reproducable when sniffing ping packets. The data portion of the packets are padded with the contents of the buffer. There are other utilities that demonstrate this behavior as well, but it is most easily reproduced with a simple ping and the bigger the ping packet the more data you'll see.

        If you have been using IE and then sniff ping packets, you will see the data from your previous browsing. If you just logged in, you can sometimes find your password padding the ping packets.

        As I said I have verified this on all WIndows platforms except XP. I have also looked for it on numerous Linux platforms and have NOT found Linux to suffer the same vulnerability. That is, Linux does NOT appear vulnerable.
  • by FullClip ( 139644 ) on Thursday January 09, 2003 @08:31AM (#5046203)
    Oh my God, they were right all along ;)
  • deja vu..... (Score:3, Informative)

    by taviso ( 566920 ) on Thursday January 09, 2003 @08:32AM (#5046207) Homepage
    here [google.com] is a bugtraq thread from a year ago, describing a similar sounding problem...
    • Re:deja vu..... (Score:3, Informative)

      by Russ Nelson ( 33911 )
      a year ago?? You're kidding. This problem has been well-known for at least fifteen years. But given that passwords have been floating around in the clear (telnet, pop3, imap), why bother securing random contents of memory? Remember, you've got to be on the same Ethernet to exploit this.
  • by Anonymous Coward on Thursday January 09, 2003 @08:33AM (#5046211)
    Just tested this with Ethereal on W2K.

    The command 'ping -n 10 -l 1472 ' sends a packet that's padded with 'abcd...uvwabcd...uvwabcd'.

    The echo reply is padded with the same characters, apparently just pulled from the request and stuck in the reply. So far I've tried pinging W2K, HPUX, a Cisco router, and a Debian box. All return the contents of the initial request as padding.

    Is there more to replicating this than they let on? Or are they just full of poop?

    • You can't use ping, because ping's job is to echo back what you sent. It should fill the packet.

    • by gclef ( 96311 ) on Thursday January 09, 2003 @10:14AM (#5046780)
      Read the advisory. The problem they're highlighting involves breaking the standard a bit.

      What you do is send an ethernet frame that is too small by the standard's requirements. The reply will come back padded to meet the minimum size requirement. Where the padding comes from is apparently the problem...apparently it's just malloc'd, not cleared in any way.

      This means, for one thing, that you have to be on the local LAN with your target, since any routing of the packet will re-write the ethernet header, blowing away your sneakiness. It also means that standard ping won't do. You have to be able to break the rules for ethernet to see the effect.
  • OpenBSD (Score:3, Funny)

    by Talisman ( 39902 ) on Thursday January 09, 2003 @08:39AM (#5046233) Homepage
    Now OpenBSD will have to change their tagline, again.

    Only one remote hole in the default install, in more than 7 years! Oh yeah, and 1 hole embedded in the Ethernet dri...

    "Shit. We ran out of space on the CD cover."


    Wanna get pissed? [remail.org]

  • by Dwonis ( 52652 ) on Thursday January 09, 2003 @08:43AM (#5046243)
    Why is this "devastating"? People can sniff ethernet networks anyway? People don't rely solely on a switch for your network security, right?? (Who am I kidding? Of course someone does. Sigh.)
  • by somethingwicked ( 260651 ) on Thursday January 09, 2003 @08:49AM (#5046271)
    "Since they don't specify the OS, I'm assuming these are drivers for Windows."

    Funny, I am careful about checking my facts, and I am assuming that only 5 people will read my post. I would hope I would put a LITTLE more effort into my fact checking tho if I thought it was going to get 1,000,000 hits.

    Since the poster and the editors don't check their facts, I am assuming they don't.

    Slashdot is the first site I hit for tech info. And typically, while exagerrated, the attacks on MS have basis at least.

    But an ASSUMPTION like above about "Well, there's a problem, it must be Windows!" just makes my ears perk up immediately and want to check the facts. Why doesn't it for the Slashdot editors?

    WHY would you assume that? Just from the blurb the poster included it immediately seems the kind of oversight that would have the POTENTIAL at least to affect multiple systems.

    And yes, I realize that Windows drivers written by third-parties have been targetted, I find it amazingly amusing the native Windows drivers have been determined not to have this issue

    • WHY would you assume that?

      • Because it's often true, especially for remote-root class exploits
      • Because it gets a rise from their audience
      • Because the editors are too outright lazy toi actually spend 30 seconds with Google, CERT etc checking

      Just a guess...
  • There actual advisory from @stake [atstake.com] that the article quotes can be found here [atstake.com] - it's got a few more technical details and code fragments from the Linux kernel, but there's not really much else to say.

    It also shows sample frame captures illustrating leakage of HTTP traffic.
  • by Satoshi Harada ( 634776 ) on Thursday January 09, 2003 @08:53AM (#5046284)
    At least it isn't a dupe...
  • Good gods, RTFA (Score:2, Insightful)

    by Kourino ( 206616 )

    The article submitters now can't be bothered to read the articles? You know, the bit in the article where it says "The Linux, NetBSD and Microsoft Windows operating systems are known to have vulnerable link layer implementations, and it is extremely likely that other operating systems are also affected."!?

    Back to more important issues, like the actual content of the article ... I'm reading linux/net right now, anyone have any definite answers, and could point me to (say) source for where we do do this?

  • by Anonymous Coward on Thursday January 09, 2003 @09:04AM (#5046335)
    Great. I don't mean to sound like a troll, but @stake is really stretching for publicity here. 46 bytes? Do you realize how small the padding is? Yes, it's enough for a password, but keep in mind, that padding being sent out is transmitted from OLD FRAMES. These items have been transmitted before. Guess what kids? If you observe secure computing practices, such as using a encrypted login method (ssh comes to mind) and you mind your standard p's and q's, this problem should never be a PROBLEM. I am sorry, but as a professional that researches this stuff, I have to rate this vulnerability as a "really really low" and keep plugging on. In a perfect world, we would grab from urandom/random/null but this isn't a perfect world. Lets focus on remote root compromises, remote "system/admin" compromises, and lets also focus on getting IIS away from the industry. These are the REAL problems. Someone wake me up when @stake has a real advisory to give, something excellent that we are used to seeing from them, besides this trivial fluff they are going to over-hype.

    Mod me however you want, I'm a coward to /. but this will be the same position I give the Fortune 500 company I work for. /me wonders if my VP will mod me "troll" or "flamebait" =P
  • by dcs ( 42578 ) on Thursday January 09, 2003 @09:06AM (#5046349)
    RFC1042 says "When necessary, the data field should be padded (with octets of zero)to meet the IEEE 802 minimum frame size requirements."

    RFC 2119 says "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
  • I am not a security expert. In fact, my knowledge comes from Slashdot. So God help me. But is this vulnerability really useful to a hacker? If I understand it, because padding is not properly implemented, the hacker MAY receive some random data at the end of the 48 byte data. I realize there are people who have the patience to tape together shredded documents so they can read them, but in this case the hacker cannot ensure that the random pieces of data that he will receive even belong to a single "document." So my question, is this a theorectical vulnerability that would be extremely difficult to use, or is it demonstratable that a hacker could easily obtain useful information?
  • by heikkile ( 111814 ) on Thursday January 09, 2003 @09:10AM (#5046374) Homepage
    It is a flaw alright, but I fail to see it as very serious. It is not a remote exploit, nor a local one. It leaks basically random bytes from the memory, without telling where in the memory they come from, and without any way for the attacker to specify where in the memory he wants to read. So, yes, there could be a password in it, but there could as well be a snippet of executable code or binary data, or whatever. It would take a lot of sniffing of these, and a lot of filtering, before anything useful would come out of it.

    I am sure someone will rush to correct me if I am wrong about this.

    • So, yes, there could be a password in it, but there could as well be a snippet of executable code or binary data, or whatever.

      No! It would most likely be data from some other packet that was sent or received previously. The OS doesn't allocate network buffers willy-nilly, it tries to reuse the buffers if possible. This means the memory used to send a short packet is most likely going to be reused from a previous network buffer. Meaning the data out on the wire is probably going to be someone else's network traffic that you shouldn't have seen.

      I agree that the problem would be much less severe if you really were getting bytes from random spots in memory, but that isn't what happens. Operating systems tend to allocate a big chunk of memory for buffers, then reuse it over and over.

  • What makes you think this topic was an accident? I have a hunch that the /. editors posted this as an anti-microsoft blurb on purpose. With that in mind they didn't need to read the stinking article.

    If you look at recent "environmental" "news" they've put up on here they've done the same sort of thing: did not read the target article or totally disregarded it and added their own political opinion.

    Hemos has an anti-Microsoft axe to grind. Not that I blame him there but I think he's a wee bit too eager.

  • by rmckeethen ( 130580 ) on Thursday January 09, 2003 @09:40AM (#5046550)

    Consider the length of time this so-called vulnerability has lurked in the device driver code for all those operating systems, than ask why no one discovered the problem sooner. Could it be that there's nothing to be worried about?

    I'm guessing this problem has gone undetected so long because uber-short frames don't naturally occur on most Ethernet installations. Networks typically send real data, not empty frames, that's why we build them in the first place. You have to intentionally generate super-small frames if you want to see them. All the examples @Stake provides are based on ICMP Echo/Echo Replies, where you can specify the packet length at the command line. Show me some real network traffic that exhibits this problem, than I'll start to worry.

    Still not convinced? Well, consider that you can't exploit the issue beyond even a single router, and that the vulnerability in most cases is just rehashed data, stuff that's already gone out on the wire. How big a security issue is that? Seems like the least of my problems. I'd worry more about one un-patched system on the network or one stupid marketroid opening a TELNET secession to the web server than I'd worry about this.

    I'm going to go out on a limb here and declare this a non-issue. I'm sure the guys over at @Stake are happy to have something to show their bosses (and the media) so soon after the holidays, but it just doesn't look very serious from where I'm sitting.

  • by martin ( 1336 ) <maxsec@gm[ ].com ['ail' in gap]> on Thursday January 09, 2003 @09:50AM (#5046620) Journal
    The firm I was workign for at the time noticed this 6 years ago on AIX.

    We informed CERT/IBM - nothing happened.

    NOW it it makes all the headlines.

    what impact does it have - none, unless the stuff in the PADing area contains the unencrypted data that was originally send encryped. Or am I missing something like I normally do?
  • by gorjusborg ( 603799 ) on Thursday January 09, 2003 @09:56AM (#5046663) Journal
    Ever written a C program in windows and pooched the pointer arithmetic??

    Ever print the results to the screen??

    If you have, you know that garbage comes out, and is pretty much undecipherable. The reason it is not readable is that the the program is interpreting each byte as a character, and the data is most likely not ASCII.

    This is an analog to what is happening with these "bad" drivers. The driver is simply reading more memory than contains actual data, and sending it along with the good data, since the receiving station will strip off the padding (bad data) it shouldn't matter. What the author of the article is implying is that someone might spend the time to try to decipher the padding and find sensitive data from your system. Good luck to any person who wishes to decipher almost randomly sampled data from a memory map. They will have the same problem as the C program mentioned above: they will have no clue how to interpret the data, and will have to trial and error "known" data types. Even then, they only get 45 bytes of data to use as context. So even if they got ASCII characters, how are they to know if it is a password or part of a Gnumeric spreadsheet??
  • by Scratch-O-Matic ( 245992 ) on Thursday January 09, 2003 @10:05AM (#5046729)
    my computer is broadcasting an internet IP address, enabling hackers to attack my computer immediately! I wonder if this is also related to my internet connection not being optimized?
  • tips (Score:3, Insightful)

    by stinky wizzleteats ( 552063 ) on Thursday January 09, 2003 @10:10AM (#5046757) Homepage Journal

    Wow. This is pretty hardcore, especially for networking devices. My biggest fear related to this has to do with the increasing use of VLANs to bound logical security zones. Let's say port 1 and 8 are on different VLANs - 1 is in the private network, 8 is in the DMZ. They use the same ASIC, so padding data is effectively shared between both. You've already owned a DMZ host, so you can use it to listen to ethernet padding data that might contain traffic once transacted on port 1. Listen long enough, and you might get some juicy passwords otherwise invisible to the DMZ.

    No guarantees, but until we get updated drivers, put in a snort rule for undersized packets flying around in your public networks, and make sure your VLAN boundaries occur on port group boundaries (Most Nortel switches, for example, have different ASICs for ports grouped physically on the front of the switch.)

  • 3Com/USR?... (Score:3, Interesting)

    by fudgefactor7 ( 581449 ) on Thursday January 09, 2003 @10:16AM (#5046790)
    WTF?! 3Com makes a buttload of cards, yet they're not even listed on that CERT list.
  • by corvi42 ( 235814 ) on Thursday January 09, 2003 @10:33AM (#5046906) Homepage Journal
    When I read articles like this it makes me feel... iln ?!?
  • by galego ( 110613 ) <jsnsotheracct&gmail,com> on Thursday January 09, 2003 @10:59AM (#5047104)
    What do you mean (ether:00:0a:83:56:04:7d) my NIC card (Full name: Jack B. Stupid) is broadcasting (SSN:123456789) sensitive information without me (birthdate:01-01-1965) knowing about it? My brother-in-law (my home phone: 555-444-3333) helped me install it and insured me (my cell phone: 666-555-4444) it was fine. He even installed a (paypal id/pwd: myemailaddress@mydomain.com/myPass) firewall to help protect my home network. I'll have to (send donations to:mybrotherinlaw@hisdomain.com) check with him though, and see what he knows about it.
  • Fixed in 2.4 (Score:3, Informative)

    by noselasd ( 594905 ) on Thursday January 09, 2003 @11:35AM (#5047405)
    http://linux.bkbits.com:8080/linux-2.4/ChangeSet@- 3d?nav=index.html You'll see Marcelo just commited fixes for heaps of network drivers from Alan Cox to the 2.4 tree.
  • This is silly. (Score:4, Informative)

    by Dagmar d'Surreal ( 5939 ) on Thursday January 09, 2003 @01:48PM (#5048437) Journal
    When I first saw this, I thought to myself, "Surely Steve Gibson's name is on the report somewhere" because this is the sort of lunacy one usually finds his name on.

    Much to my suprise, @Stake's name was on it. Looking further, I see that Eweek has genuinely made a mountain out of a molehill. Seventeen bytes of randomly chosen data can be snatched from a remote machine, provided it's literally in the same building as the attacker, and provided it's got a cheap-o network card. Pardon me while I quake in fear for the safety of the little children.

    Why do we have to be in the same building? Because if the packet in question goes through most routers, they're quite likely to crumple the bits up and throw them away because of it's past use as a means for covert communication. ...and while it's good that the memory leakage is of contiguous bytes (otherwise they'd be entirely useless) seventeen bytes is a _really_ small window for any meaningful data to come through. If you were lucky, you might be able to get part of a (presumeably encrypted) password, or two and a half words from a typical email. It's also possible that fancy arp-foolery would get you *all* the victim's network traffic, making it the long and obnoxious way to go about doing something as simple as sniffing packets.

    Their statement about it being "trivial to exploit" should have stopped at just saying it was "trivial". It was good of @Stake to bring this to the attention of programmers, although quite possibly publishing in PDF format made it look a little more important than it really is. ...What Eweek published about it was downright silly.

Whenever people agree with me, I always think I must be wrong. - Oscar Wilde