[LSD] IRIX nsd remote buffer overflow vulnerability

From: Last Stage of Delirium (contact@lsd-pl.net)
Date: Wed Jul 30 2003 - 00:11:46 PDT

  • Next message: sloppy seconds: "RE: RPC DCOM still vulnerable even after applying patches"

    Hello,
    
    We have discovered a serious security vulnerability in the IRIX nsd service,
    which when properly exploited can result in an unauthorized remote root access
    to the vulnerable system. SGI was informed about this issue and assigned this
    bug number CVE CAN-2003-0575 (ftp://patches.sgi.com/support/free/security/advisories/20030704-01-P).
    
    The /usr/etc/nsd program is installed and started by default on all versions of
    SGI's IRIX operating system beginnig from version 6.5.0 (from 6.5.x the nsd
    service is listening only on localhost interface). It is responsible for
    providing consistent namespace and cache mechanisms for different name services
    (i.e. DNS, NIS, local configurations). It uses NFS based, virtual file system
    (in memory file system) for the purpose of storing different information data
    files. In IRIX operating system, all functions operating on namespaces make use
    of the functionality provided by the nsd service. This specifically refers to
    functions like getpwnam() and gethostbyname().
    
    This is also the primary reason why this service cannot be easily turned off, as
    this would influence the opeariting of the IRIX name services and the whole
    system as well.
    
    DESCRIPTION OF THE VULNERABILITY
    
    In order to allow user applications to communicate with the nsd services, it
    implements the NFS protocol. This interface is accessible through a dynamically
    assigned (at the system startup) UDP port (usually 1024 and above). The
    vulnerability that we have found is in the function implementing the RPC
    AUTH_UNIX method. It belongs to the so called class of "heap buffer overflow"
    errors.
    
    The vulnerability can be triggered by sending specially crafted RPC AUTH_UNIX
    udp packet to the nsd service. Upon reception of such a packet, nsd invokes
    the nfs_dispatch() function for handling the NFS protocol requests. From within
    the latter function, a call to nsd_cred_new() one is done. The nsd_cred_new()
    function allocates heap memory to store the received authorisation data.
    
    Next, just after returning from the nsd_cred_new() function, a copy loop is
    executed. This loop simply copies elements of c_gid table (containing the list
    of group identifiers to which the user belongs) to the proper offset of the
    nsd_cred structure previously allocated by the nsd_cred_new() function. Both,
    the loop counter (c_gids), as well as the copied data are taken directly from
    the body of the received packet. In a result, the user can fully control the
    length of copied data. Particularily, he can arrange it in such a way, so that
    a buffer overflow condition will be triggered in a result of which some control
    data from (and after) the nsd_cred structure will be overwritten.
    
    Below you can see a detailed trace log from our bptrace tool, which clearly
    illustratates the nsd execution path that leads to the overflow condition.
    
    breakpoint trace [version 1.4]
    copyright by LAST STAGE OF DELIRIUM 1998 Poland
        found 168 symbols
        168 breakpoints enabled, 0 disabled, 0 aliases
    ==> attaching process 2901956 (/usr/etc/nsd)
    [2901956] 0x1000521c    1  nsd_callback_get()
    [2901956] 0x1001535c    1  nsd_logprintf()
    [2901956] 0x10015624    1  nsd_calloc()
    [2901956] 0x0fa35e5c    1  calloc(1,40)
    [2901956] 0x0fa34bc4    1  malloc(40)
    [2901956] 0x0fa37838    1  memset(0x1002a168,0,40)
    [2901956] 0x0fa494cc    1  tsix_recvfrom_mac()
    
    -------------------------------------------------------------------------------
    [2901956] 0x10005254    1  nsd_cred_new() Allocating new nsd_cred
    [2901956] 0x10015624    2  nsd_calloc()   strucuture
    -------------------------------------------------------------------------------
                               There is a described above loop
    -------------------------------------------------------------------------------
    [2901956] 0x10010c4c    1  nfs2_dispatch()
    [2901956] 0x1001535c    2  nsd_logprintf()
    [2901956] 0x0fa49734    1  tsix_sendto_mac()
    [2901956] 0x0fa5eadc    1  sendto(5,
                             00 00 00 00 00 00 00 01 00 00 00 00 00  .............
                             00 00 00 00 00 00 00 00 00 00 00 00 00  .............
                             00 00                                   ..
                             ,28,0,)
    [2901956] 0x100053ac    1  nsd_cred_clear()
    [2901956] 0x0fa35c6c    1  free(0x10037b90)
    [2901956] 0x0fa35c6c    2  free(0x1002a168)
    [2901956] 0x100142b4    1  nsd_timeout_set()
    [2901956] 0x0fa57fd8    1  gettimeofday()
    [2901956] 0x0fa5e73c    1  select()
    [2901956] 0x1000521c    2  nsd_callback_get()
    [2901956] 0x1001535c    3  nsd_logprintf()
    [2901956] 0x10015624    3  nsd_calloc()
    [2901956] 0x56] 0x0fa5eadc    2  sendto(5,
                             00 00 00 00 00 00 00 01 00 00 00 00 00  .............
                             00 00 00 00 00 00 00 00 00 00 00 00 00  .............
                             00 00                                   ..
                             ,28,0,)
    -------------------------------------------------------------------------------
    [2901956] 0x100053ac    2  nsd_cred_clear() Freeing nsd_cred and asmcode
                                                execution
    -------------------------------------------------------------------------------
    ==> process 2901956 forking to 2901957
    ==> attaching process 2901957 (/usr/etc/nsd)
    ==> process 2901957 executing /bin/sh
        found 32 symbols
        32 breakpoints enabled, 0 disabled, 0 aliases
    
    
    -------------------------------------------------------------------------------
    
    We have verified that this vulnerability is exploitable and we have written a
    fully operational proof of concept code. It will be available for download from
    our webpage in the future.
    
    With best regards,
    Members of
    The Last Stage of Delirium
    Research Group
    http://lsd-pl.net
    



    This archive was generated by hypermail 2b30 : Wed Jul 30 2003 - 11:25:15 PDT