Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Flaw Found iIn Ethernet Device Drivers

Hemos posted more than 11 years ago | from the yay-for-security-bugs dept.

Bug 429

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

Sorry! There are no comments related to the filter you selected.

Hah! (2, Funny)

Anonymous Coward | more than 11 years ago | (#5046138)

At least it didn't foil my first post.

Re:Hah! (-1)

Anonymous Coward | more than 11 years ago | (#5046269)

Wow, I'm floored. Thank you guys so much for the compliment. I love you guys.

Or maybe (5, Informative)

Anonymous Coward | more than 11 years ago | (#5046139)

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

Re:Or maybe (3, Informative)

packeteer (566398) | more than 11 years ago | (#5046197)

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.

Or maybe (2)

forged (206127) | more than 11 years ago | (#5046226)

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

Re:Or maybe (2, Insightful)

ottawanker (597020) | more than 11 years ago | (#5046246)

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 (2)

loply (571615) | more than 11 years ago | (#5046250)

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 (3, Informative)

Ashran (107876) | more than 11 years ago | (#5046308)

A link [cert.org] from the article has a list of vulnerable vendors.
#
Quote
Microsoft Corporation Not Vulnerable 3-Jan-2003

If michael had been the editor... (-1)

MondoMor (262881) | more than 11 years ago | (#5046313)

He'd have had some smartassed sarcastic anti-Microsoft, anti-IP, anti-censorship addition to the story, and then had to delete it once HE read your post and then actually bothered to read the article.

The ugly truth: michael is a hypocrite and a jerk.

Flaw found.... (3, Funny)

Anonymous Coward | more than 11 years ago | (#5046140)

...."iln" story title

Surprise (-1, Redundant)

billybob2001 (234675) | more than 11 years ago | (#5046141)

Flaw Found iIn Slashdot Headlines!

Dictionary on the present list for this December!

Flaws iln the Headline Too! (-1, Redundant)

goldspider (445116) | more than 11 years ago | (#5046143)

Really, it's the headline for Christ's sake!

Linux isn't effected (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5046144)

Because linux cant even get ps/2 mice working (oh wait, thats the gnu/hurd)

Re:Linux isn't effected (-1, Offtopic)

Silicone (569267) | more than 11 years ago | (#5046224)

funny, mine works just fine with scroll button and all...

You assume too much (3, Informative)

GroovBird (209391) | more than 11 years ago | (#5046145)

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 (5, Informative)

GroovBird (209391) | more than 11 years ago | (#5046157)

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

Re:You assume too much (3, Funny)

nmg196 (184961) | more than 11 years ago | (#5046225)

> 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 (0)

Anonymous Coward | more than 11 years ago | (#5046259)

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 (5, Insightful)

the_mice (163224) | more than 11 years ago | (#5046277)

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

Re:read it again (0)

Anonymous Coward | more than 11 years ago | (#5046286)

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

Re:read it again (1)

dWhisper (318846) | more than 11 years ago | (#5046326)

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.

Re:You assume too much (3, Interesting)

Daniel Phillips (238627) | more than 11 years ago | (#5046291)

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

You mean Microsoft said they aren't vulnerable. [cert.org] But look at these weasel words: "However, we have found samples in our documentation that, when compiled without alteration, could yield a driver that could contain this issue." Draw your own conclusions.

The Nature of the CERT list (1)

dWhisper (318846) | more than 11 years ago | (#5046306)

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:You assume too much (1)

seosamh (158550) | more than 11 years ago | (#5046158)

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

Not Exactly (5, Insightful)

starX (306011) | more than 11 years ago | (#5046171)

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.

Re:You assume too much (1)

DanThe Bike (87732) | more than 11 years ago | (#5046173)

From the CERT advisory though:
Microsoft Corporation
Not Vulnerable 3-Jan-2003
The details [cert.org] would imply that windows is fine, but that some documented examples aren't.

Read between the lines... (2)

leonbrooks (8043) | more than 11 years ago | (#5046331)

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

According to the CERT... (0)

Anonymous Coward | more than 11 years ago | (#5046181)

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 ?

At least read it before you post it (-1, Redundant)

pvera (250260) | more than 11 years ago | (#5046146)

Is it really that hard to read an article before writing a small blurb and posting it?

this is weird (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5046148)

have you ever posted in safari, for Mac OS X? It is simply the world's fastest browser!

Linux, NetBSD and windows. (-1, Redundant)

ViVeLaMe (305695) | more than 11 years ago | (#5046150)

Seems like on slashdot, even the one who fscking SUBMIT the story can't be bothered to read it.
Amazing...

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

Read the f*cking article. (4, Informative)

Alranor (472986) | more than 11 years ago | (#5046153)

Since they don't specify the OS

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


OK, it's slashdot, so we expect people to post comments without reading the article, but it's a little ridiculous that the submitter didn't even bother.

Re:Read the f*cking article. (-1)

Daengbo (523424) | more than 11 years ago | (#5046201)

but it's a little ridiculous that the submitter didn't even bother.
It's also a little rediculous that you have a 5, interesting, while the person who posted the exact same material and opinions a minute before you got 0,redundant. Rediculous or amazing.
Go ahead, suck my Karma for calling a spade a spade

Re:Read the f*cking article. (2)

Alranor (472986) | more than 11 years ago | (#5046255)

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

Daengbo (523424) | more than 11 years ago | (#5046332)

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.

HEMOS DIDN'T READ IT EITHER!!! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5046267)

That's his fucking job on this site, yet he, like all the other editors, simply posts whatever shit they want without even checking the submitter's source. On top of that, the blatent typo in the FUCKING ARTICLE TITLE just goes to show how much this site sucks.

Come on people, MOD PARENT UP. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5046360)

Hemos really didn't check the source, either. It *IS* his alleged job here.

Re:Read the f*cking article. (2, Informative)

fulgan (116418) | more than 11 years ago | (#5046341)

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)

Flaw Found iIn Slashdot Editors (5, Funny)

Anonymous Coward | more than 11 years ago | (#5046154)

Anonymous Coward writes "English speakers have discovered a serious flaw that may be present in many Slashdot editors that is causing the devices to broadcast poor journalism over networks. Seems the editors couldn't be bothered with a Spellcheck call. Slashdot trolls have their typical (puffy, low on tech details) take on it here. Since a fault was found, Slashdot is assuming the problem is with Windows."

Re:Flaw Found iIn Slashdot Editors (2, Funny)

edbarrett (150317) | more than 11 years ago | (#5046265)

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

well (5, Interesting)

REBloomfield (550182) | more than 11 years ago | (#5046155)

lets hope this isn't globally exploitable, as I can't imagine every manufacturer of every card is going to fix this....

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

Re:well (1)

AnEmbodiedMind (612071) | more than 11 years ago | (#5046270)

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 (1, Interesting)

lederhosen (612610) | more than 11 years ago | (#5046281)

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

common fault (5, Informative)

oliverthered (187439) | more than 11 years ago | (#5046159)

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 (4, Interesting)

PhilHibbs (4537) | more than 11 years ago | (#5046321)

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.

And MS-Word ships same over the net... (2)

leonbrooks (8043) | more than 11 years ago | (#5046338)

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

Wow.. (2, Funny)

brandonsr (550431) | more than 11 years ago | (#5046160)

Hey, that's super uhh.. Does slashdot broadcast my IP?

Re:Wow.. (5, Informative)

NuMessiah (7486) | more than 11 years ago | (#5046198)

Well, we are speaking about the ethernet packets here. As soon as the packet hits the router or bridge only the IP (or ICMP ...) protocol partition is transferred. So this bug actualy can't be globaly exploited, only within the switched eternet networks.

bb4now,
PMC

Re:Wow.. (4, Informative)

Large Green Mallard (31462) | more than 11 years ago | (#5046292)

Close. Hits a router, or something routing (ie a PC) and the ethernet frame becomes just another TCP/IP packet.

A bridge doesn't route, it only segments ethernet segments and reduces the amount of traffic going to the section it is in front of.

Re:Wow.. (2, Insightful)

Anonymous Coward | more than 11 years ago | (#5046307)

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

A lame bug, but at least not a very exploitably-useful one.

Re:Wow.. (0)

Anonymous Coward | more than 11 years ago | (#5046312)

You mean exploitable in a remote compromise?

The exploit is data leekage, not a root compromise or a buffer overflow.

Re:Wow.. (1)

hwprog (575295) | more than 11 years ago | (#5046357)

If I'm reading the articles correctly (which I may not be :-) then the bug seems to apply to IP packets also. The same flaw seems to exist for IP packets shorter than 46 bytes which _should_ be padded with octets of 0, but most drivers are just sending the data from the previous packet. Since the specs are hazy on which protocol layer is doing the padding and so the drivers differ in their approach, you may get parts of the previous IP packet or parts of the previous ethernet packet transmitted to remote hosts via IP.

Re:Wow.. (2, Insightful)

NuMessiah (7486) | more than 11 years ago | (#5046361)

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

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

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

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

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

bb4now,
PMC

Re:Wow.. (1)

SEWilco (27983) | more than 11 years ago | (#5046325)

Does slashdot broadcast my IP?

Well, I've never had one of those helpfully informative windows pop up on Slashdot to warn me about my IP address being broadcast!

:-)

moron FUDge being discovered..... (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5046165)

in the payper liesense, falsely advertised, hostage ransom stock markup kode blew scams, foistered on US buy the ill eagle kingdumb [trustworthycomputing.com] .

tell 'em robbIE.

moron FUDge being discovered.....-5 @40 (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5046202)

you slimIE troll, you forgot:

look for: va.msn.net, ticker: (VAST) [trustworthycomputing.com] ?

you are so immature. you will NEVER be a FraUDuleNT stock markup billyunheir. you are on EVERYBODY's foems list, from now on, including retroactive?

A call (0)

Anonymous Coward | more than 11 years ago | (#5046166)

If any of the linux kernel hackers are reading this, don't just sit there, fix those network modules.

talk... (-1, Troll)

m1chael (636773) | more than 11 years ago | (#5046174)

about anal retentive posters. how them sound so elitest and infallable...

narf!

Links to actual article (4, Informative)

tomlouie (264519) | more than 11 years ago | (#5046176)

Here's a link to the original article:

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

Here's a link to the CERT notice:

http://www.kb.cert.org/vuls/id/412115

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

Enjoy.

Tom

Dont assume (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5046177)

It said in many drivers. That includes a lot more then windows in my opinion but hey. Since the Linux Drivers are open source why don't you look at the code before making assumptions. In this case the assumption just makes an ass out of you.

I can read! (5, Interesting)

1010011010 (53039) | more than 11 years ago | (#5046179)


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

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

SSH (3, Insightful)

mmol_6453 (231450) | more than 11 years ago | (#5046196)

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 (5, Informative)

42forty-two42 (532340) | more than 11 years ago | (#5046248)

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

Re:SSH (0, Offtopic)

Large Green Mallard (31462) | more than 11 years ago | (#5046262)

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 (0)

Anonymous Coward | more than 11 years ago | (#5046348)

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

ian

Re:I can read! (5, Informative)

Raphael (18701) | more than 11 years ago | (#5046294)

The pad of older data in a 46 byte header can't contain a lot of data.

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

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

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

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

Not a hard fix for open source (3, Insightful)

Arethan (223197) | more than 11 years ago | (#5046182)

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 (1)

reanjr (588767) | more than 11 years ago | (#5046195)

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

...or... (2)

leonbrooks (8043) | more than 11 years ago | (#5046363)

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

Re:Not a hard fix for open source (1, Funny)

Anonymous Coward | more than 11 years ago | (#5046215)

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 (3, Informative)

Richard_at_work (517087) | more than 11 years ago | (#5046298)

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 (0)

Anonymous Coward | more than 11 years ago | (#5046351)

Who writes the CERT advisories?

IN SOVIET RUSSIA (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5046186)

The flaw finds YOU!!!

When you assume... (0, Offtopic)

mightor (529970) | more than 11 years ago | (#5046191)

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

Re:When you assume... (-1, Offtopic)

falzer (224563) | more than 11 years ago | (#5046205)

AGHH! What the hell was that? I'm blind now!

Details from @stake (5, Informative)

Unfallen (114859) | more than 11 years ago | (#5046200)

Re:Details from @stake (5, Informative)

1010011010 (53039) | more than 11 years ago | (#5046247)

So, @Stake is just figuring this out [google.com] , eh?

It is possible to read parts of a remote machines memory. To be specific, it would have to be memory recently freed/swapped to disk. Consider this for example:
int main(int argc, char **argv[], char **envp[])
{
char *ptr=0; /* We take a rather large chunk of memory and fill it with A's */
int val, i;

while(1) {
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.

Your computer is broadcasting sensitive info ! (5, Funny)

FullClip (139644) | more than 11 years ago | (#5046203)

Oh my God, they were right all along ;)

deja vu..... (3, Informative)

taviso (566920) | more than 11 years ago | (#5046207)

here [google.com] is a bugtraq thread from a year ago, describing a similar sounding problem...

MS says that they are NOT vulnerable (1)

tetrode (32267) | more than 11 years ago | (#5046209)

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

Mark

Slow newsday for eweek then. (3, Interesting)

Anonymous Coward | more than 11 years ago | (#5046211)

Just tested this with Ethereal on W2K.

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

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

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

Re:Slow newsday for eweek then. (0)

Anonymous Coward | more than 11 years ago | (#5046288)

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. (3, Informative)

sboyko (537649) | more than 11 years ago | (#5046315)

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

OpenBSD (3, Funny)

Talisman (39902) | more than 11 years ago | (#5046233)

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? [remail.org]

Re:OpenBSD (0)

Anonymous Coward | more than 11 years ago | (#5046371)

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!

Why is this "devastating"? (3, Insightful)

Dwonis (52652) | more than 11 years ago | (#5046243)

Why is this "devastating"? People can sniff ethernet networks anyway? People don't rely solely on a switch for your network security, right?? (Who am I kidding? Of course someone does. Sigh.)

Slashdotted your credibility-and everyone sees it (5, Interesting)

somethingwicked (260651) | more than 11 years ago | (#5046271)

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

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

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

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

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

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

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

@stake Advisory (2)

semaj (172655) | more than 11 years ago | (#5046276)

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

It also shows sample frame captures illustrating leakage of HTTP traffic.

Flaw Found iIn Slashdot News Title (4, Funny)

Satoshi Harada (634776) | more than 11 years ago | (#5046284)

At least it isn't a dupe...

Good gods, RTFA (2, Insightful)

Kourino (206616) | more than 11 years ago | (#5046301)

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?

Who honestly cares? (0)

Anonymous Coward | more than 11 years ago | (#5046311)

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?

This is not true (-1)

Anonymous Coward | more than 11 years ago | (#5046327)

This is not true! At least I don't want to believe it... I just installed my D-Link DI 604. Sigh...

moron FUDging the b00ks... (0)

Anonymous Coward | more than 11 years ago | (#5046328)

buy the #'s?

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

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

see also: bill&art's accelleNT ADventure?

see also: va.msn.net, ticker: (VAST) [trustworthycomputing.com] ?

wIEnIE boyz (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5046362)

quit whining. take the test drive. it won't hurt a byte. trust US, & the 'natural' markup forceUS. uid be better off. go watch tv. folks WHOaRE a lot smarter/greedier than any of US can imagine, are 'taking care' of 'things', for US. chill out. can't you see we're trying to move some vdo games here?

Oh god, lets hype it all up (5, Insightful)

Anonymous Coward | more than 11 years ago | (#5046335)

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

Mod me however you want, I'm a coward to /. but this will be the same position I give the Fortune 500 company I work for. /me wonders if my VP will mod me "troll" or "flamebait" =P

The drivers comply with the RFC (5, Informative)

dcs (42578) | more than 11 years ago | (#5046349)

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

RFC 2119 says "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

Is this vulnerability really useful? (2)

MyNameIsFred (543994) | more than 11 years ago | (#5046354)

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?

Looks pretty harmless (5, Insightful)

heikkile (111814) | more than 11 years ago | (#5046374)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?