freeradius denial of service in authentication flow

Pierre Carrier pierre.carrier at
Thu Feb 13 01:49:41 UTC 2014

On Wed, Feb 12, 2014 at 5:00 PM, Alan DeKok <aland at> 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
base64_decode(vp->strvalue, buffer).
Nothing stops this base64_decode invokation from going over the buffer
boundary, a uint8_t[64] 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 mailing list