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.

Comments

Hah!

[Anonymous Coward]

At least it didn't foil my first post.

Re:Hah!

[Jeremiah Cornelius]

I for one am G L A D that my local ILEC decided not to deliver Ethernet "to the curb"...

Besides, I couldn't make any sense out of BGP4 for Dummies !

Or maybe

[Anonymous Coward]

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

Re:Or maybe

[packeteer]

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

[ottawanker]

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

Re:Or maybe

[loply]

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

[Ashran]

A link from the article has a list of vulnerable vendors.
#
Quote

Microsoft Corporation Not Vulnerable 3-Jan-2003

Re:Or maybe

[Lt Razak]

Meanwhile... another story gets published without reading the source. Since they don't specify the site, I'm assuming this was Slashdot.

Re:Or maybe

[Anonymous Coward]

Exploitable drivers have been found for Windows, Linux, NetBSD...

OR MAYBE nobody bothered reading the CERT advisory?

The list of affected systems is clear enough:

Microsoft - NOT VULNERABLE

Re:Or maybe

[frp001]

One step futher: Given that Linux is GPL the flaw can be not only shown but demonstrated... given this is GPL I suppose we can expect a 2.4.21 or 22 to correct these flaws.

Re:Or maybe

[Anonymous Coward]

No drivers for network cards made by Microsoft were vulnerable... In other news, no cars made by Cisco has ever been stolen.

Re:Or maybe

[jericho4.0]

Where did you get that info? The cert advisory has a big list of vendors with 'uknown' beside them.

This doesn't look like the serious flaw it was posted as.

Re:Or maybe

[Anonymous Coward]

In most cases this works out to about a penny or less per email.

I'm sure that's what you *meant* to put in your sig, right? Oh hey, wait. Is that id= in the URL for a referral bonus? Oh, hey, you wouldn't be trying to make money by lying, would you?

Jackass.

Re:Or maybe

[Mithy]

Shame the guy at eWeek doesn't appear to have read the CERT advisory either. Next to "Microsoft Corporation", it says: "Not vulnerable". Though the situation surrounding third-party drivers for Microsoft OSes isn't made entirely clear.

Re:Or maybe

[Trolling4Dollars]

Can't get money without work. E-mail != work. Scumbag.

Re:Or maybe

[Anonymous Coward]

Sweet! My VMS/VAX is safe!

Re:Or maybe

[mentin]

The report at atstake has a demonstration of vulnerability using code taken from /usr/src/linux/drivers/net/atp.c with a note "atp.c is a Linux device driver for Ethernet adapters based on the RealTek RTL8002 and RTL8012 chipsets." So looks like Linux is (or was) vulnerable.

It is a shame none of Linux vendors provided their status. I am sure CERT notified them well in advance.

Re:Or maybe

[Anonymous Coward]

Microsoft Corporation, Not Vulnerable. There are no vulnerable Microsoft ethernet cards. It's just those pesky third-party ethernet cards that are vulnerable.

Re:Or maybe

[packeteer]

The Windows OS itself isn't vulnerable. Vunerabilities HAVE been found though for Windows drivers of certain manufactuers. One particular company can have vulnerabilities for many different OS's. When a company writes drivers for different OS's such as Windows and Linux they can share some of the code. If that code is vulnerable then all of the drivers are also vulnerable. This is not an OS issue at all.

Flaw found....

[Anonymous Coward]

...."iln" story title

You assume too much

[GroovBird]

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

Re:You assume too much

[GroovBird]

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

Re:You assume too much

[seosamh]

Yet according to the Cert list referenced in the article, MS Windows systems are not affected, and most Linux distros are listed as "unknown".

Re:You assume too much

[DanThe Bike]

From the CERT advisory though:

Microsoft Corporation Not Vulnerable 3-Jan-2003

The details would imply that windows is fine, but that some documented examples aren't.

Re:You assume too much

[nmg196]

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

Nick...

Re:You assume too much

[Anonymous Coward]

M$ is marked "not vulnerable", but that just means that they didn't write any of the device drivers for the affected cards. MS generally won't write device drivers, they'll leave that up to the manufacturers.

So here M$ gets look innocent and say, "It's nothing to do with us", while actually being guilty as sin for having an OS that uses loads of vulnerable drivers.

Easy!

Re:You assume too much

[the_mice]

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

Re:You assume too much

[Daniel Phillips]

Interesting fact: Microsoft Windows is mentioned as "not vulnerable".

You mean Microsoft said they aren't vulnerable. 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.

Re:You assume too much

[Anonymous Coward]

The conclusion being that you should use all development samples as a guideline and not a strict template.

Re:You assume too much

[Anonymous Coward]

Microsoft is listed as being "not vulnerable" because Microsoft says it is not. If you follow the CERT links down to that entry it says

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.

Apparently Microsoft publishes "sample" drivers...which hardware manufacturers might have used to create buggy drivers. (Anyone have a link to the relevant documentation?)

Re:You assume too much

[bastion_xx]

I thought the primary reason for code samples/examples was to assist a developer in understanding how to program for a particular function? The conclusion I would draw is that in this case, Microsoft have good system level developers.

I wonder if there are any sample code for creating Linux drivers that may also have this issue?

Re:You assume too much

[Anonymous Coward]

Uh, they're ALL "not vulnerable" or "unknown." Lots of help there, thanks CERT!

Re:You assume too much

[Kourino]

So here M$ gets look innocent and say, "It's nothing to do with us", while actually being guilty as sin for having an OS that uses loads of vulnerable drivers.

How is MS guilty for crappy code in other people's drivers now? They're not responsible for writing drivers for every single piece of hardware someone wants to run under Microsoft Windows. That would be the responsibility of the hardware vendors. ... and like it or not (and there are bits of the Win32 API I really do dislike), not all code that comes from Microsoft is utter crap with no redeeming qualities.

Oh, I really wish I could find a link to the Penny Arcade about "M$" right now too. :) Although I just realized I'm responding to an AC ...

Re:You assume too much

[Michalson]

I would make a more extensive reply, but you're an idiot so I won't waste all that time. Microsoft is not responsible for what 3rd party vendors produce. In order to be responsible in any way, they would have to implement a policy where by Microsoft inspects all source code for anything made for Windows, and only then "allow" it to be shipped. If Microsoft controlled developers like that I suspect you'd be doing a lot more kicking and screaming (and then you'd actually have a reason, rather than now when you *don't*).

Re:You assume too much

[Michalson]

Sample code is designed to be short and easily understandable, it's rarely designed to be production code. You are supposed to learn from sample code, not copy and paste it into your production code. Anyone stupid enough to do that deserves to get fired.

Now please, show me some (complete) sample code from any company that I *can't* rip apart for flaws.

Re:You assume too much

[tankbob]

Erm it doesn't say that the Microsoft Operating system is not vulnarable it says that their network cards are. The fault doesn't have to exist in software either, some vendors have the nic hardware constructing the packets and so no matter what os you are running you would be vulnerable.

Re:You assume too much

[lynx_user_abroad]

How is MS guilty for crappy code in other people's drivers now?

Microsoft became responsible for other people's code the moment they got into the business of signing other people's code.

If Microsoft wants me to believe that drivers which have been approved and signed by Microsoft are any more trustworthy than drivers which haven't been signed and approved by Microsoft, then Microsoft need to accept responsibility for ensuring that is the case.

You can't say "don't use that code, I haven't approved it. Use this one instead..." and then say "well it's not my fault if the code I demand you use is broken, I didn't write it!"

Re:You assume too much

[fucksl4shd0t]

Now please, show me some (complete) sample code from any company that I *can't* rip apart for flaws.

#include "stdio.h"

int main(void)
{
printf("Hello, World!\n");
}

This sample code is pulled from any company's literature that describes basic structure of a C/C++ application. (Ok, not all C++ books include this exact code, but I've seen it in a few of them)

Re:You assume too much

[Blkdeath]

Microsoft is not responsible for what 3rd party vendors produce. In order to be responsible in any way, they would have to implement a policy where by Microsoft inspects all source code for anything made for Windows, and only then "allow" it to be shipped.

Interesting; my threading layout had this post displayed right above yours. Between this and the "Don't trust us as a source of secure activex controls" fiasco - how are we expected to trust code they're certifying?

Me thinks it's time Microsoft got out of the signing business altogether. It's even giving them a bad rap.

Re:You assume too much

[Anonymous Coward]

You failed to return a value at the end if main() even though it is declared to return an int.

Re:You assume too much

[Anonymous Coward]

You're! a fucking! RETARD!

MS is 'guilty as sin' because hardware manufacturers write shoddy drivers for their products?

So wait. If *you* write some shoddy Linux drivers for your computer-controlled AssReamer2k Dildo, Linux "gets look innocent and say, "It's nothing to do with us", while actually being guilty as sin for having an OS that uses loads of vulnerable drivers."

Re:You assume too much

[thesadmac]

I'd agree with this guy. It's a little more of a sensible nit-pick than the other one.

Re:You assume too much

[RoundTop-VJAS]

That ain't C++, that's C.

jeez. get your languages right.

if it was C++ you would have things like "using namespace std;" and you would have used cout rather than printf.

Silly C programmers not doing it properly

Re:You assume too much

[Anonymous Coward]

You are supposed to learn from sample code

So what are you supposed to learn, how NOT to do it?

Re:You assume too much

[fucksl4shd0t]

Hey dude, go reread my post, and then I'll take out my "GNU C++" book and show you where in the first chapter that listing appears. :)

Then I'll take out my Borland C++ Builder in 21 days book and show you the same listing in the first chapter.

Then I'll take out my STL book and show you the same listing in the second chapter.

I know what the damn language is, and I know what shows up in the damn books. Just because that listing appears in a C++ book doesn't mean it's C++, and I don't recall saying it was.

Re:You assume too much

[pc486]

My Xircom CardBus Ethernet II (PC card) is vunerable on Windows2000 with the latest driver. So yes, Windows, more like the individual NIC drivers, is vunerable.

Here is the padding from one ICMP reply (1 byte data
was used in the ICMP echo request).

cf 1d 3e 59 0c 09 00 08 09 0a 0b 0c 0d 0e 0f 10 11

Re:You assume too much

[Anonymous Coward]

Windows NT zeroes all memory during allocation, so even if a driver is vulnerable, the only thing a driver can leak is information it previously had such as old packets (which could have been sniffed as easily as the padding can be sniffed). Inter-process leaking is impossible without a shared memory map.

Re:You assume too much

[Anonymous Coward]

Actually, any valid C code is also a valid C++ code, from what I understand.

Re:You assume too much

[pseudonymouse]

In my experience, example code is frequently copied from documentation and used as the foundation for production code, particularly in Microsoft shops. I have heard phrases like 'I just used the sample code' or 'Why don't you just copy from the example' many times, though to be fair the code generally gets reworked a little (to beef up error handling, for instance) after it's added. The programmers are assuming that the code was written to demonstrate correct usage, rather than simply to clarify some details of usage. Obviously Microsoft anticipates this reaction if they are now going back and correcting the code samples in their documentation.

The fact that Microsoft had code samples with this flaw suggests to me that it will be found repeated in many, many places.

Re:You assume too much

[UncleDavid]

How many people use printf() where puts() would do, just because K&R decided to do it the inefficient way?

(OK, if you want efficiency in a "production as opposed to sample" environment, you probably arrange things so that you can use write()).

Re:You assume too much

[spudgun]

I wonder if there are any sample code for creating Linux drivers that may also have this issue?

Chances are Yes , if one Driver is Incorrect then everyone copied it blindly the source IS the sample code. This is one problem with Open Source, that errors propogate everywhere if they are undetected.

Of Course once it is fixed in 1 place the fix is easier to propogate too.

Re:You assume too much

[RatBastard]

Considering that MS' TCP/IP stack is an implentation of the BSD stack, the fault does not lie with MS, but with the BSD stack. It is also important to note that MS fixed the problem in their sample code and said so.

I don't like Microsoft any more than most poeple, but can we please keep the MS bashing to valid points? Whenever you pound MS for spurious reasons you weaken any argument you may have against them. Why should anyone place any merit in your valid gripes if you spew so many without any merit?

Re:You assume too much

[pipacs]

Look for stdio.h in the standard places only:

#include <stdio.h>

Read the f*cking article.

[Alranor]

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.

Re:Read the f*cking article.

[Alranor]

Yup, when I saw that I did expect to lose karma on it, but hey, it's not my fault that the mods chose to favour me today :)

I could also point out that it's a little r i diculous that you misspelt a word you were quoting from my post, but that would be a bit pedantic, so I won't bother. :)

Re:Read the f*cking article.

[Daengbo]

Indeed. I'll simply claim that I have a cold or that I've been working a hundred hours a week and then crawl back to my hole.

Re:Read the f*cking article.

[fulgan]

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)

Re:Read the f*cking article.

[Anonymous Coward]

I get 5's often, almost always get moderated up atleast one point and only ever get moderated down if a speak realistically against the pseudo geek pop culture opinion (even though I've have internet access from home since 1991).

Goddamn, you've got a big penis, I wish I had a big penis, I only have a little penis, just a little penis, easy to clean but still far smaller than yours, probably takes a longer time to clean than mine as well, mine takes such a short time to clean, whereas yours is larger, and big, mmmmm so big.

Re:Read the f*cking article.

[Anonymous Coward]

mmmmm so big.

mmmmm is all you'll be saying, while you're cleaning it. Bitch.

Re:Read the f*cking article.

[Drakonian]

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?

Re:Read the f*cking article.

[WindBourne]

Read the Cert listing instead of trying to trust an editorial that is known for not getting it correct. Also read between the lines. What it says is that it is unknown as to how far ranging this is. I am sure that it is in MS. I am also sure that Linux, BSD, and unix have it as well. Why? becuase the drivers are routinely written by the same ppl.

Flaw Found iIn Slashdot Editors

[Anonymous Coward]

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

Re:Flaw Found iIn Slashdot Editors

[edbarrett]

iNo, iSee, iThis iIs iAnother iOf iThe iSlashdot iStory iAdvertisements iFor iApple.

Re:Flaw Found iIn Slashdot Editors

[Anonymous Coward]

you summed it up lovely

Re:Flaw Found iIn Slashdot Editors

[MamasGun]

