v1.0.5, and v1.1.0
A validation issue exists with the EAP-MSCHAPv2 module in all versions from 1.0.0 (where the module first appeared) to 1.1.0. Insufficient input validation was being done in the EAP-MSCHAPv2 state machine. A malicious attacker could manipulate their EAP-MSCHAPv2 client state machine to potentially convince the server to bypass authentication checks. This bypassing could also result in the server crashing. We recommend that administrators upgrade immediately.
mrness, pls provide an updated ebuild
I would love to, but freeradius-1.1.1 is uncompilable (compilation breaks at rlm_eap module).
I've managed to fix some problems, but I still have 2 more left on this module: linker fails to find radius_xlat and log_debug symbols. It's kinda strange those functions are used here, since they are defined in radiusd daemon not the radius library.
Seems it will take awhile.
I've reported the rlm_eap compilation problems to upstream (see http://bugs.freeradius.org/show_bug.cgi?id=350).
any progress on this one?
Yes, I've spoked with upstream on email@example.com.
It could be build if I would not patch the rlm_eap makefile at all and drop --disable-static from .configure command line.
I don't like this, but is the only way. I will bump it today.
the new version has been commited, with the same keywords as the 1.1.0-r1 (I've tested myself on x86 and amd64).
sorry for the delay, but this bump was horrible. I'm still not perfectly happy with the results because I had to remove --disable-static from configure cmd line in order to make it work.
Thx Alin, this one is ready for GLSA decision. I tend to vote YES.
vote Yes, sure.
Do not forget that the old version isn't vulnerable to DoS attacks on Gentoo.
The init script use radwatch script, which restart radiusd daemon if it dies.
The important part for me here is "A malicious attacker could
manipulate their EAP-MSCHAPv2 client state machine to potentially convince the
server to bypass authentication checks."
I'm only saying this for keeping "DoS" word out from the GLSA.
0.5 vote for a glsa
Given the scope of freeradius use, I vote yes.