Subject: Thoughts on Issue 325

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 13 Jan 2010 14:27:18 -0800

In Issue 325 (see
http://aboba.drizzlehosting.com/RADEXT/radissues3.html#Issue%20325) ,  Joe
pointed out a number of

issues within the Design Guidelines document Sections 2.1.3, 2.1.4, 5, A2.1
and A2.2.  

The comments on Sections 5 and A.2.1 relate to the clarity of those
sections, which presumably can be addressed by appropriate edits, 

so I will not dwell on those aspects. 

Instead I will focus on the comments on Sections 2.1.3, 2.1.4 and A 2.2,
which relate to  complex attributes.   Those Sections

have garnered considerable discussion on the list, much of it "frank" (to
use a diplomatic phrase). 

With respect to complex attributes, my interpretation of the list discussion
is that Sections 2.1.3, 2.1.4 and A 2.2 should be revised.   

IMHO, improvements could be made in some of the following aspects of the
current text: 

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. 

My personal take is that Section 2.1.3 could do with some restructuring to
better articulate the implications of each scenario (see

http://ops.ietf.org/lists/radiusext/2009/msg00665.html for details). 

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 (e.g. see
http://securityvulns.com/advisories/radius.asp ), such as buffer overflows.
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. 

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.  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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Jan 2010 09:11:57 +0100

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. 
> 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
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 14 Jan 2010 13:24:15 -0800

Alan said:

"  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."

[BA] Yes, these are the kind of issues that have resulted in widely
publicized exploits against many different RADIUS servers. 

Alan said:

"  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."

[BA] Yes.  However, the question is whether we provide enough info to
enable the reader to understand that balance.  

Alan said:

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

[BA] My understanding is that the major change from the draft to
RFC 5090 was chopping up a single string attribute into 20 pieces. 
Some of the individual attributes make sense to me because they
are the kind of thing that might be used in policy logic
(such as the realm).  However, RFC 5090 is about 
authentication, so that the Design Guidelines document would
also appear to offer the possibility to have left the string
intact. 

Overall, RFC 5090 is not viewed very favorably within the
SIP or HTTP communities, and as far as I know, it is much
less widely implemented than the draft which it purported
to "improve".  

So the question in my mind is how this particular case could
should have been handled, and whether that is reflected in
the document.