freeradius denial of service in authentication flow
pierre.carrier at airbnb.com
Thu Feb 13 01:49:41 UTC 2014
On Wed, Feb 12, 2014 at 5:00 PM, Alan DeKok <aland at freeradius.org> wrote:
> Do you have examples of such SSHA passwords? That would help with
> testing. Right now, it's not clear to me why this happens. The code
> does a number of checks for size of password in the various encodings.
My current understanding would be, make any large SSHA password.
Sadly I don't have a testbed. I don't maintain our enterprise
infrastructure and have little prior knowledge of Radius.
rlm_pap.c, mod_authorize, case PW_SSHA_PASSWORD calls normify(request,
vp, 20), which for base64-encoded values will invoke
Nothing stops this base64_decode invokation from going over the buffer
boundary, a uint8_t on the stack.
So here's a valid SSHA which I believe would trigger this bug, simply
slightly too long for the stack:
$ ruby -rdigest/sha1 -rbase64 -e "pass='a';salt=pass*64;puts
Increase the salt length (64 bytes here) if need be, eg to a few megabytes.
Apparently the libc on our server has a stack canary, so it crashed
very reliably when a subset of our users tried to authenticate.
>> Terrible hotfix quickly packaged to avoid constant crashes here, does
>> not address the vulnerability:
> The checks in the code rely on sizeof(buffer). Making "buffer" bigger
> prevents small passwords from causing the issue. But larger ones could
> still cause it.
Again, with that fix I merely wanted to avoid constant crashes of our
office network, not address the vulnerability :)
> That's an issue, but a rare one IMHO. The user has to exist on the
> system. So this isn't a remote DoS.
Indeed, it is not a remote DoS, and I agree the practical implications
aren't too scary.
But, as a hypothetical, convoluted illustration:
A disgruntled employee could prevent all access to a company's
internal network without out-of-band intervention, including from
remote locations if the Radius infrastructure is centralized.
Such internal network access could be needed to revoke their credentials.
More information about the freebsd-bugbusters