[UNIX] GNU Radius SNMP String Length Integer Overflow DoS
From: SecuriTeam (support_at_securiteam.com)
To: firstname.lastname@example.org Date: 21 Sep 2004 13:56:14 +0200
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
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
- - - - - - - - -
GNU Radius SNMP String Length Integer Overflow DoS
" <http://www.gnu.org/software/radius/radius.html> Radius is a server for
remote user authentication and accounting. Its primary use is for Internet
Service Providers, though it may as well be used on any network that needs
a centralized authentication and/or accounting service for its
Remote exploitation of an input validation error in radiusd could allow a
denial of service.
* GNU Radius server versions 1.1 and 1.2
* GNU Radius server version 1.2.94
The problem exists in an ASN decoding routine in the Radius server code.
The function is asn_decode_string() which is defined in snmplib/asn1.c .
When a very large unsigned number is supplied, it is possible that an
integer overflow will occur in the bounds-checking code. The daemon will
then attempt to reference unallocated memory, resulting in an access
violation that causes the process to terminate.
Successful exploitation allows unauthenticated remote attackers to cause
the radius daemon (radiusd) to crash. This thereby prevents legitimate
users from accessing systems reliant upon the affected radius server for
authentication. This vulnerability does not seem to allow for execution of
code. It is a denial of service condition only. Exploitation requires that
radiusd be compiled with the --enable-snmp option. SNMP support is not
enabled in the default build procedure.
Disable SNMP support when building radiusd at compile time. Ingress
filtering of UDP port 161 on all interfaces that should not be receiving
SNMP packets may lessen exposure to this vulnerability in affected
The vulnerability is already fixed in a newer, maintenance release
version. Users are highly encouraged to upgrade to an immune version.
09/10/2004 Initial vendor notification
09/10/2004 Initial vendor response
09/15/2004 Public disclosure
The information has been provided by
<mailto:email@example.com> iDEFENSE Security Labs.
The original article can be found at:
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: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
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.