Re: More problems with RADIUS (protocol and implementations)

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 <[email protected]> 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 <[email protected]> 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.