[ Home | Liste | F.A.Q. | Risorse | Cerca... ]


[ Data: precedente | successivo | indice ] [ Argomento: precedente | successivo | indice ]


Archivio: openbsd@sikurezza.org
Soggetto: La lunga notte degli ICMP
Mittente: Giacomo Cariello
Data: 20 Jan 2002 19:55:48 -0000
Di recente mi e' capitata una cosa strana. Il provider che ha in housing 
glock.bug.it Ŕ diventato Autonomous System e ha momentaneamente acquisito 
un secondo uplink, che viene gestito da un router, che per motivi di 
organizzazione temporanea, e' stato messo nella stessa LAN di glock.bug.it. 
Il default gateway di glock.bug.it, che impara il routing dinamicamente via 
BGP, quando riceve dei pacchetti dalla LAN, che sarebbero da destinare al 
secondo uplink, manda degli icmp redirect all'host sorgente, informandolo 
della necessitÓ di tale modifica di routing.
Ma qui accade qualcosa di strano...il box OpenBSD impara automaticamente le 
nuove routes!! Gira e rigira, scopro che OpenBSD, a differenza di Linux, 
non ha alcuna sysctl fino alla 3.0-stable per bloccare l'acquisizione di 
routes via icmp redirect.
Il che equivale a dire che chiunque abbia un host in grado di intercettare 
pacchetti da un box OpenBSD che si trovi nella sua stessa LAN (la maggior 
parte dei routers oggi bloccano gli icmp redirects di default, ie: Cisco) 
pu˛ riempirgli la routing table (70.000 entries circa con il kernel 
GENERIC) e fare tante altre cosine da bambini cattivi (immaginate un po' 
voi, potendo ritoccare qua e la' :-).
Informo alcune persone del development group del kernel e dopo un'attenta 
analisi, mando un sendbug. La pezza non tarda ad arrivare da Eric Jackson. 
OpenBSD-current ha 2 nuove sysctl.

Ma qui scatta il bello:

1- Non viene rilasciata alcuna patch o nota informativa da parte del team 
di OpenBSD su questa vulnerabilitÓ. Il 99.9% degli host OpenBSD sono ancora 
vulnerabili.
2- L'icmp in questione, come molti altri icmp, se riguarda un pacchetto 
marcato da uno state (vedi stateful filtering) nel pf, viene 
automaticamente passato, anche se ci sono istruzioni che ne prevederebbero 
il blocco (questo non ha a che vedere con la sysctl).
3- La sysctl che effettivamente, se settata a 0 impedisce il successivo 
parsing del pacchetto icmp redirect, Ŕ di default a 1. E' chiaro che non 
avendo inserito nell'apposito man afterboot(8) o nella FAQ di controllare 
attentamente questa impostazione, dal punto di vista della security, Ŕ come 
se non esistesse, in barba al "secure-by-default".
4- Nel reply al mio sendbug, Eric Jackson dice che questo problema affligge 
comunque solo gli end-hosts e non i gateway, ma il mio box e' settato con 
ipforwarding attivo eppure ne e' afflitto.

Molti Linux hanno il settaggio relativo su 1 (es. Linux Debian).
FreeBSD, pur lasciando il settaggio a 0, descrive questa configurazione 
nell'rc.conf a partire dalla release 3.4:

"Support has been added for blocking incoming ICMP redirects, outgoing RST 
frames and incoming SYN|FIN frames in order to lessen or nullify the impact 
of certain kinds of DoS attacks."

icmp_drop_redirect
                    (bool) Set to NO by default.  Setting to YES will cause the
                    kernel to ignore ICMP REDIRECT packets.

icmp_log_redirect
                    (bool) Set to NO by default.  Setting to YES will cause the
                    kernel to log ICMP REDIRECT packets.  Note that the log
                    messages are not rate-limited, so this option should only
                    be used for troubleshooting your own network.

NetBSD si comporta come OpenBSD.

Ho inviato una mail di richiesta spiegazioni ad Eric Jackson, senza 
risposta. Ho chiesto spiegazioni su #openbsd / EFNet, e ho trovato pareri 
favorevoli e contrari al cambio di default da 1 a 0.
Nella fattispecie, questa sera ho incontrato Eric Jackson su #openbsd / 
EFNet e mi ha fatto capire che non Ŕ intenzionato a cambiare default perchŔ 
ne risulterebbe una violazione dell'RFC.

La mia opinione e' che un OS che si propone come "secure-by-default", di 
default non dovrebbe applicare i protocolli ove non sono strettamente 
necessari al funzionamento comune del networking, ove questi si rivelano 
fallaci in modo cosi evidente. Cosa ne pensate?
In altre occasioni (vedi ftpd), OpenBSD si discosta dallo standard e lascia 
lo standard come opzione, quindi non vedo la differenza con questa situazione.

In secondo luogo la mancanza di informazione e di supporto delle vecchie 
release non dimostra assolutamente la "pro-active security" menzionata nel 
manifesto di OpenBSD.


un po' deluso,

Giacomo Cariello, jwk@bug.it
KeyID: 3072/1024/0x409C9044
Fingerprint: 7984 10FD 0460 4202 BF90 3881 CDE4 D78E 409C 9044

"Put that mic in my hand and let me kick out the jams!" - MC5


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List




[ Home | Liste | F.A.Q. | Risorse | Cerca... ]

www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005