From: 3APA3A [3APA3A@SECURITY.NNOV.RU]
Sent: Tuesday, November 13, 2001 6:50 AM
To: bugtraq@securityfocus.com
Cc: miquels@cistron.nl; Joshua Hill
Subject: More problems with RADIUS (protocol and implementations)

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).

2.   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.

3.  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)