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]"