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

[Jan-Benedict Glaw]

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

Bsp.: "grep dev_alloc_skb ..../linux/drivers/net/*.c"
3c515.c:                        skb = dev_alloc_skb(PKT_BUF_SZ);
3c527.c:                            && ((newskb=dev_alloc_skb(1532)) != NULL)) 
3c59x.c:                        skb = dev_alloc_skb(PKT_BUF_SZ);
3c59x.c:                        skb = dev_alloc_skb(PKT_BUF_SZ);
82596.c:                struct sk_buff *skb = dev_alloc_skb(PKT_BUF_SZ);
82596.c:                                newskb = dev_alloc_skb(PKT_BUF_SZ);
bmac.c:                 bp->rx_bufs[i] = skb = dev_alloc_skb(RX_BUFLEN+2);
eepro100.c:     skb = dev_alloc_skb(PKT_BUF_SZ + sizeof(struct RxFD));
...

Der Empfang von Müll ist also garantiert, und wenn nur routing
stattfindet, dann schafft man's sicher auch, den wieder
'rauszuschicken...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier Bürger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: nicht verfügbar
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20030110/15c9a0e6/attachment.sig>