Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Security)  >   FreeRADIUS Vendors:   FreeRADIUS Server Project
FreeRADIUS Authentication Server (and Possibly Other RADIUS Servers) May Become Overloaded By a Remote Flood of Access-Request Packets from a Single User
SecurityTracker Alert ID:  1003643
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Feb 22 2002
Impact:   Denial of service via network
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  

Description:   A vulnerability was reported in the FreeRADIUS authentication server. A remote user can flood a Network Access Server (NAS) with certain PPP requests such that the NAS will flood the RADIUS server. This flaw may also affect other RADIUS servers.

A remote user can flood a NAS with PPP requests that contain an invalid password, causing the NAS to turn around and send an Access-Request to the RADIUS server. While the flooding attack is in progress, it is reported that the FreeRADIUS will lock up. When the attack stops, the server reportedly will resume normal operation.

Impact:   A remote user can cause the RADIUS server to temporarily lock up.
Solution:   For FreeRADIUS, the code has been patched so that it now waits for a configurable amount of time before sending an Access-Reject to the Network Access Server (NAS). This will cause the NAS to ignore any new PPP requests from the problem user (the one causing the flood) until the NAS receives a response from the RADIUS server.

These changes are available in the current CVS snapshot FreeRADIUS, available at:

These changes will reportedly be included in any subsequent release.

Vendor URL: (Links to External Site)
Cause:   Resource error, State error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   None.

 Source Message Contents

Subject:  DoS Attack against many RADIUS servers

  There was a report recently to the maintainers of FreeRADIUS of a
DoS attack against it.  For background, FreeRADIUS is a free software
RADIUS authentication, authorization, and accounting server. [1]

  The attack was launched from a Nortel Shasta BSN 5000, by a user who
flooded the NAS with PPP requests containing an invalid password, over
a DSL link.  All of the PPP requests failed, as when the NAS sent an
Access-Request to the RADIUS server, it responded with an
Access-Reject response, due to the invalid password.

  However, the flood of Access-Request packets caused the server to
effectively lock up while the attack was in progress.  The system load
during the attack was 60.  When the attack stopped, the server
resumed its normal operation.

  During the attack, few other users were able to authenticate, as the
server was busy processing the flood of requests from the attack.

  The code was subsequently patched so that it would wait for a
configurable time before sending an Access-Reject to the NAS.  This
change caused the NAS to ignore any new PPP requests from the problem
user, until it received a response from the RADIUS server.  These
changes are available in the current CVS snapshot FreeRADIUS [2], and will
be included in any subsequent release.

  Nortel was contacted by the administrator of the NAS under attack,
and their apparent response was that it wasn't their job to limit
RADIUS traffic.  While I can understand that approach, I would have
preferred that the NAS was part of the solution to network problems.

  My examination of other freely available RADIUS implementations
indicates that most, if not all, of them would be vulnerable to the
same attack.  I believe that many commercial RADIUS servers are also
vulnerable.  Other NAS boxes may also contribute to the problem, by
originating non-rate-limited RADIUS packets.

  Coupled with the previous message to BugTraq from [3], these problems indicate a severe
vulnerability in most RADIUS implementations.

  A decent method of avoiding these problems is to place the RADIUS
server on a protected network, where the traffic to it may be
controlled.  Dial-up users should not be able to route packets to the
server, and packets from the Internet should not be routable to the
server.  If proxying to another site across the internet is required,
then a secure transport protocol like IPSec should be used.

  In such a configuration, the server will be exposed to a minimum of
possible attacks.

  Alan DeKok.


[1] FreeRADIUS:




Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, LLC