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 attachment 102869 [details, diff] 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
