From owner-freebsd-bugbusters@FreeBSD.ORG Wed Feb 12 22:02:50 2014 Return-Path: Delivered-To: bugbusters@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC2E2845 for ; Wed, 12 Feb 2014 22:02:50 +0000 (UTC) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 460751390 for ; Wed, 12 Feb 2014 22:02:49 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w62so6695510wes.15 for ; Wed, 12 Feb 2014 14:02:48 -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:from:date:message-id:subject:to :content-type; bh=Pxuz3KwTIsqpTKmh9wi/chJ8Tm+vvfXHblrtSdvBRoQ=; b=hrlzIOuxSw655Kq1vLNuWbGOfAqMq+C/9RFJiWQSYlxj7+NduvERQaBvTF3rSYqBFC i3hGxAYfW5rtwIdG5Od1EAADRartCNQ29am48W2Na+Vp04aA5frofwwf2vAWqVZm/DoP +T04bEJvgDVvzaKIMMyBwmTZZO0WEnVg8rMoPpcN8EY08cmuyZpZykDjuVySGDyJoiqD VhP35qocw8/ytdqo5MK5RLacnhdzpJnWMaC1INdV27K0TQF1XOSmKBug2TJv60mTKbIE BltAHkShDtNy0hz9p8HfzC/FUnZgmnrLhCeCLUmdTUmKXqyeVfwpX4NnWmBthYzg+4n8 jfAw== X-Gm-Message-State: ALoCoQmMhidvpOmVDOT00kxDm9JwBpT/hiU3sgsPJF3N+Kmzdo9gyAW/piU8qvMO8AZdYrAU9V7e X-Received: by 10.194.6.8 with SMTP id w8mr32096894wjw.16.1392242567908; Wed, 12 Feb 2014 14:02:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.241.168 with HTTP; Wed, 12 Feb 2014 14:02:27 -0800 (PST) From: Pierre Carrier Date: Wed, 12 Feb 2014 14:02:27 -0800 Message-ID: Subject: Insufficient salting in the net-ldap Ruby gem To: rory@berecruited.com, pkgsrc-security@netbsd.org, bugbusters@freebsd.org, secalert@redhat.com, product.security@airbnb.com Content-Type: text/plain; charset=UTF-8 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: Wed, 12 Feb 2014 22:02:50 -0000 Hello, SSHA passwords generated by the net-ldap Ruby gem use a salt between "0" and "999", only providing 10 bits of entropy. This is an attack vector, making attacks based on rainbow tables significantly easier than with a strong salt. https://github.com/ruby-ldap/ruby-net-ldap/blob/master/lib/net/ldap/password.rb#L29 This E-mail is sent to the current upstream maintainer and all vendors that distribute a version of that gem. Your version might not be affected; if not, sorry for the noise. Best, -- Pierre Carrier Site Reliability Engineer, Airbnb From owner-freebsd-bugbusters@FreeBSD.ORG Wed Feb 12 22:55:07 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 835BA3EB for ; Wed, 12 Feb 2014 22:55:07 +0000 (UTC) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B6C017C7 for ; Wed, 12 Feb 2014 22:55:06 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q58so6554927wes.21 for ; Wed, 12 Feb 2014 14:55:05 -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:from:date:message-id:subject:to :content-type; bh=/G1YFBbJgtZOeki6UNMQkq7PSgXP9Kd2o3BXNG10U7g=; b=YV4ThBwJ8YXfL+xdI5wdB6AVCmt7lIj9FqAypGTv3hF1PIAb8GaDfOY9kN3ar0kI4i nRBRi8dOfLCblviNSJgs/d7mMLpbpUYvn5ucfTt3sDdx/ouYzTENOAl23XMvkHdnrUzL 5sgt8S0/GntIp6EL4nr1B+DXlu4KwC0jQwDniFXths9DU+Sxu8iXj3DPLwks4YEl/ftR 4Kdt89OIQABG5kZcHv07nVAiHnqBdJTjMd8yeOEqP6tDgiaZN1IZ7To4Du3rNFhtqfp5 2tRfd9KQ8fk5b8z/CYt+GQQ7f44mroAyFrecbIYKouYLqq4i3hqgGsqzFPnBC9K3aQE+ Bsig== X-Gm-Message-State: ALoCoQm9Y++v/N6cKNgWLdhhGGaoSG8RU83iBgPuE12fqQAJq3C/scjQIN077s7Nfb2PgIAlPbXr X-Received: by 10.194.6.8 with SMTP id w8mr32157967wjw.16.1392243877645; Wed, 12 Feb 2014 14:24:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.241.168 with HTTP; Wed, 12 Feb 2014 14:24:17 -0800 (PST) From: Pierre Carrier Date: Wed, 12 Feb 2014 14:24:17 -0800 Message-ID: Subject: freeradius denial of service in authentication flow To: security@freeradius.org, secalert , security@debian.org, security@ubuntu.com, pupykin.s+arch@gmail.com, pkgsrc-security , bugbusters , product.security@airbnb.com Content-Type: text/plain; charset=UTF-8 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: Wed, 12 Feb 2014 22:55:07 -0000 Hello, When freeradius verifies a password sent via RLM-PAP against an LDAP server, some passwords will cause a stack overflow. Some forms of SSHA, including forms that would be validated by servers applying standard constraints on the user's password attribute, will generate lengths over 64 bytes after hex-decoding. This can lead to such backtraces (observed with 2.1.10+dfsg-3ubuntu0.12.04.1, confirmed to be problematic upstream): Program terminated with signal 6, Aborted. #0 0x00007f3f4e682425 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007f3f4e682425 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f3f4e685b8b in __GI_abort () at abort.c:91 #2 0x00007f3f4e6c039e in __libc_message (do_abort=2, fmt=0x7f3f4e7c857f "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:201 #3 0x00007f3f4e756f47 in __GI___fortify_fail (msg=0x7f3f4e7c8567 "stack smashing detected") at fortify_fail.c:32 #4 0x00007f3f4e756f10 in __stack_chk_fail () at stack_chk_fail.c:29 #5 0x00007f3f4a103732 in normify (request=0x7f3f44001db0, vp=0x7f3f440179a0, min_length=20) at rlm_pap.c:281 #6 0x00007f3f4a1037fa in pap_authorize (instance=0xce9160, request=0x6366306464353863) at rlm_pap.c:404 #7 0x000000000041baed in call_modsingle (request=0x7f3f44001db0, component=1, sp=) at modcall.c:297 #8 modcall (component=1, c=0xd529d0, request=) at modcall.c:670 #9 0x000000000041aa48 in indexed_modcall (comp=1, idx=0, request=0x7f3f44001db0) at modules.c:728 #10 0x0000000000409d96 in rad_authenticate (request=0x7f3f44001db0) at auth.c:567 #11 0x00007f3f43182ef6 in eapttls_process (handler=, tls_session=0x7f3f44002c80) at ttls.c:1184 #12 0x00007f3f43181614 in eapttls_authenticate (arg=0xd44930, handler=0x7f3f44016010) at rlm_eap_ttls.c:269 #13 0x00007f3f48087d0c in eaptype_call (atype=0xd4c750, handler=0x7f3f44016010) at eap.c:175 #14 0x00007f3f4808811d in eaptype_select (inst=0xd26e50, handler=) at eap.c:409 #15 0x00007f3f4808776b in eap_authenticate (request=0xd5e400, instance=0xd26e50) at rlm_eap.c:319 #16 eap_authenticate (instance=0xd26e50, request=0xd5e400) at rlm_eap.c:281 #17 0x000000000041baed in call_modsingle (request=0xd5e400, component=0, sp=) at modcall.c:297 #18 modcall (component=0, c=0xd4bf80, request=) at modcall.c:670 #19 0x000000000041aa48 in indexed_modcall (comp=0, idx=220797, request=0xd5e400) at modules.c:728 #20 0x000000000040a2e9 in rad_check_password (request=0xd5e400) at auth.c:373 #21 rad_authenticate (request=0xd5e400) at auth.c:653 #22 0x000000000042810e in radius_handle_request (request=0xd5e400, fun=0x409aa0 ) at event.c:3776 #23 0x000000000041f6b1 in request_handler_thread (arg=0xd5d970) at threads.c:525 #24 0x00007f3f4f231e9a in start_thread (arg=0x7f3f41372700) at pthread_create.c:308 #25 0x00007f3f4e7403fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #26 0x0000000000000000 in ?? () Terrible hotfix quickly packaged to avoid constant crashes here, does not address the vulnerability: --- freeradius-2.1.10+dfsg.orig/src/modules/rlm_pap/rlm_pap.c +++ freeradius-2.1.10+dfsg/src/modules/rlm_pap/rlm_pap.c @@ -244,7 +244,7 @@ static void normify(REQUEST *request, VALUE_PAIR *vp, size_t min_length) { size_t decoded; - uint8_t buffer[64]; + uint8_t buffer[4096]; if (min_length >= sizeof(buffer)) return; /* paranoia */ On environments where such an issue did not arise previously, a user allowed to provide *validated* SSHA values to their LDAP servers can easily trigger denial of services, as the freeradius server will crash on every authentication attempt. This E-mail is sent to the current upstream maintainer and vendors distributing a package/port. Best, -- Pierre Carrier Site Reliability Engineer, Airbnb From owner-freebsd-bugbusters@FreeBSD.ORG Thu Feb 13 01:07:46 2014 Return-Path: Delivered-To: bugbusters@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CE49D2F for ; Thu, 13 Feb 2014 01:07:46 +0000 (UTC) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by mx1.freebsd.org (Postfix) with ESMTP id 476731204 for ; Thu, 13 Feb 2014 01:07:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7415C2240165; Thu, 13 Feb 2014 02:00:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTsWu2jwZkVK; Thu, 13 Feb 2014 02:00:07 +0100 (CET) Received: from Thor.local (unknown [70.50.217.206]) by power.freeradius.org (Postfix) with ESMTPSA id A73762240159; Thu, 13 Feb 2014 02:00:06 +0100 (CET) Message-ID: <52FC1916.4060501@freeradius.org> Date: Wed, 12 Feb 2014 20:00:06 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pierre Carrier Subject: Re: freeradius denial of service in authentication flow References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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:07:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pierre Carrier wrote: > Some forms of SSHA, including forms that would be validated by servers > applying standard constraints on the user's password attribute, will > generate lengths over 64 bytes after hex-decoding. 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. What, exactly, is going wrong? > Terrible hotfix quickly packaged to avoid constant crashes here, does > not address the vulnerability: > > --- freeradius-2.1.10+dfsg.orig/src/modules/rlm_pap/rlm_pap.c > +++ freeradius-2.1.10+dfsg/src/modules/rlm_pap/rlm_pap.c > @@ -244,7 +244,7 @@ > static void normify(REQUEST *request, VALUE_PAIR *vp, size_t min_length) > { > size_t decoded; > - uint8_t buffer[64]; > + uint8_t buffer[4096]; 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. I'd like to reproduce this, and come up with a definitive fix for the problem. I'd need examples of SSHA passwords to be sure. > On environments where such an issue did not arise previously, a user > allowed to provide *validated* SSHA values to their LDAP servers can > easily trigger denial of services, as the freeradius server will crash > on every authentication attempt. That's an issue, but a rare one IMHO. The user has to exist on the system. So this isn't a remote DoS. Alan DeKok. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBUvwZFqkul4vkAkl9AQJohgQAmAw3IbPAuA0DprpviCPiOMtJ+DTQZ8i8 FrBlXOIoAYU2f7Li4M8PSDizvrGaKIoXtwoMbLiJKfTWobWroOu8Ew1Yu+rKDbQG 4dMT7KoOaEky79A4kNGsbjAObny7G5+ckxaVxfNE+r2DyrWHyOPfqbKtb/PO0NrC JVyo0LHuFP4= =q9tL -----END PGP SIGNATURE----- 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 From owner-freebsd-bugbusters@FreeBSD.ORG Thu Feb 13 06:40:14 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 62E8BFE1 for ; Thu, 13 Feb 2014 06:40:14 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx1.freebsd.org (Postfix) with ESMTP id 07FF21FC8 for ; Thu, 13 Feb 2014 06:40:14 +0000 (UTC) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1D61MlX006544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Feb 2014 01:01:22 -0500 Received: from rt4.app.eng.rdu2.redhat.com (rt4.app.eng.rdu2.redhat.com [10.10.161.56]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1D61Lwu000565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 01:01:21 -0500 Received: from rt4.app.eng.rdu2.redhat.com (localhost [127.0.0.1]) by rt4.app.eng.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id s1D61LmB025646; Thu, 13 Feb 2014 01:01:21 -0500 Received: (from apache@localhost) by rt4.app.eng.rdu2.redhat.com (8.14.4/8.14.4/Submit) id s1D61K0Z025644; Thu, 13 Feb 2014 01:01:20 -0500 From: Red Hat Security Response Team Sender: secalert@redhat.com X-PGP-Public-Key: https://www.redhat.com/security/650d5882.txt Subject: [engineering.redhat.com #278019] Insufficient salting in the net-ldap Ruby gem In-Reply-To: References: Message-ID: Precedence: bulk X-RT-Loop-Prevention: engineering.redhat.com RT-Ticket: engineering.redhat.com #278019 Managed-BY: RT 4.0.13 (http://www.bestpractical.com/rt/) RT-Originator: kseifried@redhat.com To: pierre.carrier@airbnb.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 13 Feb 2014 01:01:20 -0500 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: bugbusters@freebsd.org, product.security@airbnb.com, pkgsrc-security@netbsd.org, rory@berecruited.com X-BeenThere: freebsd-bugbusters@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: secalert@redhat.com 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 06:40:14 -0000 On Wed Feb 12 15:03:04 2014, pierre.carrier@airbnb.com wrote: > Hello, > > SSHA passwords generated by the net-ldap Ruby gem use a salt between > "0" and "999", only providing 10 bits of entropy. > > This is an attack vector, making attacks based on rainbow tables > significantly easier than with a strong salt. Thanks for sending this. >From the CVE perspective this is a classic "intended security protection that fails to work as intended", the point of salting is to increase workload enough to make pre-computation and storage of the results difficult to impossible, a factor of 1000 is simply not enough in the modern word of GPU's and 4TB hd's and rainbow tables with chains. Please use CVE-2014-0083 for this issue. Also can an issue be opened upstream if it hasn't already been done? Thanks. > https://github.com/ruby-ldap/ruby-net- > ldap/blob/master/lib/net/ldap/password.rb#L29 > > This E-mail is sent to the current upstream maintainer and all vendors > that distribute a version of that gem. > Your version might not be affected; if not, sorry for the noise. > > Best, > -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 From owner-freebsd-bugbusters@FreeBSD.ORG Thu Feb 13 07:11:12 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 8EB055AF for ; Thu, 13 Feb 2014 07:11:12 +0000 (UTC) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24F881232 for ; Thu, 13 Feb 2014 07:11:11 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id f8so8118253wiw.7 for ; Wed, 12 Feb 2014 23:11:09 -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=ALWIujdcQlRXRe/lVqSzgqzrKyK8Gsb8KXdTZ9ZL49c=; b=FvCfuacirKGxK9G6tylJAgkHhNe/KT/ialo95yhIju35W3DldQE7uBlXq/9tKCLbsP pzlikPCCbmzZtCf+CRTUOWuCTfq4ql0gWsBUu64bd8p6WTUHjs1oB1EjaMZemrzAHN4t RmHk+wWKTGgwzBJaJ+PTskjN+Cw5ZI4xAts4Qc3YGyFxDK8lsYRP8mKpkk0ohdniFddg 12UwIKaLTfrErq/6t/IbY3Whmux9yQAlT8VvCGbAgAfPigTt7rWL6n+u2MBGF657Xbuu JSMi/5N4q87xHu9KS9N1kFP8PDKEPYCe1htk7JnyfQ8HrNBqzEGzHdK4k0lKFgXffEHQ kzKQ== X-Gm-Message-State: ALoCoQmKE7TVZGYMT9WHm1byrgdi3o0NwUUPd2N6H7y0sermP6MIimdTSrMs/sGxuROvLtNYBg0O X-Received: by 10.194.108.41 with SMTP id hh9mr20577wjb.89.1392275469670; Wed, 12 Feb 2014 23:11:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.241.168 with HTTP; Wed, 12 Feb 2014 23:10:49 -0800 (PST) In-Reply-To: References: From: Pierre Carrier Date: Wed, 12 Feb 2014 23:10:49 -0800 Message-ID: Subject: Re: [engineering.redhat.com #278019] Insufficient salting in the net-ldap Ruby gem To: secalert Content-Type: text/plain; charset=UTF-8 Cc: bugbusters , product.security@airbnb.com, pkgsrc-security , Rory O'Connell 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 07:11:12 -0000 On Wed, Feb 12, 2014 at 10:01 PM, Red Hat Security Response Team wrote: > Please use CVE-2014-0083 for this issue. Also can an issue be opened upstream if it hasn't already been done? Thanks. My understanding from a naive search is that the current active project is github.com/ruby-ldap/ruby-net-ldap, and rory@berecruited.com has been merging all pull requests there in recent times, so I included them in the original email as the presumed current upstream. -- Pierre From owner-freebsd-bugbusters@FreeBSD.ORG Thu Feb 13 16:44:58 2014 Return-Path: Delivered-To: bugbusters@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 699FB274 for ; Thu, 13 Feb 2014 16:44:58 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1CF211829 for ; Thu, 13 Feb 2014 16:44:58 +0000 (UTC) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1DGiqiI023978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Feb 2014 11:44:52 -0500 Received: from rt4.app.eng.rdu2.redhat.com (rt4.app.eng.rdu2.redhat.com [10.10.161.56]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1DGiqeo026350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 11:44:52 -0500 Received: from rt4.app.eng.rdu2.redhat.com (localhost [127.0.0.1]) by rt4.app.eng.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id s1DGipn8009552; Thu, 13 Feb 2014 11:44:51 -0500 Received: (from apache@localhost) by rt4.app.eng.rdu2.redhat.com (8.14.4/8.14.4/Submit) id s1DGin0J009551; Thu, 13 Feb 2014 11:44:49 -0500 From: Red Hat Security Response Team Sender: secalert@redhat.com X-PGP-Public-Key: https://www.redhat.com/security/650d5882.txt Subject: [engineering.redhat.com #278019] Insufficient salting in the net-ldap Ruby gem In-Reply-To: References: Message-ID: Precedence: bulk X-RT-Loop-Prevention: engineering.redhat.com RT-Ticket: engineering.redhat.com #278019 Managed-BY: RT 4.0.13 (http://www.bestpractical.com/rt/) RT-Originator: kseifried@redhat.com To: pierre.carrier@airbnb.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 13 Feb 2014 11:44:49 -0500 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: bugbusters@freebsd.org, product.security@airbnb.com, pkgsrc-security@netbsd.org, rory@berecruited.com X-BeenThere: freebsd-bugbusters@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: secalert@redhat.com 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 16:44:58 -0000 On Thu Feb 13 00:11:15 2014, pierre.carrier@airbnb.com wrote: > On Wed, Feb 12, 2014 at 10:01 PM, Red Hat Security Response Team > wrote: > > Please use CVE-2014-0083 for this issue. Also can an issue be opened > upstream if it hasn't already been done? Thanks. > > My understanding from a naive search is that the current active > project is github.com/ruby-ldap/ruby-net-ldap, and > rory@berecruited.com has been merging all pull requests there in > recent times, so I included them in the original email as the presumed > current upstream. > Excellent, thanks. Also can someone post this to oss-security? I suspect quite a few people are using this gem. If needed I can do the posting. -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 From owner-freebsd-bugbusters@FreeBSD.ORG Fri Feb 14 19:53:11 2014 Return-Path: Delivered-To: bugbusters@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F084AD2D for ; Fri, 14 Feb 2014 19:53:10 +0000 (UTC) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by mx1.freebsd.org (Postfix) with ESMTP id AC98B1020 for ; Fri, 14 Feb 2014 19:53:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2C37722404A8; Fri, 14 Feb 2014 20:52:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6MN9KkrNUXv; Fri, 14 Feb 2014 20:52:32 +0100 (CET) Received: from Thor.local (unknown [70.50.217.206]) by power.freeradius.org (Postfix) with ESMTPSA id 9CDF922401D3; Fri, 14 Feb 2014 20:52:31 +0100 (CET) Message-ID: <52FE7400.4000808@freeradius.org> Date: Fri, 14 Feb 2014 14:52:32 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pierre Carrier Subject: Re: freeradius denial of service in authentication flow References: <52FC1916.4060501@freeradius.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Fri, 14 Feb 2014 19:53:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pierre Carrier wrote: > 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. OK. We've pushed changes to the v2.x.x, v3.0.x, and master branches. See commit 0d606cfc29a in the v2.x.x branch, and ff5147c9e5088c7 in v3.0.x. The "master" branch doesn't have an official release, so downstream users don't need to do anything for it. > Indeed, it is not a remote DoS, and I agree the practical implications > aren't too scary. Yes. > 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. And would be discovered pretty quickly. Alan DeKok. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBUv50AKkul4vkAkl9AQLP4QQAl+cnsN0DP1vZM2NHBGE9rl95m2RPBHJJ GxZQLePweYkFCP1urAqoGkyiKs6AclGysGyxzJFj1EVw9mBBKkR+CxsKs3Wyqyku w7zG57khJjf7HZdsn7ztnzJmx4SEygcfD1dEr+yjY/+ePt5fxOPUv2EHz7ouTRVM 2Y3PtVajBkc= =egp6 -----END PGP SIGNATURE----- From owner-freebsd-bugbusters@FreeBSD.ORG Sat Feb 15 20:46: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 E741689E for ; Sat, 15 Feb 2014 20:46:41 +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 A173B180C for ; Sat, 15 Feb 2014 20:46:41 +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 1WEldH-0008L6-Ht; Sat, 15 Feb 2014 21:14:39 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1WEldH-0000FD-Cy; Sat, 15 Feb 2014 21:14:39 +0100 From: Florian Weimer To: Alan DeKok Subject: Re: freeradius denial of service in authentication flow References: <52FC1916.4060501@freeradius.org> Date: Sat, 15 Feb 2014 21:14:39 +0100 In-Reply-To: <52FC1916.4060501@freeradius.org> (Alan DeKok's message of "Wed, 12 Feb 2014 20:00:06 -0500") Message-ID: <87sirkm8uo.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 15 Feb 2014 21:01:21 +0000 Cc: Pierre Carrier , 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: Sat, 15 Feb 2014 20:46:42 -0000 * 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? Florian (Debian security team)