Security Vulnerability in inet_network() Library Routine May Allow Denial of Service (DoS) to Applications (see below for details)

1. Impact

An off-by-one buffer overflow in the inet_network() library function,
defined in the libsocket(3LIB), libresolv(3LIB), and the SunOS 4.x binary
compatibility libraries libc.so.1.9 and libc.so.2.9 in Solaris, may affect
applications which make use of this routine.  Depending on the
application, this may allow a local or remote unprivileged user to crash
the application using the inet_network() routine (which is a type of
Denial of Service).

This issue is also referenced in the following document:
    
CVE-2008-0122 at

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0122

2. Contributing Factors

This issue can occur in the following releases:

SPARC Platform

• Solaris 8 for libresolv(3LIB)without patch 109326-21

• Solaris 8 for libsocket(3LIB)without patch 111327-06

• Solaris 8 for SunOS 4.x Binary Compatibility libraries without patch 109152-03

• Solaris 9 for SunOS 4.x Binary Compatibility libraries without patch 112874-45

• Solaris 10 for SunOS 4.x Binary Compatibility libraries without patch 136892-01

• OpenSolaris based upon builds snv_01 through snv_87 (SunOS 4.x Binary Compatibility libraries only (6653976)) 
  

x86 Platform

• Solaris 8 for libresolv(3LIB) without patch 109327-21

• Solaris 8 for libsocket(3LIB) without patch 111328-05

Note 1: The inet_network() function in the libsocket(3LIB) and
        libresolv(3LIB) libraries isn't affected by this issue in Solaris
        9, 10 and OpenSolaris.


Note 2: The SunOS 4.x binary compatibility libraries allow existing SunOS
        4.x applications, including OpenWindows applications, to run on
        Solaris without modification or recompilation and only apply to 
        the SPARC architecture.  More details can be found in the "Binary
        Compatibility Guide" at http://docs.sun.com/.

Note 3: A partial test to check if an application links with a library such
        as libresolv(3LIB) is to use ldd(1):

        $ ldd /path/to/Application | grep libresolv
                libresolv.so.2 =>        /usr/lib/libresolv.so.2

        A comprehensive test to check if an application links with a
        library such as libresolv(3LIB) requires the use of pldd(1)
        against the running application since ldd(1) does not list any
        shared objects explicitly attached using dlopen(3C).  For example:

        $ pldd `pgrep Application` | grep libresolv
        /usr/lib/libresolv.so.2

3. Symptoms

If the described issue is exploited to cause a Denial of Service (DoS) to
an application which links to an affected library, the application will
exit and may generate an error message about a Segmentation Fault,
potentially writing a core(4) file. 

4. Workaround

There is no workaround for this issue. Please see the "Resolution" section
below.

5. Resolution

This issue is addressed in the following releases:

SPARC Platform

• Solaris 8 for libresolv(3LIB)with patch 109326-21 or later

• Solaris 8 for libsocket(3LIB)with patch 111327-06 or later

• Solaris 8 for SunOS 4.x Binary Compatibility libraries with patch 109152-03 or later

• Solaris 9 for SunOS 4.x Binary Compatibility libraries with patch 112874-45 or later

• Solaris 10 for SunOS 4.x Binary Compatibility libraries with patch 136892-01 or later

• OpenSolaris based upon builds snv_88 or later (SunOS 4.x Binary Compatibility libraries only (6653976))

• Solaris 8 for libresolv(3LIB) with patch 109327-21 or later

• Solaris 8 for libsocket(3LIB) with patch 111328-05 or later

http://sunsolve.sun.com/search/document.do?assetkey=1-61-213557-1

09-Jun-2008: Updated Contributing Factors and Resolution sections. Resolved.
10-Jun-2008: Additions to Contributing Factors and Resolution sections.

This solution has no attachment