Full Disclosure mailing list archives
Re: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability
From: Ron DuFresne <dufresne () winternet com>
Date: Tue, 25 Nov 2003 16:19:02 -0600 (CST)
"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 () s-quadra com> To: full-disclosure () lists 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 () freeradius org", "postmaster", "webmaster", or "aland () freeradius 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 () freeradius 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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability S-Quadra Security Research (Nov 21)
- Re: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability David Maxwell (Nov 21)
- Re: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability Ron DuFresne (Nov 25)
- Re: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability David Maxwell (Nov 27)
- Re: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability David Maxwell (Nov 27)
- Re: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability Ron DuFresne (Nov 27)
- Re: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability Ron DuFresne (Nov 25)
- Re: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability David Maxwell (Nov 21)