[Dshield] Ethernet Vulnerability

Lauro, John 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
> following
> possible situation:
> 
> innocent decides to do some online purchasing.  In doing so,
innocent
> places
> an order issuing her credit card number (16 bytes long).  Innocent
> continues
> on with her online purchasing.  So if the minimum frame on her NIC
that is
> sent out requires >= 16 bytes of padding and that cc number just
happens
> to
> be in that padding I would think this to be not a very good thing.
Of
> course, .  It's true that the chance of this happening is miniscule
and
> that
> that information will be chopped up among frames but it doesn't take
a
> rocket scientist who knows about this vulnerability to gain access
to
> innocent's network segment and sniff and pull apart the traffic to
put
> those
> "null pads" back together to get  some kind of useful information.
> 
> At least this is how I interpret the malisciousness of this
vulnerability.
> I admit, however, I am not an IP guru so I might see this from a
slightly
> 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 mailing list