Random IRC quote :      <madalenasbuenas> ahora te tengo bajo el ojo nullsub

Apple’s Windows Bonjour Namespace Service Provider flaw

Buenas,

Apple publicó ayer una serie de boletines de seguridad para diversos apple.jpegproductos entre los cuales se encuentra un fallo que reporté hace unos meses en el servicio Bonjour, este servicio es usado en productos como por ejemplo iTunes, iPhoto, iChat, Adobe Creative Suite 3, Proteus, Adium, Fire, Pidgin, Skype, etc. La vulnerabilidad no es muy grave y únicamente afecta a plataformas Windows, aún así me parece un buen ejemplo para ilustrar vulnerabilidades que pueden afectar a productos de terceros y no precisamente porque hagan un «uso real» del componente vulnerable, como ahora veremos.

El servicio Bonjour, que por cierto es open source,  utiliza en su implementación windowsera lo que se llama un Namespace Service Provider, según la propia definición de Microsoft :

A namespace provider implements an interface mapping between the Winsock namespace SPI and the native programmatic interface of an existing name service such as DNS, X.500, or NetWare Directory Services (NDS).


Básicamente un NSP se implementa en forma de una librería que será a su vez cargada por Winsock en cada uno de los procesos que hagan uso de este último, de esta manera se establece esta interfaz dinámicamente.

Personalmente no me gusta mucho la arquitectura de Winsock, y la experiencia me ha dicho que la mayor parte de los LSPs y NSPs con los que he tenido el gusto o la desgracia de toparme, me han dado algún tipo de problema. Se trata de componentes que deben ser bastante robustos, porque actuan de una manera intrusiva a nivel de los procesos en los que se cargan, todavía recuerdo (con rabia) las vueltas que di en una ocasión mientras estaba programando un exploit remoto, que finalmente resultó no estar funcionando por culpa del LSP de determinado Antivirus, que por supuesto estaba metiendo la pata hasta el fondo, aunque bien visto y sin saberlo estaba actuando de IDS, pero no sólo para mi exploit 🙂

Como diría Marcial, enresumiendo!, cuidadín con los LSPs y NSPs que si metes la gamba la estas metiendo en todos los procesos donde se cargue tu interfaz.

Vamos a ver en este caso, donde metió la gamba Apple :

NSPLookupServiceBegin en mdnsNSP.c

DEBUG_LOCAL int WSPAPI
    NSPLookupServiceBegin(
        LPGUID                    inProviderID,
        LPWSAQUERYSETW            inQuerySet,
        LPWSASERVICECLASSINFOW    inServiceClassInfo,
        DWORD                    inFlags,
        LPHANDLE                outLookup )
{

    …

        n = WideCharToMultiByte( CP_UTF8, 0, name, -1, translated, sizeof( translated ), NULL, NULL );
        require_action( n > 0, exit, err = WSASERVICE_NOT_FOUND );

        replyDomain = translated;

        while ( *replyDomain ) // <- DoS!!, accessing invalid memory address …
        {
            label[labels++]    = replyDomain;
            /* GetNextLabel() could return a NULL pointer as you can see below */
            replyDomain        = GetNextLabel(replyDomain, text);
        }
  …
}

GetNextLabel en mdnsNSP.c

GetNextLabel(const char *cstr, char label[64])
{
    char *ptr = label;
    while (*cstr &amp;&amp; *cstr != ‘.’)
        {
        char c = *cstr++;
        if (c == \\)
            {
            c = *cstr++;
            if (isdigit(cstr[-1]) &amp;&amp; isdigit(cstr[0]) &amp;&amp; isdigit(cstr[1]))
                {
                int v0 = cstr[-1]‘0’;
                int v1 = cstr[ 0]‘0’;
                int v2 = cstr[ 1]‘0’;
                int val = v0 * 100 + v1 * 10 + v2;
                if (val <= 255) { c = (char)val; cstr += 2; }
                }
            }
        *ptr++ = c;
        /* returning a null pointer if the label is greater than 64 bytes! */
        if (ptr >= label+64) return(NULL);
        }
    if (*cstr) cstr++;
    *ptr++ = 0;
    return(cstr);
}

La función NSPLookUpServiceBegin será llamada en el contexto de cualquier proceso que intente realizar una resolución de nombre, si uno de los campos del dominio es mayor de 64 bytes se producirá un acceso invalido a memoria con lo cual básicamente podemos provocar una denegación de servicio (incluso de manera remota) en cualquier proceso al que podamos forzar a realizar una petición de este tipo ( pej DNS ) que controlemos. Este caso es relativamente común, ya que muchos protocolos de red suelen transportar este tipo de datos, de manera que posteriormente se realizan estas resoluciones.

De cualquier manera y como comentábamos al principio, el servicio Bonjour, no creo que sea un componente que se encuentre con frecuencia en servidores, con lo cual este fallo de seguridad tiene una importancia baja, aunque ha venido bien para explicar este tipo de fallos 🙂 .

Bueno, para terminar y como está tan de moda, os dejo el exploit que hará cascar vuestro Google Chrome o Firefox si tenéis este servicio instalado ( lo tendréis si usáis iTunes y no habéis actualizado todavía )

Un saludo y hasta la próxima 🙂

4 Comentarios para “Apple’s Windows Bonjour Namespace Service Provider flaw”

  1. Comment por infi | 09/10/08 at 9:43 am

    Interesante lectura 🙂

  2. Comment por Ruben | 09/10/08 at 11:05 am

    Eres un criminal.

  3. Comment por LordHASH | 09/10/08 at 11:44 am

    espero que ruben sea amigo tuyo…

  4. Comment por elpescailla | 09/11/08 at 6:49 pm

    el mario este no tiene amigos.. no ves q anda por ahi estropeando el software de los demas, pues claro nadie quiere ser su amigo

    por lo demas, un bug muy guapo y un articulo la mar de interesante 😉 y lo que dices lsps y nsps totalmente deacuerdo..y aun mas cuidado deberian tener programando filtros de sistema de archivos, de ndis, y los famosos hooks q andan metiendo ahora para la heuristica de los antivirus… pero claro, en vez de hacer una seccion de calidad en condiciones, regalan nintendos ds, y asi esta el patio

Se han cerrado los comentarios