Slashdot Mirror

← Back to Stories (view on slashdot.org)

Flaw Found iIn Ethernet Device Drivers

Posted by Hemos on from the yay-for-security-bugs dept.

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.

26 of 390 comments (clear)

  1. Or maybe by Anonymous Coward · · Score: 5, Informative

    the flaws are in linux drivers too. Who knows, you might even want to read the article.

  2. Flaw Found iIn Slashdot Editors by Anonymous Coward · · Score: 5, Funny

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

  3. well by REBloomfield · · Score: 5, Interesting
    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?

  4. Re:You assume too much by GroovBird · · Score: 5, Informative

    In addition (I post too fast), the CERT has made available a list of vulnerable systems that they know of.
    Interesting fact: Microsoft Windows is mentioned as "not vulnerable".

  5. common fault by oliverthered · · Score: 5, Informative

    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.

    --
    thank God the internet isn't a human right.
  6. Not Exactly by starX · · Score: 5, Insightful

    The Cert advisory says that MS doesn't ship any drivers with this vulnerability. This is a lot different from saying that MS systems are completely uneffected. We're going to have all double check against the actual driver being used by the system (when this list is complete of course) to find out if we are particularly affected by this.

  7. I can read! by 1010011010 · · Score: 5, Interesting

    "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.
    --
    Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
    1. Re:I can read! by Raphael · · Score: 5, Informative
      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 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.

      --
      -Raphaël
    2. Re:I can read! by fucksl4shd0t · · Score: 5, Insightful

      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)

      --
      Like what I said? You might like my music
    3. Re:I can read! by thogard · · Score: 5, Interesting

      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.

  8. Details from @stake by Unfallen · · Score: 5, Informative

    @stake's advisory release:
    http://www.atstake.com/research/advisories/2003/a0 10603-1.txt

    And their etherleak report PDF:
    http://www.atstake.com/research/advisories/2003/at stake_etherleak_report.pdf

    1. Re:Details from @stake by 1010011010 · · Score: 5, Informative
      So, @Stake is just figuring this out, 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) {
      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 ip addresses/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.
      ... from January, 2002.
      --
      Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
  9. Your computer is broadcasting sensitive info ! by FullClip · · Score: 5, Funny

    Oh my God, they were right all along ;)

  10. Re:SSH by 42forty-two42 · · Score: 5, Informative

    It can't sniff SSH keys from that; SSH is secure even if you sniff *all* packets.

  11. Slashdotted your credibility-and everyone sees it by somethingwicked · · Score: 5, Interesting
    "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

    --

    ---"What did I say that sounded like 'Tell me about your day?'"---

  12. Re:You assume too much by the_mice · · Score: 5, Insightful
    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...
  13. Oh god, lets hype it all up by Anonymous Coward · · Score: 5, Insightful

    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

  14. The drivers comply with the RFC by dcs · · Score: 5, Informative

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

    --
    (8-DCS)
  15. Looks pretty harmless by heikkile · · Score: 5, Insightful
    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.

    --

    In Murphy We Turst

  16. Cisco isn't vulnerable: by Ayanami+Rei · · Score: 5, Informative

    Cisco's Status/Statement
    and
    Full CERT Advisory

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
  17. Re:SSH by thing12 · · Score: 5, Informative
    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.

  18. This flaw is a non-issue by rmckeethen · · Score: 5, Informative

    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.

  19. Re:Or maybe Slashdot wont post news unless its ant by Michalson · · Score: 5, Insightful
    While not 100% true I do see truth in that. For anything to get on the front page these days it seems to require at least one of the following:
    • Microsoft is bad, we don't know why, but it is
    • Another article just like it is already on the frontpage
    • The Poster has provided enough FUD about the article to fill a landfill
    • Someone got arrested in the vicinity of a tech company. IT MUST BE A THREAT TO OUR RIGHTS!
    • Crazy, unsupported rumor. Likely about Apple.
  20. noticed this 6 years ago by martin · · Score: 5, Interesting

    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?

  21. Re:SSH by Tom · · Score: 5, Informative

    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.

    --
    Assorted stuff I do sometimes: Lemuria.org
  22. Re:Slow newsday for eweek then. by gclef · · Score: 5, Informative

    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.