[LACNIC/Seguridad] Análisis de seguridad del protocolo IP

Jorge M. Niedbalski R. niedbalski en ip6nw.com
Jue Ago 21 15:24:59 BRT 2008


2008/8/21 Fernando Gont <fernando en gont.com.ar>

>  Hola, Jorge,
>
>
> Concuerdo con Roque, lo propuesto en la seccion 3.1 solo es valido para 2
> de los ethertypes  0x0800 (IPv4) e 0x86DD (IPv6).
>
> En el caso de otros ethertypes como 802.3, SPRITE, X.25  Segun el documento
> ¿ se deberia descartar el paquete , aun cuando se esta encapsulando
> adecuadamente sobre otro tipo de link layer ?
>
>
> mmmm.... no entiendo.
>
> El planteo es el siguiente:
> Si un frame ethernet llega a un host, y su payload se le pasa al modulo de
> IPv4, es porque el Ehertype del paquete Ethernet era 0x0800.
> Este valor de  Ethertype indica que el payload del paquete Ethernet
> contiene un paquete IP.
>
> Si el Ethertype es 0x0800, pero lo que se encapsula es en realidad un
> paquete IPv6, esto es una error, ya que en tal caso el Ethertype deberia
> haber sido 0X86DD, y *no* 0x0800.
>
> Del mismo modo, si un modulo IPv6 llegara a "procesar" un paquete IPv4 que
> llego en un frame Ethernet, es porque el Ethertype fue 0x86DD, en vez de
> 0x0800, que es el que verdaderamente correspondia. Por tal motivo, esta es
> una condicion de error.
>
> Se entiende el argumento?
>
> Saludos cordiales, y gracias por el feedback!
>
> --
> Fernando Gont
> e-mail: fernando en gont.com.ar || fgont en acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>
>
Hola Fernando,

Respondiendome a mi mismo y aclarando mi apreciacion,

Supongamos el caso comun de un frame ethernet obviando algunos detalles , el
flujo seria (solo consideraremos el procesamiento de entrada del frame) :

rutina ether_input()
    se valida    ETHER_HDR_LEN
    se valida    M_PKTHDR

Luego se extrae de la cabecera el ether_type

etype = ntohs(eh->ether_type);

Luego se setean algunos bits flags en caso de ser multicast,etc

Al finalizar la rutina se llama a  ether_demux() quien setea el isr con los
NETISR apropiados para dicha mbuff.

case ETHERTYPE_IP    isr = NETISR_IP
case ETHERTYPE_ARP    isr = NETISR_ARP
case ETHERTYPE_IPX      isr = NETISR_IPX
case ETHERTYPE_IPV6    isr = NETISR_IPV6
case ETHERTYPE_ATALK    isr = NETISR_ATALK1


Luego con el ISR seteado se despacha al network interruption software
routine netisr_dispatch(isr, mbuff) , que distingue 2 casos, cuando es un
NETISR_MPSAFE (casos como ipsec) se setea directamente
la funcion handler apropiada segun el isr , en caso contrario se envia al
schednetisr(num).

Para los casos de NETISR_IP y NETISR_IPV6 previamente se registran las
rutinas de manejo de entrada.

netisr_register(NETISR_IP, ip_input, &ipintrq, NETISR_MPSAFE);
netisr_register(NETISR_IPV6, ip6_input, &ip6intrq, 0);

En ambos casos la comprobacion es simple tanto en la rutina ip_input como
ip6_input :

if (ip->ip_v != IPVERSION) {
                ipstat.ips_badvers++;
                goto bad;
}


Lo mismo ocurre para el caso de una if_ppp , en tal caso

 switch (proto) {
#ifdef INET
    case PPP_IP:
        /*
         * IP packet - take off the ppp header and pass it up to IP.
         */
        if ((ifp->if_flags & IFF_UP) == 0
            || sc->sc_npmode[NP_IP] != NPMODE_PASS) {
            /* interface is down - drop the packet. */
            m_freem(m);
            return;
        }
        m->m_pkthdr.len -= PPP_HDRLEN;
        m->m_data += PPP_HDRLEN;
        m->m_len -= PPP_HDRLEN;
        if ((m = ip_fastforward(m)) == NULL)
            return;
        isr = NETISR_IP;
        break;

Es decir que la rutina de interrupcion seguira siendo la registrada para
NETISR_IP

En definitiva centrandonos en el caso ethernet , considerando un ethertype
0x0800 esta es manejada por la rutina registrada para NETISR_IP (en stack
4.4BSD es ip_input) valida que el campo ip_v sea correcto, por lo tanto, esa
comprobacion extra no es necesaria.


-- 
Jorge Niedbalski R.
-----------------------------------------
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20080821/1d4be728/attachment.html>


Más información sobre la lista de distribución Seguridad