Apple is vulnerable too...RTFA.

This one looks like it is really and truly cross-platform. FreeBSD, Linux and Mac seem to be affected, as are drivers written for Windows.

To be perfectly honest, this is not a vulnerability that sends chills down my spine. Sure, someone could snarf a packet or two, but the fact is, there is nothing on my system at home which I'd care about someone sniffing.

Now, if this allowed for remote sploits, running of arbitrary code, etc...then I'd be worried. However, if I had some big gnarly trade secrets on my network, I would be very worried about this.

Re:Flaw Found iIn Slashdot Editors

[Anonymous Coward]

Apple is vulnerable too...RTFA.

This was a joke...GAFSOH (Get A Fucking Sense Of Humor).

Re:Flaw Found iIn Slashdot Editors

[Anonymous Coward]

This was a joke...GAFSOH (Get A Fucking Sense Of Humor).

I'd advise you to learn to tell jokes that DFSLAGDVC (Don't Fucking Suck Like A God Damned Vacuum Cleaner).

well

[REBloomfield]

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

[AnEmbodiedMind]

Too great an abstraction?? If anything it would be removing abstraction...that of the driver OS kernel divide.

In anycase, trying to write a fix in the OS for a fault in some (many?) drivers wouldn't work as the fault is in (some of) the drivers behaviour...

Re:well

[lederhosen]

The device driver is a part of the OS and not the hardware...

Re:well

[REBloomfield]

I think i put it wrong :)

what i meant was, since the drivers sit on top of the OS, could a layer be put between them to prevent unfriendly calls being passed through, or would this simply not work due to directly accessinh hardware?

Re:well

[Anonymous Coward]

One wonders whether it would be possible to build a fix into the operating system

Speak for one's self, don't put words in one's mouth.

Re:well

[Ivan Raikov]

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

[Ivan Raikov]

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

[labratuk]

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

Re:well

[Corgha]

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

[indiigo]

Read up on how the OSI model works and then you'll have your answerg{!}g

Re:well

[Anonymous Coward]

interesting that you think that way... stupidest thing i've ever heard.. but interesting none the less.

I'm guessing you're aiming at Linux vs. Microsoft (in a general way - even though they don't necessarily make these ethernet drivers).

Someone can go in and clear up the issue - and this someone is...? maybe someone who doesn't know jack about the driver?

No muss, no fuss. Fixed drivers. - now what do you mean by fixed drivers? ones that are fixed to crash your computer? as far as i know, when Microsoft sees a bug like this, they fix it faster than you know about it. AND, they even know the correct way to fix it.

MOD ME DOWN! I DON'T HATE MICROSOFT.

Re:well

[evilviper]

I can't imagine every manufacturer of every card is going to fix this....

I hate the fact that there are a million different chipsets for every device. For network cards, I refuse to buy anything that isn't based on the TULIP chipset (which MANY are). The Tulip chipset has great performance, is very inexpensive (I can buy Linksys LNE100s in unlimited quantities at my local Best Buy for $15), and I have yet to experience a single one that doesn't work when I get it, and never misses a packet for years so far.

So, screw the vendors that don't want to write good drivers, and screw the vendors that want to sell their new chip for $1 less. I've standardized my systems (better than any Mac fanatic can claim theirs is) and I think everyone should do the same.

Re:well

[LegendLength]

In Windows it is not possible put a custom driver between a manufacturer's driver and their network adapter. It's only possible to put one between their driver and the system above (an NDIS Intermediate driver).

CERT link

[Jan-Pascal]

You can find the CERT's take on this here:
http://www.kb.cert.org/vuls/id/412115.

common fault

[oliverthered]

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.

Re:common fault

[PhilHibbs]

I was browsing around a Delphi executable file, and found a hod load of HTML that I had been working on earlier that day. The thing that pissed me off most was that all that junk that could have been zeros made the file less compressable than if it were, and we were distributing software over 19.2kbps serial connections at the time.

Re:common fault

[Anonymous Coward]

Someone once sent me a Word document, and I ran strings on it because I didn't have a *.doc viewer. Inside, I found several cookie strings for porn and banking sites.

Re:common fault

[Anonymous Coward]

Access cleans out the database when you compact it.

Re:common fault

[jeremyp]

The Word problem is far worse than that. The "fast save" facility just tacks amendments onto the end of the original document. you can often find earlier drafts of documents (or even completely different documents) by doing strings on them.

Nowadays I send all docs out in pdf format.

Re:common fault

[oliverthered]

Access re-creates the database when you compact it, it may still pad the database with crap instead of nulls

Re:common fault

[Dave Fiddes]

This is one of the reasons why you should always clear any memory in your program that contained passwords, encryption keys, etc after you have finished using them. That way you minimise the chance of it leaking out if there is a fault in your app, or another one if your OS doesn't zero memory before use by another program (Win95 doesn't but NT does(?)).

Re:common fault

[Anonymous Coward]

Not "packing" (which is the term when a filebased database doesn't immediately physically remove deleted records) is a very common occurance among filebased and ISAM databases. This isn't a flaw. If you want it removed, compact.

Re:common fault

[oliverthered]

the section could at least be wiped out with nulls, which is different from compacting.
Catalogue pages in access are 2k, there's not much overhead in writing 2K to the disk if your going to write a few bytes anyhow.

Re:common fault

[Anonymous Coward]

Also there is a flaw in access, when a block is initially written, the padding is whatever is in memory.

Re:common fault

[yuiop]

NT zeroes out all pages before it hands them to a process. One process cannot read the memory of another process, unless it has the debug privilege, or otherwise has some mutual facility such as shared memory.

Not Exactly

[starX]

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.

I can read!

[1010011010]

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

Re:I can read!

[Raphael]

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.

Re:I can read!

[fucksl4shd0t]

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!

[thogard]

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.

Re:I can read!

[quantum bit]

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.

That's because packet switching is intended to be a performance optimization, not a security measure . Ethernet, even switched ethernet does not guarantee that your packets are not sniffed. On routed networks, it's assumed that they will be seen at a minumum by the routers that the traffic goes through. If your application protocol depends on the lower levels being secure and unsniffable, then your application protocol is broken .

If anything, I think Cisco is doing the right thing by ensuring that the failure mode doesn't disrupt the network. Otherwise, filling up the MAC table would lead to a quick and easy DoS attack.

Don't mean to sound harsh but people need to realize that the RFCs that define these protocols (Ethernet/IP) explicitly state that security is the responsibility of the upper layers. That's why IPSEC was invented. I've seen many networks where the network "engineer" is relying on VLANs for a "secure" subnet. VLANs are another feature that was designed for convenience (segmenting broadcast domains for performance reasons) rather than security. Despite several band-aids to try to make VLANs security-conscious, it's still a bad idea to depend on them for that purpose.

Re:I can read!

[WindBourne]

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.
Actually, it would be easy to build a closed source device driver that would place a password in that area and send it out of a secured area. Becuase ppl have been sloppy, it is doubtful that the packets were checked in the pad area.

Re:I can read!

[Anonymous Coward]

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.

What exactly is it about being "1/2 way around the world" that reduces one's knowledge of security?

Re:I can read!

[karlm]

You may not need to chain several greoups of captured bytes together. You can use them as part of a dictionary for a hybrid password cracker.

Better yet, if you've got a pretty good idea that you have a password fragment (for instance, it's preceded by a known username and a colon), you've greatly reduced the password cracking effort. If you have a strong password, leaking 3 characters makes it about 300,000 times easier to crack.

According to the CERT...

[Anonymous Coward]

If you click a few links away (well, actually just one) you end up on http://www.kb.cert.org/vuls/id/412115 which states that Microsoft, CISCO and others are NOT Vulnerable, which is the exact opposite as what eweek says...

FUD ?

Not a hard fix for open source

[Arethan]

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.

Re:Not a hard fix for open source

[reanjr]

Obviously you've never had the opportunity to have Windows Update bother you whenever a fix is implemented.

Re:Not a hard fix for open source

[Anonymous Coward]

An interesting question is if they can even fix it since most ethernet drivers are after all third party drivers for windows. I can fix my card on my own using the source (linux), thank you very much.

Re:Not a hard fix for open source

[Richard_at_work]

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?

Re:Not a hard fix for open source

[Anonymous Coward]

Who writes the CERT advisories?

Re:Not a hard fix for open source

[AvidLinuxUser]

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

Re:Not a hard fix for open source

[David McBride]

Microsoft don't make network drivers -- they just distribute the drivers written by hardware manufacturers.

Hence, Microsoft can claim that all of their code is not vulnerable when Microsoft installations are not necessarily safe from this bug.

(Not knowing anything about MS's kernel implementation, it's possible that the reponsibility for padding null bytes falls to the kernel and not individual drivers, in which case they could fairly claim that MS installations are not affected.)

Re:Not a hard fix for open source

[Anonymous Coward]

Insightful? When was the last time you bough a Microsoft Ethernet card?

Re:Not a hard fix for open source

[MamasGun]

They do exist. In fact, MS has just recently gotten more heavily into networking hardware...particularly WiFi. Couldn't tell you if their stuff is good or bad, but it's out there.

When you assume...

[mightor]

Since the author has failed to specify the species he belongs to, I am assuming he is a lemur.

SSH

[mmol_6453]

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

[42forty-two42]

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

Re:SSH

[Large Green Mallard]

Be nice to us and we'll be nice to you.

It's common courtesy and will get you everywhere in life

Your friendly neighbourhood BOFH.

Re:SSH

[Anonymous Coward]

Surely the driver will only have access to the
kernel-side buffers? The private keys reside
strictly in user space.

ian

Re:SSH

[Anonymous Coward]

Surely the kernel is able to read all of memory without restriction.

Re:SSH

[Anonymous Coward]

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

Unless of course you are using SSH version 1 which is easily cracked. Check out ettercap for an SSH version 1 sniffer.

Re:SSH

[thing12]

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

[fucksl4shd0t]

Be nice to us and we'll be nice to you.

If I remember my childhood and early adulthood correctly, people have never been nice to geeks. Should we hold a grudge?

Re:SSH

[GrenDel Fuego]

The post about this on LKML indicates that the memory bits that end up getting sent out are typically snippets of network traffic.

So the chances of it getting a private key from user space are pretty slim.

The LKML post and Alan Cox's reply are available here:
http://www.lib.uaa.alaska.edu/linux-kernel/ archive /2003-Week-01/0821.html

Re:SSH

[Daniel Phillips]

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.

Re:SSH

[Tom]

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

[colinleroy]

I wonder how an ssh private key would get _in clear_ in the padding of a packet.
Do you really know any stupid enough people to ftp a private key ?

Re:SSH

[ryanvm]

It could be enough for someone to snag the SSH private keys for a connection.

How do you figure? Why would someone's NIC be broadcasting their private SSH key in the first place? It can only read information that was transmitted earlier.

Re:SSH

[Tom7]

I wouldn't say SSH1 is "easily cracked". All ettercap does is a man-in-the-middle attack, something which the default configuration of openssh, at least, provides a huge warning about.

That said, there have been a number of much worse bugs in openssh and other ssh implementations, mostly because they wrote them in C!

Re:SSH

[MamasGun]

I think that's his point exactly. The alpha geek in your company prolly had a miserable life at the hands of jocks and soshes...the kind of people who grow up to be company execs and marketdroids. BE NICE to your SysAdmin. Otherwise you might find yourself in a world of hurt, because s/he still has scores to settle.

Re:SSH

[Anonymous Coward]

up to 46 bytes of memory, which would usually be statically allocated, and reused for each packet, meaning that only the first packet would have random data, the rest would have data that was already transferred by the same card (or at least same driver = same brand of card).

Re:SSH

[fucksl4shd0t]

I think that's his point exactly. The alpha geek in your company prolly had a miserable life at the hands of jocks and soshes...the kind of people who grow up to be company execs and marketdroids. BE NICE to your SysAdmin. Otherwise you might find yourself in a world of hurt, because s/he still has scores to settle.

Here's some Voltaire at you:

Perhaps that's why the world we live in NOW is the way it is? Hint: Bill Gates was probably NOT a jock.

Re:SSH

[mmol_6453]

As other people have pointed out, I didn't know what I was talking about. I forgot that SSH transfered a public key from server to client, then the client would send a public key, encrypted, to the server.

Re:SSH

[WolfWithoutAClause]

No, the SSH private keys are never in an ethernet packet to begin with.

Actually they may end up in one, but it depends on the device driver and the SSH implementation, for, according to the CERT announcement:

"Depending upon the implementation of an affected device driver, 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."

Re:SSH

[ehiris]

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

[Anonymous Coward]

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.

...and you thought all those DDoS attacks were just an annoying bandwidth use...

Re:SSH

[chialea]

Hi Tom.

In addition to the implementation errors, of which we've seen flocks, there is some interesting information that can be gleaned from watching the timing of the packets. This however, is not exactly easy to fix in a robust and efficent manner.

Lea

Re:SSH

[doorbot.com]

This isn't about sniffing the SSH traffic, it's about sniffing the memory of the machine, which can well contain the key.

So a possible (temporary) solution would be to add more RAM? Maybe I can write that off as a business expense...

Details from @stake

[Unfallen]

@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

Re:Details from @stake

[1010011010]

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.

Re:Details from @stake

[ostiguy]

So what?

Disclaimer - I have no coding skills whatsover, but happened to have read the @stake thing two days ago.

You linked to a piece that is almost 1 year old. In your link, the guy proposes 4 solutions. Nearly 1 year later, @stake does some research, and finds > 20 linux drivers that still exhibit the problem. So, it is still a vulnerability / information leakage problem, regardless of past research in the subject - although you pointed out that people thought about it= no one has done anything, and @stake seems to believe that minor driver code tweaks can resolve the issue, as opposed to rejigging kernel mem operations ("could lead to a race though..." is BAD).

ostiguy

Re:Details from @stake

[Kourino]

("could lead to a race though..." is BAD)

Yes, but so is reading code comments out of context :) All "We have a race condition here" implies is that without proper locking or other handling, bad things might happen. If you actually read the code the comment talks about though, that code seems to deal with it.

Also, the kernel 8139 driver has some obscure note ("Note: the chip doesn't have auto-pad!") and writes (basically) the packet data length to some hardware register ... I wonder what that does. (Disclaimer, read the following paragraph; also, I don't know this driver or this hardware. I do use it though :3 )

Interestingly enough, I can't find the "We have a race condition" code doesn't exist in 2.4.18. Weren't they basing this off that kernel? If not, the file they link to off scyld.com in the PDF doesn't exist either ... hmmm. That code segment is a bit different in 2.4.18's rtl8139_start_xmit ... and lxr tells me that rtl8129_start_xmit doesn't exist.

Re:Details from @stake

[Anonymous Coward]

The call to lock in memory is mlock(), see the discussion about it on bugtraq just before christmas for more info.

Rich.

Your computer is broadcasting sensitive info !

[FullClip]

Oh my God, they were right all along ;)

deja vu.....

[taviso]

here is a bugtraq thread from a year ago, describing a similar sounding problem...

Re:deja vu.....

[Russ Nelson]

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

MS says that they are NOT vulnerable

[tetrode]

see: http://www.kb.cert.org/vuls/id/JPLA-5BGP7V

Mark

Slow newsday for eweek then.

[Anonymous Coward]

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?

Re:Slow newsday for eweek then.

[Anonymous Coward]

Oh, yeah, damn, Cert says its only on packets that need padding to make up the frame size. Duh.

Re:Slow newsday for eweek then.

[sboyko]

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

http://www.ietf.org/rfc/rfc0792.txt?number=0792

Re:Slow newsday for eweek then.

[gclef]

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.

Re:Slow newsday for eweek then.

[Russ Nelson]

When a packet is routed, there is no minimum Ethernet size involved, so the leaked data is not sent. That's not exactly what you said.
-russ

Re:Slow newsday for eweek then.

[gclef]

Not true. RFC 894 defines the minimum frame size for IP over Ethernet. It states:

The minimum length of the data field of a packet sent over an Ethernet is 46 octets. If necessary, the data field should be padded (with octets of zero) to meet the Ethernet minimum frame size.

Any device that's building Ethernet frames should follow the spec, and pad out packets to their proper size. So, if you send out an under-size packet that has to be routed, you'll get unpredictable results...1) your router may properly pad it with zeros, which destroys your attack...or 2) the router may give you bits of its memory, which isn't what the advisory was about, but could be interesting on its own.

Re:Slow newsday for eweek then.

[Russ Nelson]

WTF?? Packets that go over HDLC or PPP have no minimum frame size. When a packet gets routed, there are no "extra" bits. So this attack only works if you're on the same LAN.
-russ

Re:Slow newsday for eweek then.

[gclef]

I think we're talking past each other.

I'm assuming that the packets will traverse Ethernet at some point in their trip. For most networks, this is a fairly safe assumption. At the point where it moves onto the Ethernet segment the packet will be padded to the minimum size, and that will happen before it hits any server at the other end.

Re:Slow newsday for eweek then.

[Russ Nelson]

where it moves onto the Ethernet segment the packet will be padded to the minimum size

Yes, and if you're not ON that network, then you'll have no access to those bits. This attack only works if you have failed to secure your physical plant.
-russ

Or maybe

[forged]

or Cisco or every other router/switch vendor...

OpenBSD

[Talisman]

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

Talisman

Wanna get pissed?

Re:OpenBSD

[Anonymous Coward]

Before you start pissing you better check the code if there are any problems.

The fxp-driver does padding in hardware of small packets.

The Realtek driver has bzero() for the padding!

Re:OpenBSD

[Anonymous Coward]

problem is this isn't really an exploit. You could call it an unwanted release of mostly useless information that in no way compromises the system.

i agree that openbsd skirts around the truth, but this is a simple bug, no more.

Why is this "devastating"?

[Dwonis]

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

Re:Why is this "devastating"?

[gclef]

read the advisory.

This has nothing to do with sniffing your network. This has to do with your machine allowing an attacker read (admittedly small) segments of memory out of your system over the network. and no, a switch won't help anyway, since the whole idea is to ping the target, and look at its response.

Re:Why is this "devastating"?

[Dwonis]

Oh, I think I get it. If you had part of a PGP key in memory, then, later, that memory was used for the ethernet "frame buffer", then it might be leaked over the network.

It's still not a huge problem, since this attack can already be carried out locally (since malloc() doesn't clear memory), but I guess it does make things worse.

I'd hardly call it "devastating", though. Since most secure applications clear their memory before freeing it (I would hope).

Slashdotted your credibility-and everyone sees it

[somethingwicked]

"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

@stake Advisory

[semaj]

There actual advisory from @stake that the article quotes can be found here - 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.

Flaw Found iIn Slashdot News Title

[Satoshi Harada]

At least it isn't a dupe...

Re:Flaw Found iIn Slashdot News Title

[MullerMn]

At least it isn't a dupe...

Give it time.

Re:Flaw Found iIn Slashdot News Title

[PunchMonkey]

At least it isn't a dupe...

Just give it another 8 hours or so ;-)

Re:Flaw Found iIn Slashdot News Title

[LogicHoleFlaw]

What? I didn't do anything! Honest, officer!

Re:read it again

[Anonymous Coward]

"Interesting fallacy: Microsoft Windows is mentioned as "not vulnerable"."

It says Microsoft Corporation is not vulnerable, since they don't manufacture an ethernet card, this is not very surprising.

This is a problem with ethernet drivers not, and I repeat _not_, an Operating System problem.

At best all this says that all Microsoft written network drivers are not vulnerable. You will need to check the vendor of your network card, or the chipset manufacturer if you have a no name card, and there are reference drivers available.

Good gods, RTFA

[Kourino]

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?

The Nature of the CERT list

[dWhisper]

That list is pertaining to the Hardware manufacturers, and I would assume the OS integrated drivers. Even those are usually packaged in the OS were provided from the manufacturers.

Since almost all ethernet cards are similar, you'd expect that most people would be affected. Nice to see that everyone gets equal billing, and we can all be hacked. Of course, everyone just assumes it's Windows. I know I'll get Flamed or what not for it, but even windows didn't mess up how the Ethernet standard worked. They just messed up how things access it.

Re:The Nature of the CERT list

[itarget]

everyone just assumes it's Windows

Just the moronic submitter and the moronic editors. That's far from everyone. In fact, you'll notice that most are berating Licensed2Hack and Hemos.

Who honestly cares?

[Anonymous Coward]

So someone on your network might be able to read small bits of previous packets or just random memory addresses. Who really cares? Why is this even a problem?

Re:read it again

[dWhisper]

Microsoft makes Ethernet cards. They currently ship their "100/10 Broadband adapter", in PCI and USB flavors, and used to ship cards years ago.

And MS hardware has always been a positive thing, like the Sidewinders and the Mice, but I'll admit I've never tried their Network Cards. But I don't use No-Names either, so it balances out.

moron FUDging the b00ks...

[Anonymous Coward]

buy the #'s?

see also: payper liesense stock markup FUDge peddlers strike IT ?rich? despite ?hard times? being ?had? buy all?

see also: shrub0nomic profomulahs still used buy stock markup frauds.

see also: bill&art's accelleNT ADventure?

see also: va.msn.net, ticker: (VAST)?

Read between the lines...

[leonbrooks]

...of what Microsoft actually had to say on the topic and bet your butt that some card manufacturers based their drivers on the flawed examples. In short, as usual, many Windows systems are vulnerable and Microsoft are duckshovelling again, or should I say `as always'? Dollars to doughnuts Windows does this on other layers as well. Still, not as bad as dear old RSTS, where reading the NL: (null) device got you whatever entire disk block was last read by anyone on the system, and the password file was read often.

Oh god, lets hype it all up

[Anonymous Coward]

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

Re:Oh god, lets hype it all up

[esarjeant]

Assuming the padding is coming from other frames on the same ethernet device, then it really seems unlikely that this is a security hole at all. The data has already been transmitted in a properly sequenced form, it would have been a lot easier to pickoff the data by sniffing the other transmission.

Now, if the padding is the result of a semi-random memory location getting written to the end of your packets then that can be considered a fairly significant risk. Another posting on /. seemed to suggest this as a possibility, but based on the CERT advisory I really don't see any evidence of this.

What am I missing here? If we could stop quibbling over the how-much-MS-sucks-today factor maybe we could understand the true scope/nature of this problem. If there really isn't a problem, then perhaps it doesn't belong on CERT.

Re:Oh god, lets hype it all up

[Anonymous Coward]

This would normally be true if it wasn't for one small issue...

free()'ed memory is generally not blanked and so is returned to the kernel (whatever OS) untouched retaining the data it was used to hold. The kernel is then asked for a block of memory for some application/driver, it passes a free block (still un-zeroed) to the application as defined in the POSIX standard, and so sensitive data can be shunted about.

For example, sshd generates a private key, it is quited and then all the memory free()'ed up is not zeroed[1]. An ethernet driver wants some padding for a ethernet frame, asks for some memory and then gets handed by complete fluke the private ssh key....

The main issue (which the CERT advisory tells us) is that it might not be limited to just the Ethernet layer. Hell there is no reason why this problem should not be found in the userspace layer. I hope now you can see the real issue.

Now the debate is whether we should be given a kernel patch where all allocated memory is first zero'ed. We would have to accept a potentially cripling performance hit though. I think we should, and if its made into a grsec patch which is controlable through sysctl all the better :)

[1] sure sshd probably does zero the memory it releases however you can see what happens if an application/driver doesn't, this just exagerates the problem.

Jim diGriz - cannot be arsed to find out my passwd ;)

Re:Oh god, lets hype it all up

[Anonymous Coward]

It's possible you may end up grabbing some memory with data in unencrypted form. That is, when a user enters a password it's stored in memory for a short time in clear text. It is possible to pick this up. *cough* Though I doubt it will ever happen... I agree it's a non-issue for the most part.

Re:Oh god, lets hype it all up

[Skapare]

Modern operating systems juggle data between network stack layers using a buffering systems that usually leaves data in the same memory location once it is copied from virtual memory. If said buffer is allocated in a small space, and if the final push of that data into the ethernet hardware does not respect that small space, then this is the equivalent of a buffer overflow, except that it is reading beyond the buffer instead of writing. These being buffers in the network stack, and thus in the kernel in most systems, what you will most likely get is whatever follows that buffer in memory. Most likely that will be whatever data is in the same memory pool. That means it will be data the kernel itself is manipulating that requires similar allocation strategy as the network stack buffers. Most likely it will be data from other network stack buffers. Some of that data will be buffer pointers (not much use) or other packet data (in or out). In a modern switched LAN, sniffing is hard. To the machine getting these ethernet frames, which has to be in the same LAN, that's like being able to do a small bit of sniffing, but that the sniffing may include bits of kernel memory that were never part of packets, depending on the way the memory allocation in that kernel is handled.

I would agree the vulnerability is really really low. One reason for this is that most likely this memory will not include any virtual process space memory, since the allocation strategies are different. Only when a whole page is reclassified from being used for virtual memory to being used as allocation for small buffers, will there be any exposure of virtual memory from a process. And many programs that deal with sensitive information are already doing things like locking pages that contain clear passwords (to prevent them from ever reaching swap space) and actually clearing those fields when done.

In many cases the buffer location involved is in the ethernet device hardware itself. The driver would copy less than 46 bytes, but set the length to the minimum 46 and update the write queue registers to include it. Now the data sent is whatever was in the hardware memory. This won't expose kernel memory, but it can expose network transmitted data that would otherwise not been sniffable, to the one next hop machine it's destined to (assuming a switched LAN ... a hubbed LAN already has greater risk than this on its own). This risk exists if the attacker is on the same LAN, so a remote exploit from over the internet won't be able to make use of this. Routers are not likely to be copying the padding along with the packet, although I can't say that this is a zero exposure.

This non-zero risk is not much of a performance hit to fix. Unless the ethernet device is doing direct memory access right out of the stack buffer, then some copying has to be involved. And how often are you needing extreme CPU performance while also sending lots of packets less than 46 bytes? Two major scenarios exist for why such small packets are going through. One is keystrokes. The other is an attack against this small vulnerability (pardon the pun). In either of these cases, I don't see where adding the extra CPU time to pad out the buffer target with zeros is going to push things over the edge. The one case where there might be a difficulty is when the network stack buffer is used directly, and in such a case it would have to be holding the whole ethernet frame in that buffer. The fix there would be to always make sure the buffer is allocated with the minimum required size (never smaller) and pad it there.

Your Fortune 500 company is very unlikely to be colocating sensitive machines where outsiders would have access to the same ethernet segment. Either you're running things in-house, or have outsourced to a major outsourcer, or have colocated things with router isolation involved. Just due to these factors, your risk drops just about as close to zero as you can get.

And MS-Word ships same over the net...

[leonbrooks]

...where do you want your data to go today? Oops, sorry! (-:

Re:And MS-Word ships same over the net...

[oliverthered]

Word is even worse, though you can mostly correct the problem by saving the file with a different name.
try modifying a file a few times and then saving with a different name, the file size will drop!

Re:And MS-Word ships same over the net...

[leonbrooks]

Or just use OpenOffice.org, problem solved.

The drivers comply with the RFC

[dcs]

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

Is this vulnerability really useful?

[MyNameIsFred]

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?

Re:Is this vulnerability really useful?

[ab762]

Indeed, exploiting this is not trivial. But consider if I repeatedly send the minimum length packet and get 46 bytes each time. Eventually I may get a recognizable cleartext password. And, given the vast number of times passwords do go over the net, eventually might not be too long.

If the padding bytes all come from other packets, then I'll see nothing that I wouldn't see with a sniffer on your local net. But it appears that I could see that remotely, which is indeed an issue for concern.

It is common, but bad, practice to assume that passwords on a corporate Intranet don't need to be protected as carefully as on the Internet. Now, we see that some of the data from those "safe" Intranet packets may get spewed outside.

I'd say it falls between the two extremes you suggest.

Countermeasures can be applied at routers, in theory, since the router (or firewall) could inspect the packet and null out the padding bytes. Of course, this would impact performance.

Re:Is this vulnerability really useful?

[Anonymous Coward]

The router would take the IP packet out of the ethernet packet, and put it into a new one anyway, so at worst, you would be looking at random memory in the router.

A bridge is needed to forward the ethernet packet between networks.

...or...

[leonbrooks]

...`fix' your machine into the deck at terminal velocity. Trustworthy Computing at its best!

