From owner-freebsd-bugbusters@FreeBSD.ORG Sun Feb 16 09:39:39 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 55AD6F85 for ; Sun, 16 Feb 2014 09:39:39 +0000 (UTC) Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 11DEE1D5E for ; Sun, 16 Feb 2014 09:39:38 +0000 (UTC) Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WEyC7-0002u6-Pt; Sun, 16 Feb 2014 10:39:27 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1WEyC7-0002Z8-FR; Sun, 16 Feb 2014 10:39:27 +0100 From: Florian Weimer To: Alan DeKok Subject: Re: freeradius denial of service in authentication flow References: <52FC1916.4060501@freeradius.org> <87sirkm8uo.fsf@mid.deneb.enyo.de> <52FFD55C.5030408@freeradius.org> Date: Sun, 16 Feb 2014 10:39:27 +0100 In-Reply-To: <52FFD55C.5030408@freeradius.org> (Alan DeKok's message of "Sat, 15 Feb 2014 16:00:12 -0500") Message-ID: <87y51bwg4w.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pierre Carrier , secalert , pkgsrc-security , security@ubuntu.com, security@freeradius.org, pupykin.s+arch@gmail.com, security@debian.org, bugbusters 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: Sun, 16 Feb 2014 09:39:39 -0000 * Alan DeKok: > Florian Weimer wrote: >> * Alan DeKok: >> >>> That's an issue, but a rare one IMHO. The user has to exist on the >>> system. So this isn't a remote DoS. >> >> Could you elaborate on this assessment? Is this because typical data >> sources for SSHA passwords limit the length of the salt and thus the >> length of the SSHA hash? > > Partly. The typical use-case for a remote DoS is for an > unauthenticated user to take down the system. Here, the user has to be > known, *and* be able to create a long SSHA password. > > To me, this puts the issue into the category of "known users can do > bad things", which is very different from "unknown users can do bad things". Okay, fair enough. As this is already public via , I will request a CVE on oss-security.