Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

GNU Radius Format String Vulnerability
I. BACKGROUND
 GNU Radius is a centralized user authentication and accounting system. It
supports back-end SQL databases for accounting. More information can be found
at http://www.gnu.org/software/radius/ 
II. DESCRIPTION
 Remote exploitation of a format string vulnerability in GNU Radius could allow
an attacker to execute code in the context of the running daemon. 
 The vulnerability specifically exists within the SQL accounting code. A format
string is built using user supplied data and then unsafely passed to the
variable argument function 'sqllog'. 
III. ANALYSIS
 Successful exploitation allows unauthenticated remote attackers to execute
arbitrary code in the context of the running radius daemon (radiusd). Typically
the radius daemon will run as root. 
 Exploitation requires that radiusd be compiled with an SQL back-end and SQL
accounting be turned on. These options are both turned on by default for
FreeBSD and Gentoo Linux. 
IV. DETECTION
 iDefense has confirmed that this vulnerability is present in version 1.3 and
1.2 of GNU Radius. It is likely that all prior versions are vulnerable. 
V. WORKAROUND
 iDefense confirms that using one of the other supported accounting methods
will mitigate exploitation of this vulnerability while still allowing
accounting to take place. 
VI. VENDOR RESPONSE
 The GNU Radius team included a fix for this vulnerability in version 1.4. 
VII. CVE INFORMATION
 The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2006-4181 to this issue. This is a candidate for inclusion in the CVE list
(http://cve.mitre.org), which standardizes names for security problems. 
VIII. DISCLOSURE TIMELINE
 08/16/2006 Initial vendor notification
 09/08/2006 Initial vendor response
 11/06/2006 Second vendor notification
 11/26/2006 Coordinated public disclosure

IX. CREDIT
 The discoverer of this vulnerability wishes to remain anonymous. 
Get paid for vulnerability research
http://labs.idefense.com/methodology/vulnerability/vcp.php
Free tools, research and upcoming events
http://labs.idefense.com/
X. LEGAL NOTICES
 Copyright 

GNU Radius Format String Vulnerability
I. BACKGROUND
 GNU Radius is a centralized user authentication and accounting system. It
supports back-end SQL databases for accounting. More information can be found
at http://www.gnu.org/software/radius/ 
II. DESCRIPTION
 Remote exploitation of a format string vulnerability in GNU Radius could allow
an attacker to execute code in the context of the running daemon. 
 The vulnerability specifically exists within the SQL accounting code. A format
string is built using user supplied data and then unsafely passed to the
variable argument function 'sqllog'. 
III. ANALYSIS
 Successful exploitation allows unauthenticated remote attackers to execute
arbitrary code in the context of the running radius daemon (radiusd). Typically
the radius daemon will run as root. 
 Exploitation requires that radiusd be compiled with an SQL back-end and SQL
accounting be turned on. These options are both turned on by default for
FreeBSD and Gentoo Linux. 
IV. DETECTION
 iDefense has confirmed that this vulnerability is present in version 1.3 and
1.2 of GNU Radius. It is likely that all prior versions are vulnerable. 
V. WORKAROUND
 iDefense confirms that using one of the other supported accounting methods
will mitigate exploitation of this vulnerability while still allowing
accounting to take place. 
VI. VENDOR RESPONSE
 The GNU Radius team included a fix for this vulnerability in version 1.4. 
VII. CVE INFORMATION
 The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2006-4181 to this issue. This is a candidate for inclusion in the CVE list
(http://cve.mitre.org), which standardizes names for security problems. 
VIII. DISCLOSURE TIMELINE
 08/16/2006 Initial vendor notification
 09/08/2006 Initial vendor response
 11/06/2006 Second vendor notification
 11/26/2006 Coordinated public disclosure

IX. CREDIT
 The discoverer of this vulnerability wishes to remain anonymous. 
Get paid for vulnerability research
http://labs.idefense.com/methodology/vulnerability/vcp.php
Free tools, research and upcoming events
http://labs.idefense.com/
X. LEGAL NOTICES
 Copyright © 2006 iDefense, Inc.

 Permission is granted for the redistribution of this alert electronically. It
may not be edited in any way without the express written consent of iDefense.
If you wish to reprint the whole or any part of this alert in any other medium
other than electronically, please e-mail customer service for permission.

 Disclaimer: The information in the advisory is believed to be accurate at the
time of publishing based on currently available information. Use of the
information constitutes acceptance for use in an AS IS condition. There are no
warranties with regard to this information. Neither the author nor the
publisher accepts any liability for any direct, indirect, or consequential loss
or damage arising from use of, or reliance on, this information.

net-dialup please advise and bump as necessary.

i guess SQL support is a useflag? is SQL accounting enabled by default?

Version bumped and marked stable on x86 (the only keyword btw).

(In reply to comment #2)
> i guess SQL support is a useflag? is SQL accounting enabled by default?

yes and yes.
However, we do not provide a init script for radius daemon.

does this really run with root privs like stated in the advisory? If so, this
should be changed before sending a GLSA.

Created an attachment (id=102869) [details]
sqllog changes

The attachement describe changes occured in sqllog().

Since we don't provide a init script, I cannot say anything about this subject.
The user decides under which privileges will run radius daemon, not us.

The fact that we don't provide a init script speak for itself: there aren't
many gnuradius users. Most RADIUS peeps use freeradius (me included). 

sqllog function has no longer a variable list of arguments. Since all calls to
that function had only the 2 mandatory arguments, I can only conclude that
va_start can be exploited through a carefully chosen msg.

This one is ready for GLSA release. Sorry for the delay:-(

GLSA 200612-17