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-radiusat_private> 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 <3APA3Aat_private> 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.
This archive was generated by hypermail 2b30 : Tue Nov 13 2001 - 15:31:25 PST