Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: More problems with RADIUS (protocol and implementations)
From: aland () striker ottawa on ca
Date: Tue, 13 Nov 2001 12:16:02 -0500

  I note that the original message didn't cite my short message to
Bugtraq about security issues with RADIUS:

http://cert.uni-stuttgart.de/archive/bugtraq/2000/12/msg00332.html

  Some points in that message were also covered by Joshua, he added a
number of good points, and missed a few others.  Specifically, rfc2869
defines the Message-Authenticator attribute, which is used to sign
packets.  This signature allows Access-Request packets to be verified,
negating the security problems of spoofed packets.

  Unfortunately, not all RADIUS client implementations support
Message-Authentictor.  Some have an incorrect implementation, and
others define the same attribute to have a proprietary meaning,
negating it's potential security.

Joshua Hill <josh-radius () untruth org> wrote:

  4.1 Summary Findings

...
     * The Access-Request packet is not authenticated at all. (attack
       3.4)

  RFC 2869 and the Message-Authenticator negate this statement, with
the exception of older RADIUS client implementations.

     * Many client implementations do not create Request Authenticators
       that are sufficiently random. (all attacks in 3.5)
     * Many administrators choose RADIUS shared secrets with insufficient
       information entropy. Many client and host implementations
       artificially limit the shared secret key space. (note 3.6)

  As always, a security system is only so strong as it's
implementation faults.  It has been my experience that the majority
(if not all) of security issues with RADIUS has been with poor
implementations.  Attacks using protocol failures are few, and can
often be protected against via other mechanisms.

  4.2 Suggested Protocol Additions

  A few of the issues discussed here, and the proposed solutions, have
already been addressed in later RADIUS RFC's.

  Changing RADIUS now is nearly impossible, for two reasons.  One, the
IETF RADIUS group has been disbanded, and starting it up again will
face great opposition.  Two, implementing RADIUS properly (following
the RFC's) is so difficult for many vendors that I, personally, hold
no hope for any extensions being added to fix security problems in the
protocol.


  However, I do agree with the sentiment that DIAMETER is probably too
heavy-weight for many embedded systems.  There is a need for a
light-weight, secure, authentication and accounting protocol.


In another message, 3APA3A <3APA3A () SECURITY NNOV RU> wrote:
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.

  This issue is new, at least to bugtraq.  He discussed it earlier on
the FreeRADIUS development list, which does not have wide circulation:

http://lists.cistron.nl/pipermail/freeradius-devel/2001-October/001504.html


  Coupled with the spoofing of Access-Request packets with no
Message-Authenticator attribute, this attack may be serious.  The
defenses appear to be securing the implementation against this attack,
and to a lesser extent firewall rules can help limit the scope of the
attack.

3.  Most  of current freeware RADIUS server implementations (and some of
commerce  ones)  are  derived  from Cistron.

  Which is itself derived from Livingston 1.16.  There have
historically been a number of commercial RADIUS servers derived from
Livingston 1.16.  That practice should be discouraged.

 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.

  This attack does not permit the attacker to execute any code on the
RADIUS server, but it does allow the attacker to force a SEGV on the
server, and thus to crash it.

  Alan DeKok.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]