Re: freeradius denial of service in authentication flow

Pierre Carrier <[email protected]> Wed, 12 Feb 2014 17:43:10 -0800
Newsgroups gmane.os.freebsd.bugbusters
Message-ID <CAM7LUF5e07PTwWAdcGEJNdZ24Nk0ssugCeoc=u_uMy8i-7xvOQ@mail.gmail.com>
On Wed, Feb 12, 2014 at 5:00 PM, Alan DeKok <[email protected]> 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
'{SSHA}'+Base64.encode64(Digest::SHA1.digest(pass+salt)+salt).gsub(\$/,'')"
{SSHA}EWVTJscI1wMZviYQ6KV9mluVnTthYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh

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.


-- 
Pierre
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugbusters
To unsubscribe, send any mail to "[email protected]"