Re: Thoughts on Issue 325

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> In Issue 325 (see
> a.       *Clearer articulation of the current situation.*    As noted in
> Joeâs original posting, not all uses of complex attributes (such as
> sending of a complex attribute from server to client) require code
> changes on the server, and the need for code changes
> differ considering whether we are talking about the client or server
> side, or whether the attribute is being sent or received.

  I will see if I can propose some text.

> b.      *More detailed look at security issues.*  Section 2.1.4
> addresses the potential security vulnerabilities of complex attributes. 
> However, since RADIUS has been around a while, we have concrete data
> relating to the types of issues that tend to result
> in major security problems

  Have all of the vendors published all vulnerabilities?

  We are only seeing a portion of the issues in any vulnerability database.

  My experience has been:

a) most externally exploitable crashes / overflows are due to
encoding/decoding of packet data.  Since the RADIUS packet format hasn't
changed in 15 years, the culprit to blame is attributes.  Since the
encoding/decoding of int/ipaddr/etc. (simple) attributes hasn't changed
in 15 years. the culprit to blame is text/string attributes.

b) many other vulnerabilities are due to insecure *use* of packet data.
 These issues don't usually apply to int/ipaddr/etc (simple) attributes,
as it is difficult to send malicious data in them.  The issues usually
have to do with text/string attributes.  (i.e. complex ones)

c) I've managed to crash a number of systems doing interoperabilty
tests.  To my recollection, many of these issues were never publicly
reported in a vulnerability database.

> Looking
> at the past incidents, it is not clear to me that all âcomplexâ
> attributes would be equally likely to exhibit these problems.
> 
> For example, it would seem to me that a âcomplexâ attribute of fixed
> length would be less likely to be vulnerable to a buffer
> overflow than one that involved variable length, particularly if this
> was combined with polymorphism and/or nesting.

  Pretty much, yes.  Or attributes that encode complex types with
"length" fields that are 16 bits, or are 8-bits of "count of 32-bit
words".  Both can result in the encoded data claiming to be "larger"
than the encapsulating attribute, and lead to overflows.

> c.       *Additional considerations.*  As noted in the Appendix,
>  complex RADIUS attributes have been used in the past, so
> that in those cases their merit was thought to outweigh the
> disadvantages.   While A 2.2 does provide considerations
> useful for the evaluation of a âcomplexâ attribute design, it is not
> clear to me that all the useful elements of a potential
> checklist have been taken into account.

  I'm not sure we can have an exhaustive checklist.

  Good design is a balance.  Solutions are often a compromise between
two equally ugly alternatives.

>  For example, looking back at
> RFC 5090,  the decision was made to break up
> a âcomplexâ String attribute into 20 separate attributes.    Given the
> number of additional attributes that were
> consumed as well as the effort required to parse each of these 20
> attributes,  did this decision really generate
> benefits in excess of the costs?   In retrospect, the argument does not
> seem like a slam dunk.

  Some of that was due to a desire to be (somewhat) compatible with
existing deployments of an I-D that had not passed review.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>