full-disclosure - FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20031127184726.GK17282@mail>
From: david at crlf.net (David Maxwell)
Subject: FreeRADIUS 0.9.2 "Tunnel-Password" attribute handling vulnerability

On Tue, Nov 25, 2003 at 04:19:02PM -0600, Ron DuFresne wrote:
> 
> >   "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;

You seem to be referring to the date the announcement was posted to Full
Disclosure. Alan is referring to the date the announcement was posted to
the public Free Radius mailing list.

> 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

I agree - I'll encourage Alan to add such information to the webpages.

[...]
> I think some level of credit should be given that an attempt was made. 
[...]
> 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

Alan is unlikely to refuse to address any future issue, or refuse to work
with anyone who contacts the developers with a security issue - any such
behaviour would be irresponsible for a project leader.

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

You don't seem to have the sequence of events straight - First, the
researcher published the vulnerability to the public FR list. At that
point, there was no reason to do anything other than patch ASAP, as
users were now exposed with no available resolution.

What point is there in coordinating an announcement of an already
published vulnerability? However, Alan provided a vendor statement to
the researcher - who then did not include it in his post to other
security lists.

Don't confuse Alan's lack of desire to 'coordinate' on an already public
vulnerability with a lack of desire to cooperate with this researcher,
or any others in the future.

-- 
David Maxwell, david@....net|david@...well.net -->
If you don't spend energy getting what you want,
	You'll have to spend it dealing with what you get.
					      - Unknown