More problems with RADIUS (protocol and implementations)

Type securityvulns
Reporter Securityvulns
Modified 2001-11-13T00:00:00


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.

-- /\_/\ { . . } |\ +--oQQo->{ ^ }<-----+ \ | ZARAZA U 3APA3A } +-------------o66o--+ / |/ You know my name - look up my number (The Beatles)