Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:2178
HistoryNov 13, 2001 - 12:00 a.m.

More problems with RADIUS (protocol and implementations)

2001-11-1300:00:00
vulners.com
33

Hello bugtraq,

There are more problems in RADIUS protocol and some of implementations:

  1. There is no way RADIUS server can validate Access-Request packet
    really originated by NAS (RADIUS client) before (and even after, if
    packet has no User-Password attribute) decoding all attributes. It opens
    a possibility to spoof source IP for this kind of packets. I think this
    is a major weakness in RADIUS protocol rather then all hard-to-exploit
    cryptographic M-i-t-M issues.

Example: according to RFC 2865 each RADIUS packet can be up to 4096
bytes. It allows to put > 2000 attributes into a single packet. Most
RADIUS servers implementations allocate maximum attribute length for
each attributes, it means for each attributes > 256 bytes of memory will
be allocated. So, it's possible to lock >512K of memory and amount of
CPU time with a single 4K packet. Nice possibility to DoS.

Attached is simple flooder to flood server with packets like this. It
doesn't spoof source IP, so it can only be used to test your RADIUS
server (you must use it from IP registered as NAS).

  1. RFC 2865 requires unpredictability of authenticator value in
    Authentication Request packet. Many RADIUS servers and client libraries
    implementations do not follow it. Many of them have code like
    srand(time(0) + getpid()) (or even srand(time(0)) + rand(). As you know,
    the number of rand() states is very limited and it's easy to predict the
    state of PRNG. It opens possibility to spoof NAS Authentication Request.

For example Cistron RADIUS has this flow in proxy module. Many RADIUS
client libraries also have this flow.

  1. Most of current freeware RADIUS server implementations (and some of
    commerce ones) are derived from Cistron. And most of them (including
    Cistron itself) have buffer overflow in digest calculation (in case of
    Cistron itself it's static data overflow in calc_acctdigest() function).
    This function adds shared secret to packet data to calculate digest, but
    space for shared secret never allocated in buffer. If packet is exactly
    of allocated size (in case of Cistron it's 1024 - they do not exactly
    follow RFC) string pointer located after the buffer in memory will be
    overwritten with shared secret. Probably this overflow can only lead to
    DoS. Since overflow occurs before packet is checked, it can be exploited
    from spoofed IP.


http://www.security.nnov.ru
/\_/\
{ . . } |\
±-oQQo->{ ^ }<-----+ \
| ZARAZA U 3APA3A }
±------------o66o–+ /
|/
You know my name - look up my number (The Beatles)