Message-Id: <20070918222715.DBC3214A@lists.grok.org.uk>
Date: Tue, 18 Sep 2007 23:27:13 +0100 (BST)
From: noreply@...ecurity.com
To: full-disclosure@...ts.grok.org.uk
Subject: [MU-200709-02] Dibbler Remote Denial of Service
	Vulnerability

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dibbler Remote Denial of Service Vulnerability [MU-200709-02]
September 18, 2007

http://labs.musecurity.com/advisories.html

Affected Products/Versions:

Dibbler 0.6.0
http://klub.com.pl/dhcpv6/

Product Overview:

Dibbler is a portable DHCPv6 implementation.  DHCPv6 is the Dynamic
Host Configuration Protocol for IPv6, an application-layer protocol
used to dynamically assign IPv6 addresses to network components.

Vulnerability Details:

There are multiple vulnerabilities where a maliciously-crafted packet
can crash Dibbler.  These include packets with options with large
lengths (memory allocation failure via integer overflow), invalid
lengths (buffer overread), and malformed IA_NA options in a REBIND
message (null pointer dereference).

* Options with large lengths

Options with large lengths can cause integer overflows which
ultimately cause the server to fail to allocate memory and abort.  For
example, in the TSrvMsg constructor (SrvMessages/SrvMsg.cpp, line 94),
the message length is converted using ntohs() and stored in a short
(line 109).  The length is later passed to option constructors as an
int.  The length will be sign-extended and may be incorrectly used as
a negative signed integer or a large unsigned integer.  For example,
if the code is OPTION_CLIENTID and the length is -1, the server will
eventually attempt to allocate 4294967295 bytes to store the DUID
(Misc/DUID.cpp, line 26).  This allocation will usually fail and the
server will abort.

  Code snippet of SrvMessages/SrvMsg.cpp starting at line 106:
    while (pos<bufSize) {
        short code = ntohs( * ((short*) (buf+pos)));
        pos+=2;
        short length = ntohs(*((short*)(buf+pos)));
        pos+=2;
    ...
    case OPTION_CLIENTID:
        ptr = new TSrvOptClientIdentifier(buf+pos,length,this);

  Continuing in SrvOptions/SrvOptClientIdentifier.cpp, line 23:
    TSrvOptClientIdentifier::TSrvOptClientIdentifier(
        SmartPtr<TDUID> duid, TMsg* parent)
        : TOptDUID(OPTION_CLIENTID, duid, parent)

  Continuing in Options/OptDUID.cpp, line 61:
    TOptDUID::TOptDUID(int type, char* &buf, int &bufsize, TMsg* parent)
       :TOpt(type, parent)
    {
        this->DUID=new TDUID(buf,bufsize);

  Continuing in Misc/DUID.cpp, line 26:
    TDUID::TDUID(const char* DUID,int DUIDlen)
    {
        ...
        if ((DUID)&&(DUIDlen))
        {
            this->DUID=new char[DUIDlen];

There are similar vulnerabilities in other constructors (e.g.,
TClntMsg, TClntOptIAAddress, TClntOptIAPrefix, TOptVendorSpecInfo, and
TOptOptionRequest) and methods (e.g., TRelIfaceMgr::decodeRelayRepl,
TRelMsg::decodeOpts, TSrvIfaceMgr::decodeRelayForw).

* Invalid lengths

In many places, lengths are not validated against buffer sizes
resulting in potential buffer overreads.  For example, the TSrvMsg
constructor does not check the buffer size correctly before reading
the option code and option length (SrvMessages/SrvMsg.cpp, line 106 -
see code snippet above) and does not check the option length against
the buffer size before parsing the options.

* Malformed IA_NA options in a REBIND message

A REBIND with an invalid IA_NA can cause a null pointer dereference
due to a logic error.  In TSrvOptIA_NA::rebind()
(SrvOptions/SrvOptIA_NA.cpp, line 407), the TAddrIA (ptrIA) is
retrieved from the TAddrClient (ptrClient) and then the client
(ptrClient) is checked against NULL.  The TAddrIA (ptrIA) should be
checked against NULL.  It can be NULL and the pointer is later
dereferenced.  

  Code snippet starting at line 407:
    ptrIA = ptrClient->getIA(this->IAID);
    if (!ptrClient) {
        ...
        return;
    }
    ...
    ptrIA->setTimestamp();


Vendor Response / Solution:

Fixed in Dibbler 0.6.1
Available from http://klub.com.pl/dhcpv6/

History:
May 30, 2007       - First contact with vendor
May 31, 2007       - Vendor acknowledges vulnerability
July 5, 2007       - Vendor releases security fix
July 5, 2007       - Notify vendor of additional issues
July 6, 2007       - Vendor releases snapshot
July 11, 2007      - Notify vendor of additional issues
July 13, 2007      - Vendor releases snapshot
July 30, 2007      - Notify vendor of additional issues
August 26, 2007    - Vendor releases snapshot
August 26, 2007    - Vendor releases snapshot
September 11, 2007 - Vendor releases official fix
September 18, 2007 - Advisory released

Credit:

This vulnerability was discovered by the Mu Security research team.

http://labs.musecurity.com/pgpkey.txt

Mu Security offers a new class of security analysis system, delivering a
rigorous and streamlined methodology for verifying the robustness and security
readiness of any IP-based product or application. Founded by the pioneers of
intrusion detection and prevention technology, Mu Security is backed by
preeminent venture capital firms that include Accel Partners, Benchmark
Capital and DAG Ventures. The company is headquartered in Sunnyvale, CA. For
more information, visit the company's website at http://www.musecurity.com.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFG8ExC+aa9jJz2VeARApJYAJ0ZAdm8ILcHJGqCX1q8fFxRraCt5ACfZlUn
5dQKBnJtd6250am+2Tm3ElU=
=SU4M
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists