[Dshield] Ethernet Vulnerability
jlauro at umflint.edu
Thu Jan 9 16:53:13 GMT 2003
> -----Original Message-----
> From: Conner, Jim [mailto:jconner at uslec.com]
> Sent: Thursday, January 09, 2003 11:27 AM
> To: 'list at dshield.org'
> Subject: RE: [Dshield] Ethernet Vulnerability
> |-----Original Message-----
> |From: Johannes Ullrich [mailto:jullrich at euclidian.com]
> |Sent: Thursday, January 09, 2003 10:33 AM
> |To: list at dshield.org
> |Subject: Re: [Dshield] Ethernet Vulnerability
> |> This one is critical everyone.
> |> Not really. Ethernet leaks information. This is, at best, a
> |> different manifestation of an existing risk.
> |Depends on what is leaked. I guess there are two options:
> |- prior frames:
> | no big deal. Because these frames where already send across the
> |same wire a short time ago.
> I was under the impression that this was a big deal because of the
> possible situation:
> innocent decides to do some online purchasing. In doing so,
> an order issuing her credit card number (16 bytes long). Innocent
> on with her online purchasing. So if the minimum frame on her NIC
> sent out requires >= 16 bytes of padding and that cc number just
> be in that padding I would think this to be not a very good thing.
> course, . It's true that the chance of this happening is miniscule
> that information will be chopped up among frames but it doesn't take
> rocket scientist who knows about this vulnerability to gain access
> innocent's network segment and sniff and pull apart the traffic to
> "null pads" back together to get some kind of useful information.
> At least this is how I interpret the malisciousness of this
> I admit, however, I am not an IP guru so I might see this from a
> incorrect light. I could have this completely wrong.
I should go back and reread it... but from what I understand is you
could get those extra bytes forwarded all the way back from a remote
subnet. Even if that's not the case, it would still allow you to
bypass a switch that might of prevented the sniffing.
> |- random kernel memory
> | only an issue if the attacker knows where the memory comes from,
> |or worse, if the attacker can 'request' which part of the memory is
> |used. Either way, very hard to get much useful out of this.
> |I guess the real question is 'why'? is it so hard to pad with '0'?
I agree, but strangely enough, sometimes a compiler will optimize that
out, if you don't flag the variable correctly and the compiler notices
those bytes are never used by the code again...
More information about the list