Re:...or...

[Anonymous Coward]

what about the recent dso, or unpnp vulns? i had to rely on the likes of steve gibson for those updates

Looks pretty harmless

[heikkile]

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.

Re:Looks pretty harmless

[saider]

Most likely it contains previous packet data, which has a higher chance of something sensitive (like login information). But it would still be like putting together a puzzle that is a picture of a broken puzzle.

Re:Looks pretty harmless

[The Other Nate]

I agree with your take on the probability of the info's usefulness, but I had to laugh when I saw your sig.

Re:Looks pretty harmless

[pclminion]

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.

XQ says...

[leonbrooks]

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

Re:XQ says...

[fucksl4shd0t]

WHY would you assume that?

• Because it's often true, especially for remote-root class exploits
• there aren't any "root" class exploits, since there's no "root" user in Windows.
• Because it gets a rise from their audience
• Sensationalism at its best, but not journalism of any sort.
• Because the editors are too outright lazy toi actually spend 30 seconds with Google, CERT etc checking
• Do they actually read the stories before posting the link, or do they depend on the synopsis of the story before making the decision to post it? There's a great deal of potential exploit of slashdot if they depend on the synopsis, the sort of exploit they criticize windows for.

Re:XQ says...

[leonbrooks]

there aren't any "root" class exploits, since there's no "root" user in Windows

I'm going to assume that you're blonde and not just trolling. There is no root, but there is complete carte-blanche access to every bit on the system. This is `root class' access since it is in the same class as having root on a real OS. Doiung this over the 'net is `remote-root class'. In point of fact, root can be freely renamed and may have its ultimate authority restricted (e.g. by capabilities) on a Unix box, so in this regard root has extended its feature set to encompass Administrator-style operation as well.

Sensationalism at its best, but not journalism of any sort.

Do you see me arguing with that?

Do they actually read the stories before posting the link, or do they depend on the synopsis of the story before making the decision to post it?

I think they mainly rely on misreading the synopses. They're also apparently in the habit of refusing good stories for several days at a run.

There's a great deal of potential exploit of slashdot if they depend on the synopsis, the sort of exploit they criticize windows for.

Um, what? You can social-engineer practically anything. The kind of exploit Windows is characterised by is the we-didn't-plan-ahead type, the this-needed-a-rewrite-half-a-decade-ago type.

Microsoft are always in too much of a rush to capture market share, so put their effort into this or that shiny new feature instead of making the basics work right. Linux started out with nothing to lose, every step uphill, no marketing or legal department, so it has had to constantly prove its merit in order to gain acceptance. And it has.

This Was Intentional

[ONOIML8]

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.

linux geeks cant read

[Anonymous Coward]

Linux Geek - "Since they don't specify the OS, I'm assuming these are drivers for Windows."

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

Re:read it again

[Anonymous Coward]

I figured they might have dabbled a bit in the past (Hell they made a cordless phone), but I've never seen one over here in Australia. With the Xbox I thought they may have dabbled again.

The main point was that it is the drivers not the OS, I own a SideWinder 3D Pro joystick, that is still going strong, the throttle isn't as smooth as it used to be but otherwise it has been a accurate long serving piece of hardware. Their mouse are also very good. I've always wondered how they can have poor software QA when their hardware is for the most part (Some of the first batch of Optical mice were slightly dodgy, corrected in next revision) good.

Good point!

[leonbrooks]

Perhaps, since the site only speaks English, they meant to say `i1n'?

Cisco isn't vulnerable:

[Ayanami Rei]

Cisco's Status/Statement
and
Full CERT Advisory

Re:HEMOS DIDN'T READ IT EITHER!!!

[Kourino]

By the way, you misspelled "blatant", and the use of HTML tags obviates the need of ugly all-caps messages :)

Sorry, I usually don't feed the trolls ... it's 730am, I've been up for almost 24 hours, and I'm waiting for a drive to badblock ^^;

Fix within a week? MS - NO WAY!

[Anonymous Coward]

You know Linux will have a simple fix ready within a few days.
You think Billy Gates will get off his duff and fix this?
$80 for the new version Win YP, then maybe, if you are lucky it has the fix (and a whole new list of bugs).
MS people are such fools. One born every day!

Re:Fix within a week? MS - NO WAY!

[Anonymous Coward]

Too bad microsoft isn't flawed with this problem(contrary to the article). And lets see how fast linux geeks can recreate tens of thousands of drivers.

Re:Fix within a week? MS - NO WAY!

[cookiepus]

There aren't tens of thousand of drivers for Linux. At last count, there are only six known drivers for Linux. None of which supports are relevant hardware.

Am I the only one tired of this?

[los furtive]

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?

Re:Am I the only one tired of this?

[a_n_d_e_r_s]

I think that already been done ....

Re:Am I the only one tired of this?

[Anonymous Coward]

No.
The next thing will be that articles gets posted without slashdot readers reading them.

Re:Am I the only one tired of this?

[mstyne]

I think what's next is people stop reading /.

Re:Am I the only one tired of this?

[Anonymous Coward]

Have the editors changed this post since it first went up? Or do we have readers who read the article but not the complete summary of the article? "It's actually Linux, *BSD, and Windows." is the comment added by the editor, no?

Re:Am I the only one tired of this?

[Anonymous Coward]

Yes.

>I'm assuming these are drivers for Windows

That was the only part up for hours. The editor added the comments after several mod 5 posts pointed out what the sumbitter wrote.

Read it one more time...

[dWhisper]

Actually, I only know that they make these because I ran into one of their access points. Everything I've seen about their Wireless stuff seems to be positive.

Their Games and their Hardware has always been unique, innovative and stable. I just figured they were getting prepared for the Monopoly split, by putting all the good eggs in one basket.

This flaw is a non-issue

[rmckeethen]

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.

Re:This flaw is a non-issue

[Anonymous Coward]

I agree, but I see this leak all the time.
Arp packets in particular... who has xxx....
The never go far, but it still surprised me a few months ago...

tcpdump -X -s 4096

I felt raped for a few minutes.. but further investigation cleared it up.

Re:This flaw is a non-issue

[Twanfox]

Personally, I would tend to agree that this particular issue is a non-issue. To state rather that the effort in exploiting it would be better spent just hard cracking a system open and reading out the data. It's more troublesome for some of us to see the kind of stupid error correction techniques in widely prevolent systems.

Always kind of bothered me why memory freshly allocated could not start at 0. Does that take so much effort to do? How about sanity checking my data structure? How about properly implimenting something? Lazyness seems to be the word of the age, though.

Someone please mod down wrong.

[Ayanami Rei]

I'm sorry, but this is uninformed spouting of the mouth.

SSH private keys never even get near the ethernet stack.
If the driver programmers are as lazy (or efficient...) as the article claims they are, these stray bytes are from other offsets in the stack, thus comprising parts of older (or perahps yet unhandled) frames, which incidentally, contains information from packets you could have sniffed wholly on that segment. Why they would randomly allocate memory right adjacent to user space data segments or the file buffer cache, i'll never know (hint: IT DOESN'T)
Also, SSH takes care to overwrite old buffers containing the private key when it finishes with it too.

What no one has mentioned yet which is the real vulnerabiltiy is that this attack can be mitigated by any device which can reach a vulnerable client with an IMCP ECHO request and get a reply. Some network configurations allow IMCP to flow freely, including to the internet, thus machines inside may be at risk when they thought they might have been safe on a private network segment (using unencrypted protocols, telnet, etc.).

Solution? Block IMCP if you don't need it. Or ensure the firewall is using a non-vulnerable driver/device and have it "rewrite" all the packets (this may be imperative, but it could depend on implementation).

Re:Someone please mod down wrong.

[schon]

this is uninformed spouting of the mouth.

you mean his post, or yours?

Block IMCP if you don't need it

Ahem; if you run TCP/IP, you always need it.

ICMP is used for control messages between systems - it's used for control messages (the 'C' and 'M' in ICMP) for TCP and UDP packets.

Without ICMP, your connections can take longer, or (in some cases) not work at all. All modern OSes support path MTU discovery - and PMTU discovery relies on ICMP messages. If you block these messages, your clients will be unable to reach sites if part of your path to them has a smaller MTU than the MTU of your local interface.

You may know a lot about SSH, but you don't know squat about TCP/IP. ICMP is used for more than just 'ping'.

Re:Someone please mod down wrong.

[aridhol]

your clients will be unable to reach sites if part of your path to them has a smaller MTU than the MTU of your local interface.

I suppose you've never heard of packet fragmenting, then? MTU discovery tries to ensure that your packets won't be fragmented by routers, but if you send larger packets, they'll be fragmented by routers and re-assembled by the destination machine.

Re:Someone please mod down wrong.

[LegendLength]

Solution? Block IMCP if you don't need it. Or ensure the firewall is using a non-vulnerable driver/device and have it "rewrite" all the packets (this may be imperative, but it could depend on implementation).

Rewriting the packet would have no effect because the problem is in the driver below and its bad use of its own static packet buffer.

Re:Someone please mod down wrong.

[schon]

I suppose you've never heard of packet fragmenting, then?

Yes, I've heard of it. And unlike you, I actually know how it works in relation to PMTU discovery.

MTU discovery tries to ensure that your packets won't be fragmented by routers, but if you send larger packets, they'll be fragmented by routers

No, they won't.

PMTU discovery works by setting the "DO NOT FRAGMENT" bit of the IP header. Packets that are too large are dropped, NOT fragmented, and an ICMP message is sent to the originating host, telling them to re-send a smaller packet.

If you're gonna correct someone, make sure you know what you're talking about first.

Re:Someone please mod down wrong.

[aridhol]

For the PMTU, yes it's marked DNF. The host computer should be intelligent enough to send a smaller packet after enough DNF packets disappear into the ether.

Once a PTMU has been calculated, the data packets should not be marked DNF, as the path may change as routers change states, and the PTMU may change and fragmenting still occur.

Re:Someone please mod down wrong.

[schon]

For the PMTU, yes it's marked DNF

OK, so what's your point then? (Oh, and it's marked 'DF', not 'DNF')

The host computer should be intelligent enough to send a smaller packet after enough DNF packets disappear into the ether.

"Should be"? First, we're talking about what "is" and "isn't", not "should be"... and second, no, it SHOULDN'T be.

If the host is just going to assume that a dropped packet is due to someone misconfiguring their firewall - and not just because the packet was dropped for some other reason - what happens when "enough" packets disappear because of some other reason (like, say - temporary link outages, congestion, etc..)?

The "intelligent enough" host begins making it's packets smaller, which causes more overhead for the troubled link. If the dropped packets are because of congestion, you're actually making the problem worse instead of better (because smaller packets impose higher overhead on a network, both because the payload is smaller relative to the packet size, and there are more packets for the routers to process.)

Once a PTMU has been calculated, the data packets should not be marked DNF

Try reading RFC 1191, which describes PMTU discovery, and directly contradicts your statement.

Section 6.3 (Purging stale PMTU information) states this: "Because a host using PMTU Discovery always sets the DF bit" (emphasis added.) Seems the guys who invented PMTU discovery disagree with you.

data packets should not be marked DNF, as the path may change as routers change states

This is the perfect reason why hosts should continue to set the DF bit, not a reason why they shouldn't.

Problem I had with net coding

[Tyreth]

A little while back while I was experimenting with sockets programming, I came across a strange behaviour (or I thought was strange). I discovered that even if I cleared a char array on the client receiving the message, for some reason the packet I received from the server would contain the new information, with the old tacked on the end. So in a chat example, if my first packet had the message "Hello" and the second said "Bob", then the second would actually contain "Boblo". I tried all I could to clear the char array because I was presuming that the problem was with the client. Then I discovered I could solve this with memcpy of nulls (I think) into the char array first before sending. I can't remember if I did this on the server or the client.

Sorry I'm being vague, but a person who is competent at socket programming will _probably_ know what I'm talking about. So I'm curious, is this the same problem we read about here that I encountered, or is it just a misunderstanding of mine into the details of socket programming? I'd love to understand.

Thanks

Re:Problem I had with net coding

[LordKaT]

So I'm curious, is this the same problem we read about here that I encountered . . .

This problem is similar in that it is memory releated, but it has nothing to do with server software, and everything to do with device drivers. Your problem was memory on the server side of things, specifically, the buffer you used needed to be cleared out before you used that buffer again, otherwise the old data would be still be in the buffer, until new data came along that was as long (or longer). Basically, you would need to sniff the packets in order to get the overflow of memory, otherwise it was just poor coding on your part. Here's an example:

main()
{
// . . . some init stuff here
char *buffer = "wookie"; // assume we used this
// . . . socket stuff here
send(wookie); // send "wookie"
*buffer = "wokie";

/* *buffer now contains "wokiee" because the last e was never cleared. If we were to send this, the client would receive wokiee. We need to clear this (memset or something else) before we put data in it */
}

--LordKaT

Re:Problem I had with net coding

[Tyreth]

Thanks. Though I remember trying to just blank the char out - or even use a new char for the second send and it still had the same problem. Which seemed really strange to me. Only a memset/memcpy (can't remember, think the latter) seemed to work.

Re:Problem I had with net coding

[deepchasm]

Nice try, but you're C is a bit confused.

*buffer = "wokie";

actually makes buffer point to a *different* location, plus "wokie" is a nul-terminated string. In short your code doesn't demonstrate the problem. Try this:

/*
* Demonstrate the need for
* zero-padding buffers
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv)
{
char buf[7] = "wookie";

printf("Original buffer: \"%s\"\n", buf);

/* replace contents without zero-padding */
memcpy(buf, "wokie", 5);

printf("Final buffer: \"%s\"\n", buf);

return EXIT_SUCCESS;
}

Re:Problem I had with net coding

[deepchasm]

In previous post,

*buffer = "wokie";

should read

buffer = "wokie";

(and in the original post I presume)

Re:Problem I had with net coding

[Anonymous Coward]

This sounds like a "tyreth does not know C" problem more than a socket problem. Consider your buffers, particularly with respect to the 0 that should terminate your strings, the length argument of read and write, etc...

The kind of data you send should also make sense, and have some sort of organization. It's a good idea to send a couple (binary) bytes that tells you about the request or information you're sending. If you're sending things like "hello" without zero termination, well... Think it through a little more.

Re:Problem I had with net coding

[Tyreth]

This sounds like a "tyreth does not know C" problem more than a socket problem

Thanks for the vote of confidence. I was asking for an answer, because I am willing to learn and don't feel a need to pretend that I do know everything about programming.

Re:Or maybe Slashdot wont post news unless its ant

[Michalson]

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.

Another redundant post

[Photon Ghoul]

This is getting pretty old.

I can deal with unprofessionalism on Slashdot (dupes, unverified sources), since it's really not a professional journalistic news source and has never claimed to be. I can deal with bias against Microsoft, the U.S. government, corporations, Red Hat, Church of Scientology, etc. because no one ever said the editors were being objective. I can deal with regurgitated Register posts and the constant WSJ (free registration required!) posts.

What I can't deal with are article submissions being approved when the submitter doesn't read the article they are submitting *and* making unfounded biased FUDish comments about it. The editors not reading the article and commenting on it in the blurb is bad enough.

It's embarassing to ever point anyone else to Slashdot and it's very hard to take it even the slightest bit seriously.

Re:Another redundant post

[Cid Highwind]

So you stay here any keep reading slashdot... why?

Re:Another redundant post

[Photon Ghoul]

Up until now, because I liked it... faults and all. Now, I'm not sure I am going to keep reading it.

noticed this 6 years ago

[martin]

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?

Re:noticed this 6 years ago

[Russ Nelson]

This vuln is at least fifteen years old. To exploit it, you need physical access to the Ethernet. Before the days of switched networks, physical access to the Ethernet meant access to EVERYTHING: telnet sessions, pop3 session, ftp transfers, all with passwords in the clear. Switched networks just make it a little harder to intercept the data (you have to forge ARP replies).
-russ

Re:noticed this 6 years ago

[Anonymous Coward]

You realise of course that 6 years is CERT's usual reaction time. The 'C' stands for conservative.

Re:noticed this 6 years ago

[ImpTech]

Well since the CERT page says IBM's not vulnerable, I guess something must have happened.

memset on windows??

[Anonymous Coward]

>> Since they don't specify the OS, I'm assuming these are drivers for Windows.

Whenever I read "memset", I think aloud "unix".

Windows programmers talk about ZeroMemory and FillMemory, not memset. In drivers, that would be RtlZeroMemory and RtlFillMemory.
memset exists for compatibility, but it's just a wrapper around FillMemory.

Secondly, for security reasons, Windows ensures that no app will ever find remnants of another app's data in its memory space (all allocated memory is erased before is't given to the requester), which significantly reduces the risk that sensitive data would be transmitted.

Normally, if the app passes it less than 46 bytes of data, the driver would have to copy it to its own buffer space at the lowest execution level to avoid hitting addresses that aren't mapped to physical memory later (would cause a BSOD if it happened above dispatch level).
If that buffer is allocated dynamically it would be empty, if it's static it would contain some part of the previous packet - not so much risk of finding sensitive data there, since it's just repeating something that has already been on the network.

BTW, the CERT advisory contains a long list of checked systems. There are only six names where it says "Not Vulnerable", and one of those six is Microsoft, so heck yeah, please keep feeling safe because *n*x is so damn secure by defi^H^H^H^H religion.

Re:memset on windows??

[Junks Jerzey]

Windows programmers talk about ZeroMemory and FillMemory, not memset. In drivers, that would be RtlZeroMemory and RtlFillMemory.
memset exists for compatibility, but it's just a wrapper around FillMemory.

memset is a standard C library function. Here's a hint: the standard C library exists under Windows, too. I have never called ZeroMemory or FillMemory, period.

Re:memset on windows??

[Anonymous Coward]

Obviously you've never written a Windows kernel mode driver.

Re:memset on windows??

[hanwen]

Whenever I read "memset", I think aloud "unix".

Secondly, for security reasons, Windows ensures that no app will ever find remnants of another app's data in its memory space (all allocated memory is erased before is't given to the requester), which significantly reduces the risk that sensitive data would be transmitted.

please keep feeling safe because *n*x is so damn secure by defi^H^H^H^H religion.

Here is a clue for you.

This is about drivers, leaking kernel memory, not drivers leaking application memory.

Drivers are not applications, since drivers run in kernel space. Since memory is generally allocated in Linux by mmapping files, applications can not get "garbage data" from the operating system.

memset is part of the ISO/IEC 9899 standard for the C programming language. If your Windows library doesn't have it, complain to your vendor. This has nothing to do with Unix vs. Windows.

Re:memset on windows??

[Anonymous Coward]

You mean you cannot use standard C for this, but need to resort to Visual Basic?

Re:memset on windows??

[Anonymous Coward]

when was the last time you used a MICROSOFT written driver.

that's like saying that Coke-a-cola is not shipping defective tires with it's product.

Microsoft weenie... never do you guys ever get your FACTS straight.

Re:memset on windows??

[Anonymous Coward]

Heh, yeah.

You ever looked at the implementation?

#define ZeroMemory RtlZeroMemory

#define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))

Re:memset on windows??

[Anonymous Coward]

Here's a hint: the standard C library exists under Windows, too. I have never called ZeroMemory or FillMemory, period.

Then I hope you never wrote a device driver.
If you did, I'd like to know RIGHT NOW which one, so I never make the mistake of installing a driver from your company.

Re:memset on windows??

[Anonymous Coward]

I believe one of your declares (the first).

Entry points in kernel32.dll version 5.0.2195.6079:

Ordinal 601 (0x259) - RtlFillMemory
Ordinal 604 (0x25B) - RtlZeroMemory

Entry point in msvcrt.dll version 6.1.9359.0:

Ordinal 686 (0x2AE) - memset

You can use depends.exe to verify it.

Using memset in a driver is going to bite you as soon as MS brings out an OS where there is a difference, the other versions aren't documented as the ones to be used in a driver for nothing.

Re:memset on windows??

[Anonymous Coward]

I forgot in my other reply - how many #if's did you have to ignore before arriving at those declares, and in which .h files?

I found this one instead:

#define _CRTIMP __declspec(dllimport)
[...]
_CRTIMP void * __cdecl memset(void *, int, size_t);

Re:memset on windows??

[Anonymous Coward]

Here are some clues for you:

1) Nobody was talking about how linux mmaps files.

2) mmapping files to allocate memory will (at least in windows) only lead to BSODs if you do it in a kernel mode driver. You can't even use the standard malloc etc. because of the same reason.

3) memset *is* available in windows. So are the rest of the unix API's that made it into the C standard (C happens to be the language unix was written in as the first OS in a higher language, and it inherited system calls from it as "library routines").

no "root" user in Windows

[wiredog]

Yes there is. It's called "administrator".

Re: no "root" user in Windows

[fucksl4shd0t]

Yes there is. It's called "administrator".

Somehow I have a feeling that you're aware that an administrator in Windows doesn't map directly to root on real OSs. For one thing, ANYONE can be an administrator. Now, I know you can make root of regular users, but typically you don't. If someone actually is an administrator on the network, he doesn't use a root-level account as his normal, everyday, email-reading and web-surfing account. However, on a Windows network, it's quite common to give an everyday email-reading web-surfing account administrative priviledges, or some portion thereof.

The "role" is the same, for the most part, and has varying degrees of delegation, but the "implementation" is different.

Re: no "root" user in Windows

[wiredog]

The "role" is the same, for the most part, and has varying degrees of delegation, but the "implementation" is different.

But that's true of ,say, unix 'root' vs Vax VMS 'superuser'. Root doesn't map directly to the equivalent on any non-unix OS.

Re: no "root" user in Windows

[Anonymous Coward]

Any decisions made to browse or do email as administrator are the user's fault, it has nothing to do with the implementation. There are plenty of stupid Linux users too who do the same thing (/w root obviously).

Re: no "root" user in Windows

[fucksl4shd0t]

But that's true of ,say, unix 'root' vs Vax VMS 'superuser'. Root doesn't map directly to the equivalent on any non-unix OS.

I hate to sound rude, but what's the point?

There isn't a "root-class" exploit in Windows, but there are exploits that allow system-level priviledges to be assigned to a remote user (localsystem account is different than administrator or domain administrator), there are exploits that allow administrator priviledges to be assigned to an intruder (administrator is different than localsystem and domain administrator) and there are exploits---well, you get my point.

but there's no "root-class" exploit.

On a UNIX box there are still several different subclasses of "root-class" exploit, and if you want to badly enough you can bundle the 3 accounts I mentioned as well as a few other groups in windows and call it "root-class", but it's still not the same.

If I crack into a UNIX host and root it, I now have complete and total power over the machine, because I am root. If I crack into a Windows box, in order to establish complete and total power over the machine I have to gain LocalSystem and Administrator priviledges both (The main difference is that Administrator usually can't run as service while LocalSystem can--needed for trojans to do anything really useful). On the domain level the differences become more sincere.

I realize I was nitpicking to begin with. :)

Re: no "root" user in Windows

[fucksl4shd0t]

Any decisions made to browse or do email as administrator are the user's fault, it has nothing to do with the implementation. There are plenty of stupid Linux users too who do the same thing (/w root obviously).

True, I'm not trying to say that Linux is better in this regard. In fact, based on my writeup, Windows is better. :) HOWEVER, in the world of Windows administration, it is normal for the administrator to use his administrator account for that stuff, whereas in the Linux world (and UNIX world, as far as I know) it is NOT normal to do so.

But how people behave on their own computers is entirely their own problem. I administer my home computers, and I use a regular user account and make judicial use of the "su" command. :)

Re: no "root" user in Windows

[benwb]

The main difference is that Administrator usually can't run as service while LocalSystem can--needed for trojans to do anything really useful

Once you have administrator priveldges on a windows box you are god. You can grant yourself any additional priveleges you need (including the run as service right). Some domain policy settings can override some of this when running in an active directory forest, but I can`t think of anything that I couldn't do as a member of the administrators group in any of the nt based windows derivatives.

