Overflow in Livingston RADIUS 1.16 and derived code
|Description:||There is a buffer overflow in the handling of buffers related to inverse IP lookup in RADIUS 1.16 and derived code (including Ascend RADIUS)|
|Author:||"Secure Networks Inc." <sni@SECURENETWORKS.COM>|
|Compromise:|| root (remote)|
|Vulnerable Systems:||Those running RADIUS server software derived from Livingston RADIUS 1.x |
|Date:||17 December 1997 |
Date: Wed, 17 Dec 1997 11:37:46 -0700
From: "Secure Networks Inc." <sni@SECURENETWORKS.COM>
Subject: SNI-22: RADIUS Advisory
-----BEGIN PGP SIGNED MESSAGE-----
###### ## ## ######
## ### ## ##
###### ## # ## ##
## ## ### ##
###### . ## ## . ######.
Secure Networks Inc.
December 17, 1997
Remote Vulnerability in RADIUS Servers Derived from Livingston 1.16.
This advisory details vulnerabilities in RADIUS server software derived
from Livingston RADIUS 1.x allow remote attacks to gain extended access
to the authentication server. In many installations of RADIUS,
exploitation of this vulnerability will allow an intruder to remotely
obtain superuser access to the machine running the RADIUS server. In
all cases, the extended access gained allows an attacker to subvert
This vulnerability was discovered in Livingston RADIUS 1.16, a popular
publically-available RADIUS server implementation. Another popular
RADIUS implementation is provided by Ascend Communications; Ascend
RADIUS, based on the Livingston 1.16 implementation, is very similar
to the Livingston code and shares the same bugs.
Merit RADIUS was not determined to be vulnerable to the specific problem
outlined in detail in this document. However, Merit RADIUS has not
been audited and Secure Networks Inc. makes no assertions as to it's
An exploitable stack overrun is present in the RADIUS accounting code in
Livingston RADIUS 1.16. The problem occurs as a result of inverse
resolution of IP addresses to hostnames; the accounting routine
rad_accounting() copies the resolved hostname to a buffer on it's stack,
without checking the length of the hostname first.
As a result of this bug, an attacker that controls the DNS server for any
IP address can configure the records for that address to resolve to a
name too large for the RADIUS server's buffer; the characters in the
hostname, which overwrites the server's stack, can contain machine
code that the server will be forced to execute.
It is important to note that the RADIUS server request authentication
(which, in some cases, involves packet signatures with keyed MD5 hashes)
does not prevent this attack. The source IP address on RADIUS accounting
requests is not checked by the server code before the error occurs.
It is also important to note that this is not the only point in the RADIUS
code where hostname resolution can be exploited to subvert the server;
unchecked string copies are common throughout the RADIUS code. Livingston
has integrated a series of patches (written by SNI) to address this
problem. See the 'Fix Resolution' section.
All RADIUS servers based off of Livingston's 1.16 RADIUS server.
Livingston RADIUS servers 2.0, 2.0.1 are not vulnerable.
As mentioned earlier, Livinsgston's RADIUS 2.0, 2.0.1 are not vulnerable
to this problem. Any Livingston customer may upgrade to 2.0.1 at:
RADIUS 1.16.1 with SNI patches is also available at:
Ascend could not be contacted for an approved fix. As the source
code for Ascend RADIUS is freely available, an attempt has been made
to correct all obvious stack overruns in the code; Ascend has in no
way examined or approved these fixes.
You may obtain this patchfile at:
As this advisory involves a general problem with the RADIUS source code,
we advise organizations running RADIUS servers to contact their vendor to
confirm the vulnerability status of their RADIUS server.
Secure Networks, Inc. would like to thank Brian Mitchell for his
original notification to the security community regarding problems in
the Livingston RADIUS code. SNI would also like to thank Carl Rigney
of Livingston for his attention to this matter.
For more information regarding this advisory, contact Secure Networks
Inc. as <email@example.com>. A PGP public key is provided below if
privacy is required.
Type Bits/KeyID Date User ID
pub 1024/9E55000D 1997/01/13 Secure Networks Inc. <firstname.lastname@example.org>
Secure Networks <email@example.com>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
- -----END PGP PUBLIC KEY BLOCK-----
The contents of this advisory are Copyright (C) 1997 Secure Networks Inc,
and may be distributed freely provided that no fee is charged for
distribution, and that proper credit is given.
You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers
and advisories at ftp://ftp.secnet.com/advisories
You can browse our web site at http://www.secnet.com
You can subscribe to our security advisory mailing list by sending mail to
firstname.lastname@example.org with the line "subscribe sni-advisories"
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
The master index of all exploits is available
here (Very large file)
Or you can pick your favorite operating system:
This page is part of Fyodor's exploit
For a free program to automate scanning your network for vulnerable
hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resources: