More problems with RADIUS (protocol and implementations)

From: 3APA3A (3APA3Aat_private)
Date: Tue Nov 13 2001 - 03:50:14 PST

  • Next message: Damir Rajnovic: "UPDATED: Cisco SSH Advisory"

    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)
    
    



    This archive was generated by hypermail 2b30 : Tue Nov 13 2001 - 05:32:13 PST