[linux-l] Re: [linux-l] Re: [linux-l] [Ethernet] Datenleck über ungenutzte Bereiche in Frames

Steffen Dettmer steffen at dett.de
Fr Jan 10 21:36:14 CET 2003


* Jan-Benedict Glaw wrote on Fri, Jan 10, 2003 at 16:39 +0100:
> On Fri, 2003-01-10 16:08:32 +0100, Steffen Dettmer <steffen at dett.de>
> wrote in message <20030110160832.A3361 at dx.net.de>:
> > * Pascal Volk wrote on Fri, Jan 10, 2003 at 15:22 +0100:
> > > http://cert.uni-stuttgart.de/ticker/article.php?mid=1053
> > > 
> > > Was wird denn in dieser Situation angeraten, ausser 2.4.19-er
> > > Kernel kompiliren oder Rechner vom Netz nehmen?
> > 
> > unverschlüsselte Kommunikation aktiv. Jeder Router packt ja
> > ein neues Padding rein, weil ja neue Ethernetframes gebaut
> > werden. Damit kann ein externer Angreifer nur die Daten des
> 
> Sicher? Ich hab' mir mal gerade so frei 'raus aus'm Bauch ein paar
> Treiber angeguckt. Ein paar schieben immer nur ~ 1K5B hin und her. Da
> wäre die Chance, den alten Müll mit zu routen durchaus gegeben
> (zumindest unter Linux), vorausgesetzt, die IPv4-Schicht 0x00't die
> überhängenden Buffer nicht nochmal und man hat passend dumme
> Kartentreiber...

Das reicht nicht an Vorraussetzungen denke ich. Ich hab mir mal
eepro100.c exemplarisch angegeuckt:

> eepro100.c:     skb = dev_alloc_skb(PKT_BUF_SZ + sizeof(struct RxFD));

   memcpy(skb_put(skb, pkt_len), sp->rx_skbuff[entry]->tail, pkt_len);

Der Buffer ist zwar 1500 Byte + x groß, aber es wird nur pkt_len
vom Frame in diesen Buffer kopiert. Das heißt, es sollte keine
Möglichkeit für die höhere Schicht geben, die Paddingdaten zu
sehen.

Aber. :)

Natürlich können die Daten, die der letzte Router in die
Paddingfelder schreibt, Daten aus anderen Netzwerken enthalten.
Router empfängt langes Packet A, schreibt das in Sendebuffer.
Dann kommt kurzes Packet B in den Buffer, und ein Rest von Packet
A wird als Padding verwendet. Wie lang ist das Padding? 46 Byte
war Ethernet-Minimum-Framesize, ja? Wie groß ist z.B. das kleinste
korrekte TCP Packet? Ich glaub, IP braucht 20 Bytes, TCP nochmal
20. Also sieht man bis zu 6 Bytes des vorherigen Packetes. Stimmt
das so? Das ist sind dann wohl auch immer die restlichen der
ersten 6 Bytes, denke ich, da ja das Padding bis zu dem 46. Byte,
also dem 6. Nutzdatenbyte, verwendet wird. Wenn der Router
bißchen was tut, ist sehr wahrscheinlich, daß man zusätzlich auch
noch je 6 Byte aus verschiedenen Verbindungen sieht. Bleibt also
doch ein Leck: zwar sieht er nur den Müll des letzten Routers,
dieser Müll besteht aber u.U. aus den Daten des letzten
Paketes...

> Der Empfang von Müll ist also garantiert, 

So wie ich es sehe, wird das Padding nicht mitkopiert. Man sieht
also anderen Müll. 

IPSec müßte hier dennoch helfen: hier kommt nochmal ein Header
dazu, der deutlich länger als 6 Byte sein dürfte... So sieht man
dann doch nur wieder Header (ist immer noch unschön, aber IPSec
ESP verschlüsselt ja die eigentlichen [orginalen] Header).

Ich glaub, selbst FTP Passwörter bekommt man so wohl schlecht
raus: man erkennt an den 6 Byte ja nicht, was das für ein Dienst
war, und kann daher die 6 Byte nur schwer sinnvoll interpretieren
(so ohne Context). Bei UDP sieht das anders aus, hier ist ein
Header nur 8 Byte lang - bleiben 18 Byte sichtbar. Ergo würde der
Angreifer den Kram wohl mit UDP machen. Vielleicht klappt es
sogar noch besser, wenn man wirklich ein leeres IP frame
erzeugt, dann müßte man die vollen 26 Byte "ausnutzen" können,
oder? Natürlich sind dann die ersten 20 nur der letzte TCP
Header, doch nun kann man die 6 Bytes Nutzdaten gleich viel
besser interpretieren...

Da die Treiber hier auch den Kram alle selbst machen, dauert es
wohl ein Weilchen, bis die alle gefixt sind, was? Sind ja viele
Stellen...

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l