From owner-freebsd-bugbusters@FreeBSD.ORG Thu Feb 13 01:49:41 2014 Return-Path: Delivered-To: bugbusters@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 263A794 for ; Thu, 13 Feb 2014 01:49:41 +0000 (UTC) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B019F14B7 for ; Thu, 13 Feb 2014 01:49:40 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hm4so7842144wib.13 for ; Wed, 12 Feb 2014 17:49:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+Q6tLQU7pJF40itEmAe2sINmNORnf9Grm9pjiO0xF0w=; b=OPtbBILmtDytqqKVHkfSs7tbSXaGgMK+1dJOgTPOLPpR7a/qQK3OqkNWNy4FZWOwoq e99tNYsGKdqCLWMCk2mqQtiK8vERpdxKE1ZvM/XQuezcORSDCWTY/HwFAwanVm9doYpv 49SpJfoTl+iB2ESq2UMVY9941NloZdre40LKvxux8+VP3tyDXR9jKnB540rOHMcOII1D EobNNVGMy8r6l5QpozJpzr6nHbmdtgLnfYGJakF5GTplV3ScmvS4dhIE/62j0XfQdO0A wCaD0IMGmd4Z2lPaN7P8e12JbqkFP83xdihKwy5N4VSg3OTKWcDoCLmdLxqCDvTesjf3 xlfw== X-Gm-Message-State: ALoCoQmax5cMDXiiDEUpJLQq7s97vq3LI80REm6S4pB+5y/SKoGwhRuzOmPDA8AyMlI8JLNiK240 X-Received: by 10.180.13.33 with SMTP id e1mr4438006wic.38.1392255810993; Wed, 12 Feb 2014 17:43:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.241.168 with HTTP; Wed, 12 Feb 2014 17:43:10 -0800 (PST) In-Reply-To: <52FC1916.4060501@freeradius.org> References: <52FC1916.4060501@freeradius.org> From: Pierre Carrier Date: Wed, 12 Feb 2014 17:43:10 -0800 Message-ID: Subject: Re: freeradius denial of service in authentication flow To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Cc: secalert , pkgsrc-security , security@ubuntu.com, security@freeradius.org, pupykin.s+arch@gmail.com, security@debian.org, bugbusters , product.security@airbnb.com X-BeenThere: freebsd-bugbusters@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Coordination of the Problem Report handling effort." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 01:49:41 -0000 On Wed, Feb 12, 2014 at 5:00 PM, Alan DeKok 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