> MCI Telecommunications
> internetMCI Security Group
>Report Title: iMCI MIIGS Security Alert
>Report Name: Remote Vulnerability in RADIUS
>Report Number: iMCISE:IMCISNI:121797:01:P1R1
>Report Date: 12/17/97
>Report Format: Formal
>Report Classification: MCI Informational
>Report Reference: http://www.security.mci.net
>Report Distribution: iMCI Security,
> MCI Internal Internet Gateway Security (MIIGS),
> MCI Emergency Alert LiSt (MEALS)
> (names on file)
> ###### ## ## ######
> ## ### ## ##
> ###### ## # ## ##
> ## ## ### ##
> ###### . ## ## . ######.
> Secure Networks Inc.
> Security Advisory
> 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 <firstname.lastname@example.org>. 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. <email@example.com>
> Secure Networks <firstname.lastname@example.org>
>-----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
> email@example.com with the line "subscribe sni-advisories"
>Dale Drew MCI Telecommunications
>Sr. Manager internetMCI Security
>Voice: 703/715-7058 Internet: firstname.lastname@example.org
>Fax: 703/715-7066 MCIMAIL: Dale_Drew/644-3335
Kevin Brown Networking Engineer
Huber & Associates <email@example.com>
IBM Business Partner http://www.primelink.com/haa/haahome.htm
Phone: 573-634-5000 ext 114
IBM, Cisco & Ascend Routers, Switches, HUBs, and related hardware.
Windows 95/NT, AIX, BSDI, FreeBSD, OS/400.
RS6000, AS/400 and basic PC troubleshooting.
Pursuate to US Code, Title 47, Chapter 5, Subchapter II, Sec. 227,
any and all nonsolicited commercial E-mail sent to this address is
subject to a download and archival fee in the amount of $500 US.
Emailing denotes acceptance of these terms.