Re: no "root" user in Windows

[benwb]

Teach me to preview
s/priveleges|priveledges/privileges/g

Re: no "root" user in Windows

[t0shstah]

Actually, I think very low level processes are run by System, which is a level higher in privileges than Administrator. For most practical purposes you are right though.

Re: no "root" user in Windows

[ergo98]

For one thing, ANYONE can be an administrator.

Oh right, and root is only for guys name "Steve" who eat Burger King Whoppers.

If someone actually is an administrator on the network, he doesn't use a root-level account as his normal, everyday, email-reading and web-surfing account. However, on a Windows network, it's quite common to give an everyday email-reading web-surfing account administrative priviledges, or some portion thereof.

This has ABSOLUTELY NOTHING to do with the "implementation" (though your fervent zealotry was clear when you contrasted Windows against "real OSs"), but rather common usage: Every guide on Windows administration since the days of NT 3.51 had admonished that one use the administrator account only for administrative purposes.

In any case if one did a poll of the general Slashdot community, I would bet pretty big bucks that a very good portion of them are running under the root account, or a root priviledge account (no one needs to reply to give their uppity righteous "We don't do that here in Linux land". I know from personal contacts that it is quite common). I have an SSH to my FreeBSD box right now as root: It's just convenient and saves a su step.

Re: no "root" user in Windows

[fucksl4shd0t]

For one thing, ANYONE can be an administrator.

Oh right, and root is only for guys name "Steve" who eat Burger King Whoppers.

I was referring to the fact that it's a point and click operation to assign someone administrative priviledges. It's not so simple to turn a regular user into root. That's a different case than logging in as root from the get go, I'm talking about priviledges assigned to an account here. I suspect (but don't know for a fact) that it's possible to give a regular user account permanently root-level access, it's still a different story.

This has ABSOLUTELY NOTHING to do with the "implementation" (though your fervent zealotry was clear when you contrasted Windows against "real OSs"), but rather common usage: Every guide on Windows administration since the days of NT 3.51 had admonished that one use the administrator account only for administrative purposes.

Actually, it does. Implementation isn't just a matter of how the developers implemented their user security model, it's also a matter of how the end-user has implemented their security policy.

I'll admit right now that my experience in administering in both worlds is EXTREMELY limited. :) So I could be shooting from the hip here. It's also one-sided. I have had a lot of contact with NT administrators, compared to very little contact with *nix administrators.

In any case if one did a poll of the general Slashdot community, I would bet pretty big bucks that a very good portion of them are running under the root account, or a root priviledge account

Ok, how about somebody reply who does this? :) The poll should also include:

• Are you logged in at work?
• Does your user account at work have these priviledges assigned?
• Does your company have a policy allowing or forbidding you to assign root-level rights to a user account?

• Keep in mind that there is a different mindset involved. Now, before you go accusing me of being an elitist, I am specifically not saying that one mindset is superior to the other. I don't know that to be true. :) But the mindsets are different, so different things happen.

  Now you can accuse me of being an elitist. I don't give a shit. :)

Re: no "root" user in Windows

[kaphka]

Yes there is. It's called "administrator".

Windows (unlike Linux) doesn't need a "root" or "administrator", since all of the necessary privileges can be assigned individually. For practical purposes, almost all Windows installations have a superuser anyway, and (as others in this thread have pointed out) most have too many.

Re: no "root" user in Windows

[Nyarly]

Actually, the single biggest difference between the various "super-user" accounts in Windows and in Unix and progeny is that the super-users aren't trusted to act as other accounts without knowing their passwords under Windows.

I think the philosophy is that this limits the impact of Administrator or LocalSystem attacks on a Windows machine, since in order to become another user, you need to change their password. I for one think that that rationale is pants, but then I cut my teeth on Irix and Solaris. Ultimately, a super-user attack is a super-user attack, whether you call it Administrator privledges or a root login; demanding a password to change accounts just makes life difficult for legitimate sysadmins.

This has been your 30 seconds of pedantry.

Re: no "root" user in Windows

[leonbrooks]

Every guide on Windows administration since the days of NT 3.51 had admonished that one use the administrator account only for administrative purposes.

It doesn't seem to have had any effect. Every Windows `power user' I know runs as Administrator most or all of the time, very few Linux/Unix power users do. Perhaps Microsoft should try something else.

Re: no "root" user in Windows

[doug363]

But an admininstrator can run processes as localsystem. As an administrator, try running regedt32 like this:
at 9:00am /interactive "regedt32"

Change the time in the command to be one minute ahead of the current system time. Regedt32 will run as localsystem. As other users have pointed out, Admins can also create services and run them as localsystem.

Re: no "root" user in Windows

[doug363]

Just curious... can you assign rights to bind to a privilaged port (1024) by user?

Nah. [ot|meta]

[Kourino]

I think it's unfortunate. Slashdot could be a nice statement about independent journalism. Instead it's a nice statement on the laziness of our societies :)

Re:Nah. [ot|meta]

[Anonymous Coward]

Wouldn't you have to have reporters to be about "independent journalism?" As far as I can tell Slashdot has always been about collecting news stories from dozens of different sources and posting those that interest the editors.

Re:Nah. [ot|meta]

[Trolling4Dollars]

This is not a journalistic endeavour. It's basically a blog. No news is being reported here, only links to other content. Then the comments... well, I've seen some of the comments and I would hardly call them journalism. If you want independent journalism, you'll need to find a real SOURCE of information, not just a forum.

Well ...

[Kourino]

Admittedly this is worst on the unedited front page. I've seen a few redeeming articles recenty. Don't remember what they are :)

Re:Slashdotted your credibility-and everyone sees

[bitflip]

A new low, indeed.

I guess Slashdot has gotten to the point where they're so desperate for hits that they have to rely on people bitching about slashdot, rather than even pretending to have integrity.

They've got about as much credibility as the RIAA at this point. If it weren't for the comments, they wouldn't have anything at all.

'iln' in title....

[carlos_benj]

Egad! This marks a new low as I was foolish enough to think that even a /. editor could spell 'in' correctly.

Re:Or maybe Slashdot wont post news unless its ant

[nagora]

Microsoft is bad, we don't know why, but it is

If you don't know why by now, you haven't been paying attention.

TWW

Re:Slashdotted your credibility-and everyone sees

[pete-classic]

Obviously they fucked up, but I think that your assumption about what Hemos meant is out of whack.

Most "pulp tech" articles are 1. about windows and 2. assume that the only system that you, the reader, are aware of is windows.

So, if an article of this type doesn't specifiy a system (which this one, of course, did) one would assume that it is about windows.

Make sense?

God, I can't belive that I am defending Hemos with his "iln".

-Peter

Driver signing

[Kourino]

Microsoft became responsible for other people's code the moment they got into the business of signing other people's code.

Good point. I hadn't thought about that at all. Although, it looks like all you need to do to get your driver signed is submit it to Microsoft's "Windows Hardware Quality Labs" for testing, and do some packaging.

Unfortunately, MS' website doesn't seem to say much about what WHQL actually does. Further investigation on that website seems to reveal that the signature only means that a driver is "compatible" with a Windows release, and that not installing unsigned drivers "may prevent problems such as ... system instability". So, in the end, signed drivers are compatible with Windows and should be more stable than the unsigned. Oh, and that this copy is unmodified from the copy WHQL got. It seems Microsoft doesn't read too much into what its signing policy means for driver quality beyond "does it install, and will it crash?" ...

I was hoping I could find some sort of agreement for the end-user on what driver signing means to them, but not so quickly, at least.

Re:Driver signing

[fucksl4shd0t]

Unfortunately, MS' website doesn't seem to say much about what WHQL actually does. Further investigation on that website seems to reveal that the signature only means that a driver is "compatible" with a Windows release, and that not installing unsigned drivers "may prevent problems such as ... system instability". So, in the end, signed drivers are compatible with Windows and should be more stable than the unsigned. Oh, and that this copy is unmodified from the copy WHQL got. It seems Microsoft doesn't read too much into what its signing policy means for driver quality beyond "does it install, and will it crash?" ...

Microsoft hasn't exactly been in the business of certifying that stuff is secure. It's just like your car dealer selling you a car with an alarm system, automatic locks, etc, but saying "You might still get robbed."

Now, personally, I don't think Microsoft should be held responsible if they certify a driver as stable on their system and it turns out to have vulnerabilities. Furthermore, I don't think Microsoft should be held responsible for their architecture lacking certain secure characteristics.

HOWEVER

The dialog that displays when you install a driver leads the user to believe that the driver being installed is both stable and secure (I don't recall the exact wording, since it's been so long since I've used Windows). Furthermore, the dialog for ActiveX installation does the same thing AND tells you that if "an Authority" hasn't certified the control, then it may compromise your system. Furthermore, it says something about if you install a control that's not safe for scripting, then your system may be compromised.

The driver scenario is similar still. First, when it's signed all that means is that what Microsoft has on their server that they're sending to you and what you receive is the SAME THING. In OSS, of course, we just provide checksums. When you apply this "signing" to an activex control, you're only really getting a signature that says that the download you made was not modified IN TRANSIT. You don't always know if the developer signs shit or not, and there's plenty of useful activex controls that aren't signed. Furthermore, signing it according to Microsoft and Verisign (the Authority mentioned) only costs money. That's it. Just pay a fee.

As for safe for scripting, well, the developer of the control decides that.

So, the bottom line is, regardless of where you get the driver or the activex control, it's still the DEVELOPER or the COMPANY MAKING THE DRIVER that you are trusting with your system. Considering that you trusted them enough to put their hardware in your computer in the first place, you're in something of a rut. And Microsoft's misleading dialogs do a great deal to improve your own position, because you can say "I was duped into thinking it was safe for my kids!".

The wording of the dialog reads to me the same as the words on the game that says "Ages 7+". So my 4-year-old might get hurt by things that would be obviously stupid to the average 7-year old, but the average 7-year-old wont' get hurt by things that are obviously stupid (about the toy, of course).

Re:Driver signing

[fucksl4shd0t]

Crap, I forgot to mention something.

When Verisign signs something (after the developer has paid them), the binary is certified as being the binary that they reviewed. But they don't actually review it, as far as I know. BUT, when your stupid IE tells you that something is signed, that means that the binary you are receiving is exactly the same as the binary verisign received. But this fact does NOT certify that the developer didn't program in vulnerabilities either intentionally or unintentionally.

Re:Driver signing

[Anonymous Coward]

Seems like one of the worst security risks is a false sense of security. I'm thinking I may actually be safer with an *unsigned* driver.

There is way to avoid this kind of problem, but in a world of benchmarks it's just not gonna happen. The OpenBSD crowd is a *possible* exception. Allocating a resource should return a resource that to the extent logically possible is a function *only* of how much of the resource is allocated. This means that memory or disk must be initialized on allocation, ie any previous information content destroyed and should again be initialized when the resource is freed. This is *before* you start thinking about making anything secure. Guaranteed to lose all benchmark races.

Re:Or maybe Slashdot wont post news unless its ant

[Michalson]

I was more refering to the pointless "M$" bashing. There are plenty of *real* reasons to find fault with Microsoft. What I'm pointing out is the constant wave of entirely baseless bashing. While the handful of *nix bigots out there might enjoy it, I find it's foolish to substitute real news with crap from the "I think M$ suks 2, can I hang around with you kool Linux people now" children.

no error checking

[DrSkwid]

stdout might not be writable

Re:no error checking

[fucksl4shd0t]

crap, I"ll have to check the stupid printf prototype now. Ok, I'll just ask. what's the printf prototype? :) Or rather, what type does it return?

Although I've never heard of stdout not being writable...

Re:no error checking

[Anonymous Coward]

Although I've never heard of stdout not being writable...

$ uptime > /dev/dsk/c0t1d0s2

There you have it. Non-writable stdout.

Re:no error checking

[Anonymous Coward]

10 PRINT "SHUT UP!"
20 GOTO 10

Don't use so many caps. It's like YELLING.

Re:no error checking

[SpaceLifeForm]

as non-root

helloworld >/var/log/messages

not Mitigated

[Bishop]

this attack can be mitigated

Mitigate is not the word you are looking for.

mitigate, v: To make less severe.

I agree, mod parent up

[Anonymous Coward]

This moderation is bullshit. the parent is not a troll, it is 100% correct. dumbass moderators. or maybe it is the editor's moderation doing this..

Here's another vulnerability.

[FreeLinux]

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.

BUT can you follow through?

[Drestin]

OK, did you bother to check the CERT Vulnerability note itself?

Wow, according to this Windows is NOT vulnerable

According to another post here Linux IS vulnerable

Reading the fluff piece isn't good enough. Go to the source and get the real deal.

Re:BUT can you follow through?

[Anonymous Coward]

Don't lambast others for not reading when you yourself haven't read the official report.

Quoting from atstake_etherleak_report.pdf, page 3:
"The Linux, NetBSD, and Windows operating systems are known to have vulnerable link layer implementations"

Re: Read the f*cking CERT note

[Drestin]

If you read the actual CERT Vulnerability note and seen that Windows is not vulnerable.

MS doesn't NEED a fix

[Drestin]

If you read the CERT Vulnerability note and seen that Windows is not vulnerable.">actual vulnerability note itself you'd see that Windows isn't even vulnerable. So it's linux that has to patch a hole Windows doesn't have.

Re:MS doesn't NEED a fix

[Russ Nelson]

The drivers Microsoft *ships* are not affected. Microsoft doesn't ship a driver for every Ethernet card one might use.
-russ

Re:MS doesn't NEED a fix

[Drestin]

And, I repeat, MS drivers are not vulnerable (yes, the ones MS ships) and therefore doesn't need a fix. Why would you associate a vulnerability in a driver not shipped (or written) by MS with MS (which is, I assume, your implication).

Drivers for linux are vulnerable so do need fixing. (p.s., sorry for the bad link in the original post, I meant: CERT note)

Re: Fix within a week? LINUX - NO WAY!

[Drestin]

Well Mr. Coward, you didn't bother to find out that Linux is vulnerable but Windows is not. MS has already issued a statement about this but I see nothing from Linux yet. Looks like the shoe is on the other foot now - haha.

Re:Slashdotted your credibility-and everyone sees

[MoreDruid]

I think the point is that the Slashdot editors just like the sound of "I bet Windows is prone to this vulnerability" way too much, and they'll post the story immediately, just to bash Windows.
OTOH, they may take this story off the frontpage now because Windows in itself is not vulnerable, but Linux is...

Some Vulnerable Linux Drivers

[Drestin]

Device Driver Original Description
3c501.c A 3Com 3c501 Ethernet driver for Linux
3c507.c An EtherLink16 device driver for Linux
3c523.c net-3-driver for the 3c523 Etherlink/MC card (i82586 Ethernet chip)
3c527.c 3com Etherlink/MC32 driver for Linux 2.4
7990.c LANCE Ethernet IC generic routines (AMD 7990 LANCE, local area network controller for Ethernet)
8139too.c RealTek RTL-8139 Fast Ethernet driver for Linux (based on rtl8139.c device driver which is also vulnerable) RTL 8129, 8139 chipsets
82596.c A generic 82596 Ethernet driver for Linux
8390.c A general NS8390 Ethernet driver core for Linux
a2065.c Amiga Linux/68k A2065 Ethernet Driver
aironet4500_core.c Aironet 4500/4800 driver core
am79c961a.c driver for the am79c961A Lance chip used in the Intel (formally Digital Equipment Corp) EBSA110 platform.
ariadne.c Amiga Linux/m68k Ariadne Ethernet Driver
arlan.c This module provides support for the Arlan 655 card made by Aironet
at1700.c A network device driver for the Allied Telesis AT1700
atari_bionet.c BioNet-100 device driver for linux68k
atarilance.c Ethernet driver for VME Lance cards on the Atari
atari_pamsnet.c PAMsNet device driver for linux68k
atp.c Attached (pocket) Ethernet adapter driver for Linux (Realtek
RTL8002 and RTL8012 chips)
bagetlance.c Ethernet driver for VME Lance cards on Baget/MIPS
declance.c Lance ethernet driver for the MIPS processor based DECstation family
depca.c A DIGITAL DEPCA & EtherWORKS ethernet driver for Linux
eepro.c Intel EtherExpress Pro/10 device driver for Linux
eexpress.c Intel EtherExpress 16 device driver for Linux
epic100.c A SMC 83c170 EPIC/100 Fast Ethernet driver for Linux (This driver is for the SMC83c170/175 "EPIC" series, as used on the SMC
EtherPower II 9432 PCI adapter, and several CardBus cards)
eth16i.c An ICL EtherTeam 16i and 32 EISA Ethernet driver for Linux
fmv18x.c A network device driver for the Fujitsu FMV-181/182/183/184
gmac.c Network device driver for the GMAC Ethernet controller on Apple G4 Powermacs
isa-skeleton.c A network driver outline for Linux
lance.c An AMD LANCE/PCnet Ethernet driver for Linux
lasi_82596.c Driver for the Intel 82596 Ethernet controller, as munged into HPPA boxen
lp486e.c Panther 82596 Ethernet driver for Linux
ni5010.c A network driver for the MiCom-Interlan NI5010 ethercard
ni52.c net-3-driver for the NI5210 card (i82586 Ethernet chip)
ni65.c ni6510 (am7990 'lance' chip) driver for Linux-net-3
pci-skeleton.c This driver is for boards based on the RTL8129 and RTL8139 PCI Ethernet chips
saa9730.c SAA9730 Ethernet driver
seeq8005.c A network device driver for the SEEQ 8005 chipset
sgiseeq.c Seeq8003 Ethernet driver for SGI machines
sk_g16.c
smc9194.c A driver for SMC's 9000 series of Ethernet cards
sonic.c
sun3lance.c
tc35815.c
via-rhine. c A Linux Ethernet device driver for VIA Rhine family chips
wavelan.c WaveLAN ISA driver
znet.c An Zenith Z-Note Ethernet driver for Linux
Wavelan_cs.c Supports version 2.00 of WaveLAN/PCMCIA cards (2.4GHz)
xirc2ps_cs.c Xircom CreditCard Ethernet Adapter IIps driver
Xircom Realport 10/100 (RE-100) driver.
This driver supports various Xircom CreditCard Ethernet adapters including the CE2, CE IIps, RE-10, CEM28, CEM33, CE33, CEM56, CE3-100, CE3B, RE-100, REM10BT, and REM56G-100.

Re:Some Vulnerable Linux Drivers

[Anonymous Coward]

Where did that list come from?

Re:Some Vulnerable Linux Drivers

[Anonymous Coward]

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

Re:Some Vulnerable Linux Drivers

[Schugy]

Do you really mean some drivers or ironically almost all drivers (that I find in /lib/modules/2.4.20/)? Or does that mean this list isn't complete? It's just that my dmfe.o for my Ethernet controller: Davicom Semiconductor, Inc. Ethernet 100/10 MBit (rev 31) isn't on that list. I don't know why I should be lucky this time :-/ Schugy

How to reproduce it easy

[NuMessiah]

OK, here is the mini howto:

At console nr. 1 run:

tcpdump -x src 10.0.0.1 and icmp

(dump all icmp packets from 10.0.0.1 with hex output (option -x))

at console nr. 2 run:

ping -s 1 10.0.0.1

(send ICMP echo request to 10.0.0.1 with requested reply size of 1)

Note: replace 10.10.0.1 with the IP address of your favourite host ;)

Usualy you are going to get one ICMP echo reply for each ICMP echo request. Each ethernet packet is going to be 46 bytes long (minimum ethernet packet length). Forth byte of each packet is the length of the ICMP message inside the packet (this is usualy 0x1D (29) for 1 byte ISMP echo reply). So, the partition of the packet content after 29th byte is padding data. If this data is not all zeroed out there is a good chance that sending host (or one of the routing/bridging equipment betwen you an the sending host) has unimplemented minimum ethernet block size padding.

Enjoy!

P.B. (Post Blogum) I just checked several MS NT 4.0 and MS WP 2000 machines and they send unpaded ethernet packets too! So, to CERT: nuff said ...

Re:How to reproduce it easy

[Anonymous Coward]

CERT said that the Drivers that ship with MS windows are not affected. It is up to each driver to do the padding right.

Re:Slashdotted your credibility-and everyone sees

[Drakonian]

The reason is it's the most obvious way to get the Slashdot editors would post it, even if its 180 degrees from the truth. You don't expect them to actually read the articles people submit do you? Has anyone ever sucessfully submitted a story with a goatse.cx link?

Hemos is an MS shill

[Salamander]

That's the only explanation that makes sense. He's trying to discredit MS-bashers by providing such an excellent example of false and childish anti-MS claims. The original @Stake paper (don't blame me for the format) not only lists vulnerable Linux drivers, it seems to list only Linux drivers. Windows is mentioned exactly once, and only in a vague afterthought kind of way; the focus is on the vulnerability as it exists on Your Favorite OS.

Microsoft Certified Drivers

[Antity]

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:Microsoft Certified Drivers

[Anonymous Coward]

Seems to me that their certification tests aren't worth the bits they're written on

Of course, what does it say about the "many eyes" argument about bugs in OSS code? This problem apparently was not discovered by the Linux community before someone else discovered it......

Re: The headline

[Anonymous Coward]

Flaw Found iIn Ethernet Device Drivers

Your headline makes no sense.

Stupid

[photon317]

This is another example of a so called "security team" finding a minor problem and trumping it up to sound like Armageddon is upon us in an attempt to boost their own visibility and credibility.

Executive Summary of Bug:

Many ethernet drivers on many OSs exhibit this problem. It is possible to send a packet to the target machine which triggers the target machine to send back a very short reply packet. Inside this very short reply packet, there maybe be as many as 30 or so bytes of data that should have been zeros. This data is from some other packet recently sent out by the target machine. This data is:
(1) unlikely to be the data you were looking for (2) extremely short
(3) probably was encrypted before being transmitted the first time if it was truly sensitive information

In the real world, there will probably be many better avenues of attacking a machine than attempting to leverage this exploit. Leveraging this exploit will require a lot of patience and good luck, as well as poor security practices on the target's side to begin with. You have many better things to worry about, move along please.

Re:Stupid

[photon317]

Oh and I might add that this won't work over an IP connection only (e.g. across the net). You need to be on the same ethernet segment as the target. This greatly limits the usefulness again. While we're at it, if you were on their segment, and it's not switched, you likely already are seeing every packet the target machine transmits anyways. Oh and by the way, there's exploits out there already to make most switches give up this data as well, so in all likelyhood this gained you nothing.

effects Linux, NetBSD and Windows

[Anonymous Coward]

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. Why badmouth Microsoft/Windows, when it's clearly a manufacturer/driver-writers issue. Always blaming Microsoft, just lends zero creditability to the worthyness of your point of view. grow up..

Windows is vulnerable through 3rd parties

[Anonymous Coward]

Their shipping product didn't contain the hole, but apparently the sample implementation code they sent out to developers did.

Did you install your network card using the CD that came with it? Guess what--you have no way of knowing if you're vulnerable until Microsoft or the card vendor puts out a list and your card is on it. Silence is not safety.

WARNING: GOATSE REDIRECT

[Anonymous Coward]

Oh, my eyes, my eyes!!!!!!

MS is okay?

[hakalugi]

Microsoft Corporation Information for VU#412115

Date Notified 06/25/2002

Date Modified 01/09/2003 10:55:58 AM

Status Summary: Not Vulnerable

Vendor Statement

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.

Re:Slashdotted your credibility-and everyone sees

[lostboy2]

Well, it's been discussed on /. that news sites sometimes edit their stories without notice. So, it's possible that the article didn't include the bit about which systems are vulnerable when the poster submitted the story.

I'm not saying that this what happened in this case. On the other hand, the article is three days old.

Still, I agree with you about the assumption regarding Windows.

Or maybe

[Mothra the III]

they could allow us to comment on a subject before it gets posted!

Is this a problem with HIPAA?

[lostboy2]

This is beyond the limits of my networking expertise, but does this mean it's possible for sensitive client or medical information to be passed in the padding?

If so, it seems that this would be a problem with HIPAA.

Granted, the extra bits of a 46 byte packet isn't much space, but then a social security number is only 9-characters.

Re:Slashdotted your credibility-and everyone sees

[HiThere]

That's the way I read it too.
OTOH, the point about articles being updated without noice posted was also apropos. It's *not* clear that they fucked up. They may have, or the article may have been edited.

Re:Or maybe Slashdot wont post news unless its ant

[Anonymous Coward]

Please furnish one single, solitary example of _completely baseless_ bashing of MS that you have seen here. From what I have seen, they deserve every lick they take, and then some.

Re:Slashdotted your credibility-and everyone sees

[thelexx]

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

Because not only do the editors dislike MS, but also because MS richly deserves to never be given the benefit of the doubt, on anything, ever again.

exploiting

[Phrack]

Windows CAN be vulnerable. Found several locally. Hardware companies using too much Microsoft example code, I imagine.

Simple to exploit.
Mac OS X/Linux:ping -c 1 -s 0 10.10.10.10
Solaris: ping 10.10.10.10 0 1
Windows: ping -n 1 -l 0 10.10.10.10
(where 10.10.10.10 is, of course, target host). Solaris doesn't seem to even want to *send* the echo request with 0 payload. Then again, I didn't investigate that too hard. IOS will definately not let you specify datagram size small enough to exploit (for that matter, it pads the echo request properly, unlike my test Win2k box with Xircom card.

Collect in favorite packet sniffer and observe. In Ethereal, it's added as Trailer under the Ethernet frame. Don't expect it to make sense.

Routers may or may not impede it. Checking about half a dozen local private class C's, I found 20 machines returning frame data. One linux, a few Windows, and a few VoIP devices. Those were crossing a Cisco L3 switch. It sorta routes, it sorta switches. However, as expected, crossing a 7204 easily screws the pooch.

So, for someone on the outside to make use of this, they'll have to break into a machine elsewhere on your network and setup some automatic exploit. To allow that to happen, you've got big troubles already besides already transmitted frame data.

And anyway, 18 bytes of previously transmitted frame data are not much to worry about. If you're not already deploying the basic security that would foil this.. just get out of the game.

Re:Or maybe Slashdot wont post news unless its ant

[Anonymous Coward]

Thanks for letting us know what an utter imbecilic fucktard you are. Hang out with me? Sure, you hang down at the end of the gun range...

Re:If michael had been the editor...

[Anonymous Coward]

Are you on the side of Seth Finklstein? He's a dick. Michael is much more principled than that guy. If not... OK. Move along. Keep your gripes about Michael to yourself pig.

in the posters defence,

[geekoid]

a great many articles/stories done assume windows, and seldom mention any other OS unless it is expicitly stated.

so for most media Computers == Windows.

This is silly.

[Dagmar d'Surreal]

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.

There are indeed HIPAA issues.

[Ashurnasipal]

Once there are patches available, if you do not apply them, you will be in violation of HIPAA. However, you aren't in trouble if your OS does not yet have a fix available.

HIPAA is pretty forgiving of this sort of predictable technical mishap - one cannot buy anything if products are required to be free of undiscovered flaws! But you are required to follow industry-recognized security practices, and applying all patches for known bugs is definitely covered by that requirement.

Where HIPAA comes down on you like a giant ball-peen hammer is when you knowingly profit from disclosing patient medical records. You'll need a striped suit and some soap-on-a-rope if you get caught doing that. Anything else is not really such a big deal under HIPAA, but of course you set yourself up for civil suit problems if you violate your own security and/or privacy policies (regardless of HIPAA rules).

how serious?

[juan2074]

I wondered the same thing. The only vendor listed as vulnerable was Network Appliance.

Re:how serious?

[MoreBeer]

NetApp has been excellent at addressing previous CERT vulnerabilities (ie DNS resolver client). Also, if you notice, they state the Gigabit 1 NIC is at risk, which leads me to believe their Filers (NAS devices) are more vulnerable than their NetCache devices. Usually, it's Damn Good Practice(tm) to leave your NAS devices _inside_ your LAN.

OTOH, I'm extremely concerned about vendors like Nokia (IP firewalls), Cisco, and off-the-shelf NIC vendors like Intel and 3Com because of the impact of exploiting security devices (firewalls, proxies, IDS, etc).

Not a speed hit at all

[Skapare]

The cost in time needed to pad the frame out to 46 bytes is about the same as the time needed to copy the data over from some buffer when the frame actually is 46 bytes. Now if the driver is so high performance that it never copies anything, and is transmitting into hardware straight from the originally queued packet buffer, then yeah, padding to 46 bytes at this point does cost a wee bit. But how often are you sending so many packets less than this size and needing the performance in the CPU? It's not an issue at all with larger packets.

Editing without "Edit" tags

[Anonymous Coward]

I'm really getting annoyed with these. Editors do something stupid and people comment on it and suddenly, poff, the error is no more.

No "superuser" in VMS

[Ashurnasipal]

But that's true of ,say, unix 'root' vs Vax VMS 'superuser'.

There is no such thing as VMS superuser. VMS never used lame 40-year old security paradigms such as 'superuser'. Windows security is superficially like Unix because Windows NT is a broken, dumbed-down version of VMS. MS broke the VMS kernel model when they spliced in graphics routines and mouse drivers at inappropriate levels - it's hard to explain in unix terms, the kernels are fundamentally different.

Out of the box, the VMS account SYSTEM has CMKRNL and SETPRIV privileges, which allow a knowledgeable user logged in as SYSTEM to do all the stuff root can do under unix. However, you can delete that account entirely, or remove these privileges, and VMS still works fine. I have used a VMS box where there were no user accounts with SETPRIV (admittedly an incredibly paranoid site) and the system worked fine.

Ted T'so's work with Linux capabilities is bringing VMS-style security to linux. This is one of the main reasons that linux is NOT unix, it's BETTER than unix. If you don't understand this, research T'so's work, and look into the way Red Hat has stripped all privs from their ntp daemon - except the ability to set the hardware clock, something normally restricted to root.

That's the way it should be, damnit!

[somethingwicked]

I was referring to the fact that it's a point and click operation to assign someone administrative priviledges

There is absolutely NOTHING wrong with this being easy to do! Would you prefer to have to do ten complicated steps to accomplish the same task??? It still will not prevent it from being done and will only take more time.

The fault lies in how easy it is to convince most people to assign admin privileges to someone else.

I will, however, agree that administative privileges are handed out many times when not necessary.

Re:That's the way it should be, damnit!

[Anonymous Coward]

IANALZ, but su is just as easy as changing a setting in the Control Panel.

That aside, I agree with your post (and realize you weren't arguing that it is difficult neccessarily)

Re:Microsoft Bashing

[MrScience]

Hmm... Too bad the facts are in your way. Of course, I understand that FUDers don't bother looking at facts.

Licensed2Blunder

[Anonymous Coward]

> Since they don't specify the OS, I'm assuming
> these are drivers for Windows."

And I'm assuming Licensed2Hack is 8 years old. I guess our assumptions are worth each other.

Re:Licensed2Blunder

[cookiepus]

His assumption was valid, since there tend not to be open source drivers for anything.

Comment removed

[account_deleted]

Comment removed based on user account deletion

YOU ARE WRONG!

[Anonymous Coward]

From CERT Advisory:
[...]
MandrakeSoft Unknown 3-Jan-2003
Microsoft Corporation Not Vulnerable 3-Jan-2003
MontaVista Software Unknown 3-Jan-2003
NEC Corporation Not Vulnerable 3-Jan-2003
NetBSD Unknown 3-Jan-2003
NetScreen Unknown 3-Jan-2003
Network Appliance Vulnerable 8-Jan-2003
Nokia Unknown 3-Jan-2003
Nortel Networks Unknown 3-Jan-2003
OpenBSD Unknown 3-Jan-2003
Openwall GNU/*/Linux Unknown 3-Jan-2003
Red Hat Inc. Unknown 3-Jan-2003
[...]

Oh god.. shut up

[Anonymous Coward]

Someone mod the parent down.

He's a troll or a flamebaiter who really doesn't have a clue what he's talking about. (This is from a person who's been coding C++, C and MFC for many years.)

Re:Oh god.. shut up

[Anonymous Coward]

So *you* are that genius who uses C++ and MFC to write drivers?

The OP (me) is someone who uses ASM and C to write *stable* drivers for a living, and who reads and follows the docs before they crash customers machines.

And for the dipshit who invented those #include lines in that other follow-up: I wonder what those RtlZeroMemory and RtlFillMemory entries in kernel32.dll are good for, if they aren't being used.

This thread made something clear to me. Half of the windows "experts" on slashdot don't know what they're talking about, and the other half are fabricating evidence where reality doesn't provide it.

Does nobody read the actual report???

[Anonymous Coward]

I can't believe nobody (or at least, nobody modded up) has actually read the actual report available in PDF form.

Lots of posts talk about "45 bytes" of information. However, only the extra bytes required to pad up potentially contain leaked data. The examples shown in the report have either 17 or 18 bytes of leaked data.

Just how useful are bytes 27-45 from the start of some previous allocation? Not very.

Clue.

[twitter]

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.

Re:Clue.

[Keith_Beef]

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.

But to quote RFC 1042

When necessary, the data field should be padded (with octets of zero) to meet the IEEE 802 minimum frame size requirements.

So, while it isn't clear where the values of zero should come from, it looks clear to me that they should be zeroe values, and not values pulled from some previously used buffer or packet.

arp

[Anonymous Coward]

If I remember correctly, the same problem was found with regard to the padding of arp packets about a year ago in linux drivers.

Perhaps reading would help draw conclusions

[TheAncientHacker]

The Microsoft statement says that Windows doesn't ship with the bug and no 3rd party driver shipped with Windows have the bug but if you build your own driver from their sample code in the Device Driver kit without changes then it is possible that your code could have the bug. And that they're changing the sample code to include the fix in the source. Maybe drawing a conclusion based on what's written would be better than just "MS are weasels"

don't be so glad

[twitter]

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

Heh! What this means is the same thing as always. Your network security is only as good as your weakest link. If you have an M$ box on your local net and someone owns it, as is so easy to do, it can sniff packets from other silly OS that don't use SSH or similar for ALL local comunications. Let's say I type a password on a local computer and that password gets padded into that ethernet frame. Ha, the M$ machine has got you. A more sinister device to leak, would be your "broadband router" box that sits next to your cable modem. If it leaks and you have an owned M$ box on your network, that M$ box can be used to request small packets through the router and thus sniff your whole network's traffic. Failure and comprimise are generally the result of a combination of minor flaws, unless you are M$ and you just make an email client that automatically executes code, sound and what not from unknown third parties. The weak link breaks a chain.

Trolls in the caves of /.

[Czernobog]

Obvious but necessary: If articles could be modded (a la kuro5hin), this would have been a -1 Troll....

Re: Read the f*cking CERT note

[pc486]

Like other posters have stated, Windows is vulnerable with the NIC drivers being the problem. Microsoft claims it doesn't ship bad drivers but my Xircom CardBus Ethernet II is vunerable (Win2k). I believe I got the driver on Windows Update :).

Delay is from CERT

[Anonymous Coward]

@stake issued this alert to CERT in late 2001. The delay was caused by CERT's insistence that they take the time to contact all of the OS/driver vendors before releasing.

That's one of the problems with "responsible reporting"; the timelines get all screwed up for those who follow the rules.

Read the articles before posting, please?

[cascadefx]

Blockquoth the poster:

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.

First off, the linked eWeek article specifically states:

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

Not to defend eWeek's journalistic or technical integrity, but they do a pretty good job of summing up the pertinent facts... such as the vulerability affecting the above implementations.

Secondly, This is a Hyperlink. They are sometimes used on the World Wide Web, to link relevant and useful resources together. Had you followed this particular link, you would have found the CERT advisory about the problem AND a link the @Stake's own advisory and white paper about the problem.

Thank you

Re:Slashdotted your credibility-and everyone sees

[Arandir]

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.

It's called dogmatism.

There's a significant number of Open Source advocates, including nearly all Slashdot editors, who take it as an article of religious faith that Linux has no bugs, Windows has three bugs per line of code, and other operating systems simply do not exist.

Thus, when they see "flaw found in...", they automatically assume it must be in Windows, and if it ever occured in Linux, it must have been fixed a long long time ago.

Real world example with TCP

[Anonymous Coward]

how about a real world example then. I was developing some cgi apps, and I had a bug that caused an app to segfault as soon as it started (stupid mistake on my part). But I looked at it in ethereal and started seeing strange things (#kernelnewbies):

Dec 17 13:11:43 Russ|werk: ummm
Dec 17 13:11:53 Russ|werk: I think the irc dcc nat module is leaking information
Dec 17 13:12:08 Russ|werk: I keep seeing irc nicks in unrelated tcp packets
Dec 17 13:12:16 mcp: uh
Dec 17 13:12:17 sarnold: Russ|werk: oy vey
Dec 17 13:12:24 Russ|werk: my webserver is not responing to a cgi request for some reason
Dec 17 13:12:37 Russ|werk: and instead, it returns 5 bytes of randomish payload
Dec 17 13:12:37 sarnold: Russ|werk: what version?
Dec 17 13:12:55 Russ|werk: 2.4.18-rmk4
Dec 17 13:13:08 sarnold: Russ|werk: humm, that might be a known issue then
Dec 17 13:13:35 Russ|werk: I don't remember reading about such a security flaw
Dec 17 13:14:06 Russ|werk: its not always an IRC nick, sometimes, its 04 05 b4 6d 69 (hex)
Dec 17 13:14:43 Russ|werk: which I think might be something in the webserver
Dec 17 13:14:58 Russ|werk: since the host name starts with 6e 65 74 6d 69
Dec 17 13:15:10 Russ|werk: but the webserver should not have access to irc nicks
Dec 17 13:16:30 sarnold: Russ|werk: oooh, the irc conntrack module bug i'm thinking of opened too many ports; no mention of leaking info
Dec 17 13:16:37 -- brodo has quit (Quit: reboot)
Dec 17 13:16:39 Russ|werk: the last vulerability in irc dcc nat was 2.4.18-pre8
Dec 17 13:17:44 sarnold: indeed; but the last bug in conntrack appears to be fixed no earlier than 2.4.19-pre6
Dec 17 13:17:56 -- luca_ has quit (Quit: Cambio server...)
Dec 17 13:20:26 sarnold: Russ|werk: please let harald welte know about this :) (laforge associated with gnumonks, the org)

Seeing this release, I now know what the issue is (the network driver in question is 8139too)

here is a ethereal capture:
http://russ.dhs.org:8000/ircdccnat_leak. libpcap

Seems your assumption is wrong...

[Anonymous Coward]

As of the time of this post, your comment has 9 replies. So that makes at least 10 people (including me) who read it. Heh.

Re:Limitations of the exploit

[Anonymous Coward]

I do not think this problem is limited to retransmition of *sent* packets. The "atstack_ehterleak_report-1.pdf" demostrates the problem on a Linux 2.4 macine with the xirc2ps_cs driver. The demostration leaks "Mozilla/5.0 (Wi" and "Windows NT 5.0; e" which suggests to me that either a) the linux machine has a web browser that is doing user-agent snooping or the more probable b) the linux machine is the web server and leaking *recieved* packets. I'm also aware of a great deal of SMTP traffic that people consider "sensitive information." Just because some HIPAA act says what doctor's can and can not do doesn't mean they are following... oh, you would probably feel better if I did not go into details.

It is also not clear that all drivers will just re-allocate existing send or recieve buffers but may possibly allocate other unused portions of kernel space. This might include providing information about a previously used IPsec or WiFi session key. Unlike Public-Private keys used during initial handshaking which tend to be 1024 bits in length, session keys tend to be around 128 bits (16 bytes) in length and could be fully revealed in a 46 byte buffer and then used to decode any capture of the previous session.

This really is a nasty exploit. Also, the examples given might lead someone into a false sense of security just by blocking ICMP, the reality is that UDP/IP headers can be as small as 28 bytes leaving room for UDP traffic to also produce this link layer bug.

If you have to be inside the nearest router...

[Kjella]

...you have tons of better ways to do this. Put a key sniffer on his keyboard, or listen to the EM-field of his screen or bug his place. Or simply get a life.

Kjella

Maybe I should be more worried, but...

[iceT]

How much sensitive information could be in less that 46 bytes? Granted, it's a bad programming practice, but seriously, what are the odds that something important like the formula to Willie Wonkas Ever-lasting Gobstopper would be in those padded bytes?

Based on the typical internet usage, I'm guessing they'd get up to 45 bytes of flesh-tone JPEG data, or the words "you to can have up 3 or 4 inches added to yo".

Re:Slashdotted your credibility-and everyone sees

[cookiepus]

WHY would you assume that?

Because it mentioned HARDWARE DRIVERS, which everyone knows don't exist for Linux.

Re:Or maybe Slashdot wont post news unless its ant

[varith]

The post of the link itself. The assumption was made that only MS was vulnerable when MS was not vulnerable at all according to CERT. That's pretty baseless.

What about alarms

[Allnighterking]

A lot of equipment in a network uses 9 consecutive 0's as an alarm signal. Hence the telcom standard of using 6 0's then 6 1's as the "pad" (oh and yes you do have to check for 9 legit 0's in a row and make "adjustments") I can see it now every time my nic sends a short packet alarms are going off all over the telco route.. *grin*... the other point is. Just because it does it... doesn't mean it's signifigant. In other words is enough real data leaked and is it leaked in a consecutive manor. Can I reconstruct useful info from this data or is this an over reaction of coulda woulda shoulda maybe might. In other words if I send 10000 packets of data with 1% short that means 10 short packets. Now if this is taken from random data streams on the box in a real time manor then it won't be

A. Consecutive data
B. Enough to construct meaningful information.

I don't really think you have to worry about your credit card numbers being transmitted in the clear here. Now if you have a system that is constantly transmitting (a number of systems do, do this ) then you do have a serious leak. In two seconds of continuous transmission a lot of data can get out if it's 100% padding. Maybe we can finally get the source code to M$ this way by monitoring what comes out of Redmond :)

Re:Or maybe Slashdot wont post news unless its ant

[Anonymous Coward]

here you go. First of all, the article wasn't even true. Second of all, even if it was true, there is nothing to backup a "Microsoft is bad" claim from it - but that's what everyone did.

Lies, Damned lies, and Microsoft

[Black Copter Control]

[ Microsoft] Vendor Statement
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.

My reading: Microsoft doesn't make any vulnerable drivers (Microsoft doesn't make (m)any Ethernet drivers). Their sample code is vulnerable, and in the future they will be testing drivers for this bug before certifying them. -- Current MS certified drivers May be vulnerable -- especially if they used MS's suggested code snippet.

In short, YMMV.

Re:Lies, Damned lies, and Microsoft

[Black Copter Control]

From the rapidity of MS's response (same day), I'm going to guess that they are few (if any) drivers actually made by Microsoft that were addressed by their response. I would also guess that there are many drivers that ship WITH current MS operating systems (2000, XP, CE) that are vulnerable, but many (most) people are going to presume from MSs response that this is not the case -- and MS knows this.

In other words, if I'm right, MS constructively lied in their declaration.

FALSE GOATSE ALERT, MOD DOWN

[Anonymous Coward]

Liar lair pants on fire!

Oh great, now my computer is broadcasting an IP

[Anonymous Coward]

Should I click on that pop-up now?

Myth: NT TCP/IP stack is based on BSD

[m_pll]

Considering that MS' TCP/IP stack is an implentation of the BSD stack...

This is simply not true. See this article for details.

So what???

[Anonymous Coward]

So an attacker could get chunks of (theoretically) up to 45 bytes from one of several sensitive sources. That sounds pretty bad, right? But wait - how does the attacker know what source the data came from? Even investigating source code to determine which of the sensitive sources it is, the data will either (a) be the same every time, in which case the exposure is very small, or (b) only tell you the general method for allocating the space which contains the sensitive data and therefore the kinds of things it *could* contain. The big BUT here is how does an attacker know what to do with the data? Sure, it *COULD* be your SSH private key, but how would anyone distinguish that from either the other thousands or millions of bytes he'll have to sift through or the other thousands of potentially sensitive pieces of data it could be? You can't really tell the difference between a public key, a private key, the value of the static variable foo, the address of the stack pointer last week Tuesday at 12:16:22.655am and data from an image of what the user ate for breakfast this morning. Therefore this bug is just that - an annoying bug. As a vulnerability it's right up there with the Michaelangelo virus in terms of threat severity; ie, it's not one.

Re: Fix within a week? LINUX - NO WAY!

[karlm]

MS statements aren't very reliable. Remember the fmous "that vulnerability is purely theoretical" claims? Someone else here claimed they got a vulnerable driver from Windows Update. Maybe MS is nice and distributes 3rd party drivers through thier update service, but I doubt they've thuroughly tested all of the drivers they ship on thier CD.

Unless you've personally tested your driver, I'd play it safe and go with the statement of the publishers: Linux, NetBSD, and Windows are vulnerable.

You also seem to wish that Linux would relase a statement. Linux cannot release a statement. Linus can. Red Hat can. Mandrake can. Linux cannot. Windows cannot. Cobol cannot. VB Script cannot.

Looks like the shoe is on at least three feet now, but some of the feet appear to be in denial. Oh, and "haha" doesn't help your post look informed or intelligent.

Secure your FreeBSD box now!

[Anonymous Coward]

diff /sys/net/if_ethersubr.c.orig /sys/net/if_ethersubr.c
385a386,393
> if (m -> m_flags & M_PKTHDR && m -> m_pkthdr.len < ETHER_MIN_LEN)
> {
> m = m_pullup (m, m -> m_pkthdr.len);
> if (!m) return ENOBUFS;
> bzero (mtod (m, caddr_t) + m -> m_pkthdr.len,
> ETHER_MIN_LEN - m -> m_pkthdr.len);
> }
>

(Patch mangled due to lameness filter - sorry)

This message sent via this patch. I feel much better knowing the three feet of ethernet cable from my PC to my DSL modem is safe.

More seriously, many DSL systems use transparent ethernet encapsulation, so those padding bytes could be going outside your building, and the buffers they originally came from may have been received on another, internal, network i/f.

S.

Let all trolls shut up

[Anonymous Coward]

The real trolls in this discussion being the "it must be windows" submitter and the "this is going to make sparks" editor that accepted it, of course.

Last Post!

[alpg]

...you might as well skip the Xmas celebration completely, and instead
sit in front of your linux computer playing with the all-new-and-improved
linux kernel version.
-- Linus Torvalds

- this post brought to you by the Automated Last Post Generator...