Date: Wed, 12 Feb 2014 17:43:10 -0800 From: Pierre Carrier <pierre.carrier@airbnb.com> To: Alan DeKok <aland@freeradius.org> Cc: secalert <secalert@redhat.com>, pkgsrc-security <pkgsrc-security@netbsd.org>, security@ubuntu.com, security@freeradius.org, pupykin.s+arch@gmail.com, security@debian.org, bugbusters <bugbusters@freebsd.org>, product.security@airbnb.com Subject: Re: freeradius denial of service in authentication flow Message-ID: <CAM7LUF5e07PTwWAdcGEJNdZ24Nk0ssugCeoc=u_uMy8i-7xvOQ@mail.gmail.com> In-Reply-To: <52FC1916.4060501@freeradius.org> References: <CAM7LUF55w4g7=GqhfFyys0fhJNKQtX-Pp804YWRW57GxbO9WDw@mail.gmail.com> <52FC1916.4060501@freeradius.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 12, 2014 at 5:00 PM, Alan DeKok <aland@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
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM7LUF5e07PTwWAdcGEJNdZ24Nk0ssugCeoc=u_uMy8i-7xvOQ>