Slashdot Mirror
Flaw Found iIn Ethernet Device Drivers
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.
the flaws are in linux drivers too. Who knows, you might even want to read the article.
Straight from the article
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.
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."
One wonders whether it would be possible to build a fix into the operating system, or would that be too great an abstraction?
You can find the CERT's take on this here:
http://www.kb.cert.org/vuls/id/412115.
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".
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.
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.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
@stake's advisory release:0 10603-1.txt
t stake_etherleak_report.pdf
http://www.atstake.com/research/advisories/2003/a
And their etherleak report PDF:
http://www.atstake.com/research/advisories/2003/a
Oh my God, they were right all along ;)
It can't sniff SSH keys from that; SSH is secure even if you sniff *all* packets.
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?'"---
At least it isn't a dupe...
Error:
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.
/. 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
Mod me however you want, I'm a coward to
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)
I am sure someone will rush to correct me if I am wrong about this.
In Murphy We Turst
Cisco's Status/Statement
and
Full CERT Advisory
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Great, first we had users who posted replies without reading the articles.
Then we had editors who posted articles without checking if they had already been posted.
Now we have users who submit articles that are neither read by the user nor the editor before being posted.
What's next? The person who writes the article doesn't read it before a user sees the link, submits it for an editor to post twice in the same day?
I'm a writer, a poet, a genius, I know it. I don't buy software, I grow it.
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.
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.
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?
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. I don't know about you, but for me, but that's too high an asking price for automatic security updates.
Have you got your LWN subscription yet?
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
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.
If you read the actual CERT Vulnerability note and seen that Windows is not vulnerable.
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.
...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.
...What Eweek published about it was downright silly.
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.
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.