Message-ID: <Pine.GSO.4.43.0311211346310.16748-100000@tundra.winternet.com>
From: dufresne at winternet.com (Ron DuFresne)
Subject: FreeRADIUS 0.9.2 "Tunnel-Password" attribute
 handling vulnerability



>
>   "S-Quadra Security Research" posted a vulnerability earlier today
> about FreeRADIUS which is (to be polite) not entirely correct.

since the freeradius folks Actually you yourself?> responded yesterday to
this, isn't your claim here a tad misleading?  Afterall, their announcment
is posted and dated today, friday, not thursday when the first reference
and the patch was announced;

Date: Fri, 21 Nov 2003 15:32:39 +0300
From: S-Quadra Security Research <e.legerov@...uadra.com>
To: full-disclosure@...ts.netsys.com
Subject: [Full-Disclosure] FreeRADIUS 0.9.2 "Tunnel-Password" attribute
    handling vulnerability


            S-Quadra Vendor Report #2003-11-21

Topic: FreeRADIUS 0.9.2 "Tunnel-Password" attribute Handling Vulnerability
Severity: Average
Release date: 21 Nov 2003



>
>   The post says:
>
>    "There exists a security vulnerability in FreeRADIUS up to 0.9.2,
>     which may allow an attacker to mount a Denial of Service attack or
>     possibly execute an arbitrary code (unproved)."
>
>   The vulnerability exists from version 0.4.0 onwards, and is not
> exploitable.  The vulnerability is a heap overflow, taking data from
> the packet contents.  That data MUST form a valid RADIUS packet, which
> significantly limits the possible exploits.  Further, as it is a heap
> overflow, it cannot overwrite any local variables (it may overwrite
> internal malloc() pointers, though).  When coupled with the "-1"
> argument passed as the length to memcpy(), the end result is that the
> data copy always results in a SEGV, before memcpy() returns.
>
>
>   The post later says:
>
>    "Access-Request packet with a malformed Tunnel-Password attribute
>     triggers the invocation of memcpy() with a negative third
>     argument, thereby causing radiusd to crash."
>
>   This statement is only partially correct.  Examination of the code
> posted in the summary makes it obvious that the vulnerability extends
> to any RADIUS attribute containing a tag, not just Tunnel-Password.
>
>   Further, ANY Access-Request packet containing a Tunnel-Password runs
> into an unrelated (and previously unreported) bug, which causes the
> server to de-reference a NULL pointer, and thus SEGV.  We note that
> the skills of "S-Quadra Security Research" did not extend to
> discovering either of these additional issues.
>
>
>   The post later says:
>
>    "S-Quadra alerted FreeRADIUS team to this issue on 20th November
>    2003, fix was available in CVS after several hours.
>
>    Unfortunately, the first attempt to contact with FreeRADIUS
>    development team was made through post to freeradius-users mailing
>    list ..."
>
>   He failed to give the developers ANY prior notification about the
> bug, so that a fix could be released before public disclosure of the
> vulnerability.
>
>   The post continues:
>
>    "... as page http://www.freeradius.org/usage.html#help ("reporting
>     bugs" section) will lead directly to the subscription form for
>     this list."
>
>   This is nothing more than an attempt to excuse his own laziness.  He
> did not try "security@...eradius.org", "postmaster", "webmaster", or
> "aland@...eradius.org", which is used to sign the public releases.
> Additionally, 10 seconds of searching the list archives would have
> revealed the developers private email addresses.  10 seconds of
> searching the server source code would have yeilded the same result.
> Reading the server documentation would have yielded further email
> addresses at freeradius.org where patches and/or bugs may be reported
> to.

Of course a mail alias on your end to direct bugs, or bugreports, or
something perhaps a tad more clear for addressing such issues could well
have eased the troubles these folks had traversing your site <could well
be they are not using english as a home language, first language, and that
could have contributed to their difficulty in finding the peroper place to
address reports to>.  but, From what I've seen thus far, they at least
*did* make an attempt to alert the developers/maintainers, and felt the
way to go about that was the users list.  I think some level of credit
should be given that an attempt was made.  Much of what the freeradius
folks have printed yesterday and today reminds me much of how in earlier
days admins and sec folks tried to discredit the hacker/cracker crowd with
remarks and comments in their analysis of "typos" and poor command skills
and such.  It comes off kinda as whining, let alone attepmts to  cast
blame away from  those that got caught in an issue.  Not that blame is
really the issue here.  The issue was there was a flaw, it was found,
folks tried, and perhaps only half-heartedly to notify others of the issue
prior to going public, and the information made it to the proper end
channel and was addressed.  No real harm done, thill the responses started
to flow from the  freeraduis crowd that seems to feel *insulted* that a
flaw was discovered in their code.  Big deal, flaws happen, and if
addressed quickly, damage can be mitigated and limited to those using the
product/tools.  No need to dig a hole and then climb in and dig deeper,
makes those doing the digging look like idiots.

>
>   It further continues:
>
>    "We actually admit that such behaviour is NOT correct and our
>     futher FreeRADIUS security reports will be issued directly to
>     freeradius-devel mailing list."
>
>   This is his response, after we informed him that
> "security@...eradius.org" was the appropriate place for future
> notifications.  We are appalled.
>
>   In short, he made no effort whatsoever to privately contact anyone
> associated with the project.  And after he has been informed of an
> appropriate forum for future reports, he publicly refuses to use that
> method.  This behaviour is amateur, and inappropriate.
>
>
>
>   When we agreed that the vulnerability existed, he contacted me
> privately, and asked that FreeRADIUS coordinate release of the
> vulnerability with him.  We refused, as he had already demonstrated an
> inability to coordinate public release of information in an ethical
> and professional manner.  His response was then to threaten
> wide-spread publication of the vulnerability, and this time, to
> include exploit code.
>

So, you decided to not work with the researcher, made your bed, and now
have to lay in it, bummer, might want to rethink that stratedgy in the
future.  If the developers/maintainers decide to not work with the
researchers/discoverers of bugs, then well, bummer, dance to the music.


>   We do not respond well to threats or attempts at blackmail.
>
>   I sent him an official response as the FreeRADIUS Project Leader,
> and requested that he include it in any further public release of the
> vulnerability.  He has not done so.  I find this behaviour
> reprehensible.
>
>   FreeRADIUS released version 0.9.3 yesterday, which fixes the DoS
> vulnerability.  We wish to have nothing more to do with "S-Quadra
> Security Research".
>
>

Alan, seriously, stop whining,  rethink your stratedgies and decisions for
the potential "next time", and realize, a little understanding and leeway
to *minor* errors goes along way to avoiding outright hostility.  Unless
you have a large budget for R&D/Q&A, working with researchers in this
realm may well be benificial to the project/product as a whole.

Thanks,

Ron DuFresne
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.

Powered by blists - more mailing lists