[NEWS] Vulnerabilities in Multiple RADIUS Clients and Servers

From: support@securiteam.com
Date: 03/11/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Mon, 11 Mar 2002 11:31:16 +0100 (CET)

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

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Vulnerabilities in Multiple RADIUS Clients and Servers
------------------------------------------------------------------------

SUMMARY

Remote Authentication Dial-In User Service (RADIUS) is widely used by
multiple ISP for authentication of users and accounting. RADIUS server
usually performs authentication and accounting on requests from RADIUS
client (also known as Network Access Server - NAS). Almost any modern
hardware or software access server can act as RADIUS client. During
internal audit of <http://www.freeradius.org> FreeRADIUS project before
the 0.4 release a few bugs were fixed in code inherited from older RADIUS
implementations. Since almost any current implementation of RADIUS servers
and multiple RADIUS clients has code derived from Merit, Ascend or
Livingston these bugs may still present in different software. Both RADIUS
servers and clients (access servers) are vulnerable.

DETAILS

Affected software:
Cistron versions prior to 1.6.4 (1)(2) (including)
Cistron version 1.6.5 (2)
XtRadius versions prior to 1.1-pre1 (1)(2) (including)
FreeRADIUS versions prior to 0.3 (1)(2) (including)
ICRadius versions prior to 0.18.1 (1)(2) (including)
YARD Radius versions prior to 1.0.19 (1)(2**) (including)
Lucent/Livingston RADIUS versions prior to 2.1 (1)(2?) (including)
Ascend RADIUS versions prior to 1.16 (1) (including)
Merit RADIUS versions prior to 3.6B2 (1*) (including)
GNU Radius versions prior to 0.95 (1) (including)
radiusclient versions prior to 0.3.1 (1) (including)

Not affected:
FreeRADIUS 0.4
Microsoft IAS (according to vendor)
All CISCO products (according to vendor)
WindNet RADIUS 1.1 (according to vendor)

(1) Multiple implementations of the RADIUS protocol contain a Digest
Calculation buffer overflow
To validate few types of RADIUS packets RADIUS calculates packet digest.
Digest calculated as MD5 hash from packet concatenated with message
authenticator and shared secret. The problem is that during concatenation
multiple RADIUS implementations fail to check target buffer has enough
space. It makes it possible to overflow buffer with shared secret data.
This bug presents in all RADIUS implementations derived from Merit/Ascend.

RADIUS client is vulnerable during parsing of Server reply. Server is
vulnerable during parsing of accounting packets and during packet
proxying. In most cases it will cause DoS against RADIUS server. In few
cases under very rare conditions discussed later it may result code
execution.

Function, where overflow occurs may have different names:

      response_match(): Merit
      calc_digest()/calc_acctdigest(): Livingston, Cistron and derived
      rc_check_reply(): radclient
      rad_proxy()/calc_acctreq()/build_packet(): yardradius

Vulnerable piece of code looks like:
      memcpy(buffer+len, secret, secretlen);

(2) Multiple implementations of the RADIUS protocol do not adequately
validate the Vendor-Specific attribute Vendor-Length
Vendor-Specific attribute is a subset of sub-attributes. Each
sub-attribute usually has 2 bytes header (first byte is Vendor-Type and
second byte is Vendor-Length), except US Robotics attributes where header
is 4 bytes. Vendor-Length should be greater or equal to header length.

The problem is that multiple RADIUS implementations fail to check
Vendor-Length than calculating amount of data inside Vendor-Specific
sub-attribute. If Vendor-Length is 0 data size will be calculated as
negative number.

Later memcpy is called with this number to copy data. In most systems
result of this attack will be DoS against RADIUS (if memcpy()
implementation is not completely flawed).

In most RADIUS servers vulnerable function is rad_recv() or radrecv().

Vulnerable piece of code looks like
     {
        ptr += 4;
        vendorlen = attrlen - 4;
        attribute = *ptr++ | (vendorcode << 16);
        attrlen = *ptr++;
        attrlen -= 2;
        length -= 6;
     }

Some implementation has the same bug in processing of USR-specific
attributes (and other non-standard Vendor-Specific attributes).

This bug can be exploited with any type of RADIUS packet.
 
Exploitation:
To exploit these vulnerabilities against RADIUS server an attacker must
first be able to send RADIUS packets from IP of registered NAS. Since
RADIUS uses UDP as transport layer it's easy to spoof NAS' IP address.
Since both bugs occurs before packet is validated no knowledge of shared
secret required.

To exploit this vulnerability against RADIUS client (NAS) the attacker
should be able to first guess client's UDP port. In many cases this port
is predictable.

Attached test_radius tool may help you to reproduce situation (it doesn't
spoof IP, so then testing against RADIUS server IP of the host you running
this tool should be registered as valid NAS). test_radius may also be
obtained from: <http://www.security.nnov.ru/files/test_radius.c>
http://www.security.nnov.ru/files/test_radius.c

For (1) buffer overflowed by shared secret which (in general case) is not
known to attacker. Attacker is not able to control this data, but he is
able to control length of the data. It makes it possible to make 1-byte or
2-bytes buffer overflow. In this case if last symbol(s) of shared secret
is in appropriate range it may be possible to use this overflow for code
execution in few implementations. Sometimes it looks possible to exploit
it blindly, for example this is definition of buffer in one of RADIUS
implementations:

            static int i_recv_buffer[RAD_BUFFER_SIZE];
            static u_char *recv_buffer = (u_char *)i_recv_buffer;

Receiving function works with recv_buffer. Theoretically it's possible to
write to any memory location in 3 steps:
1. We do 1-byte overflow to change last byte of recv_buffer to point to
middle of i_recv_buffer (it will happen only if last byte of shared secret
is higher then lowest byte of i_recv_buffer address).
2. Now we can overwrite recv_buffer with data controlled by us with second
packet.
3. Now data of the third packet will be written to location we choose.

Of course exploitation is only possible if all 3 packets are handled in
the same thread. To reproduce this problem you may use something like

    test_radius RADIUS_SERVER 1 100 MAX_PACKET_SIZE 10 1646 4

Where RADIUS_SERVER is ip of your RADIUS host MAX_PACKET is compiled
maximum packet size, you can try different:
1024, 2048, 4096, 8192, etc
(This command will send radius accounting packet of MAX_PACKET_SIZE)

(2) Can be tested with
  test_radius RADIUS_SERVER 11 20 311 0
(malformed Microsoft MS-CHAP-Challenge packet)

Or
  test_radius RADIUS_SERVER 1 100 9 0
(malformed CISCO Cisco-AVPair packet)
 
test_radius may also be used as a stress-testing tool against memory
exhaustion problem described in
<http://www.securiteam.com/exploits/6K00J2035U.html>
http://www.securiteam.com/exploits/6K00J2035U.html.

  test_radius RADIUS_SERVER 1 2 MAX_PACKET_SIZE 100000

ADDITIONAL INFORMATION

References:
 <http://www.security.nnov.ru/files/test_radius.c>
http://www.security.nnov.ru/files/test_radius.c

The information has been provided by <mailto:3APA3A@SECURITY.NNOV.RU>
3APA3A.

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

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.

Relevant Pages
Loading