From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 02:20:26 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36493106566B for ; Sun, 10 Jun 2012 02:20:26 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E5BA78FC08 for ; Sun, 10 Jun 2012 02:20:25 +0000 (UTC) Received: by obcni5 with SMTP id ni5so5976951obc.13 for ; Sat, 09 Jun 2012 19:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QN+5bacaKlRvvBCpBNy2WwrOLFS58Wxwjm1kox7y1Iw=; b=Usklme/1GfIQ9bGHYtczuDvQss//3f1HHH550PJZvoZE8euJU0zU/AaYpfuo2bUCmE NPhuOl+dnT9XS74d6W9piUhh+4dqRlLxuuaR4j5PhUausQtFaCV4eF50Mtya2iUbvmYL aJj5WS6wAg1ZVz9T5gM8F+VWzFFPyxjwC8v+Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=QN+5bacaKlRvvBCpBNy2WwrOLFS58Wxwjm1kox7y1Iw=; b=R4i4HQ1Y3BAdup5jikj5q0Z0vi3sVkXY5MN+a0Wzn4r5nxhw/j68xk+P4pFiBQCztT NQR403dDy1w5rn01IML01/k3ftcgIFPUp6moxLUD496lc14PwvgA4DY5nkUKT+cnsaSW HOpm1IVl4SWquUq8FujAeW+17kEaQXxRbjd6g6zPGLLIA2DkcOLcRhrbffb5lbUsjYqD jarJJa7eyI5WnMZ0LewOFEjSr/Ol6sGAHJspzJUKesgyiWOZ/G3qCYEaxxsXJfB2+bTV i5VX+OnCxXr7a1MqH4kuTGNAJZvMkUBceeHyUTGBwrRCBc6MnZRLtGDpjkqYk8n6CD6G RjAA== Received: by 10.182.2.193 with SMTP id 1mr12088796obw.46.1339294825309; Sat, 09 Jun 2012 19:20:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.204.69 with HTTP; Sat, 9 Jun 2012 19:19:55 -0700 (PDT) In-Reply-To: References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> <4FD350EF.6080802@sentex.net> From: Eitan Adler Date: Sat, 9 Jun 2012 19:19:55 -0700 Message-ID: To: Robert Simmons Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlZ8ZyBd9wuURBqEHkBdeJ/TJuvhHz36i5R9Vb8t4E+0pnskWlX6ndNM983rhbDJIj0PBH9 Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 02:20:26 -0000 On 9 June 2012 13:16, Robert Simmons wrote: > On Sat, Jun 9, 2012 at 9:34 AM, Mike Tancsa wrote: >> On 6/9/2012 9:19 AM, someone wrote: >>> hi, >>> >>> what is needed to change from md5 to sha512 ? As all old passwd are md5, I imagine there is a >>> sequence of steps not to lock me out of the box. is there any place that documents this ? >> change the users passwd to something new, or just use the old passwd, >> but re-enter it change the default format and run passwd. The password will transparently change. -- Eitan Adler From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 06:55:21 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DC6B106564A for ; Sun, 10 Jun 2012 06:55:21 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 103B88FC0C for ; Sun, 10 Jun 2012 06:55:21 +0000 (UTC) Received: from delta.delphij.net (unknown [IPv6:2001:470:83bf:0:221:5cff:fe6a:37bb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id D70E9FDC6; Sat, 9 Jun 2012 23:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1339311315; bh=GpHO4E4Bc50CuuqOmhYgqOis8MBPoeRfVw8hoz/4WGs=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=N3AW2W5pZxMLQVaax+BY+x14kZk9+gSuwPyAQiYUQw7qUnfLQl6rqwABJuPnCQx0Z 4p+UKFpNVazJUX3xTifu89BUVWJ+IpHrRMbkRtug7LMYpqypaC430vJhBTy8xytTk4 tHV3oqUHH00NC3U3uNiCgwrt839C7Mque6jMOi00= Message-ID: <4FD444C5.9080701@delphij.net> Date: Sat, 09 Jun 2012 23:55:01 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Mike Tancsa References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> In-Reply-To: <4FD334BE.4020900@sentex.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , d@delphij.net, freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 06:55:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/09/12 04:34, Mike Tancsa wrote: > On 6/8/2012 8:51 AM, Dag-Erling Smørgrav wrote: >> We still have MD5 as our default password hash, even though >> known-hash attacks against MD5 are relatively easy these days. >> We've supported SHA256 and SHA512 for many years now, so how >> about making SHA512 the default instead of MD5, like on most >> Linux distributions? > > Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ? Its > currently not there. Ping me next Friday if nobody else would volunteer. > RELENG_7 is supported until 2013 > > Sort of a security issue considering this assessment of MD5 > > http://phk.freebsd.dk/sagas/md5crypt_eol.html > > > ---Mike > > > >> >> Index: etc/login.conf >> =================================================================== >> >> - --- etc/login.conf (revision 236616) >> +++ etc/login.conf (working copy) @@ -23,7 +23,7 @@ # AND >> SEMANTICS'' section of getcap(3) for more escape sequences). >> >> default:\ - :passwd_format=md5:\ + >> :passwd_format=sha512:\ :copyright=/etc/COPYRIGHT:\ >> :welcome=/etc/motd:\ >> :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\ >> >> DES > > - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP1ETFAAoJEG80Jeu8UPuzRWAH/3XDen0pxNpYDqRxfAiTKJjI A0JqyNrVMMA3/ncenceODJs+7BugXRWnC5jyAzfxC5KulL1ZcBZCfYApdWgJ+Lun yHnv/JryEK2InzGwuDX/P3Tt1TZVKtr5drs7yJuZnRaW5SWRRaPRvLqgGZ1PdNxb /cHIXL+DPxHUXhwBcInhWWImNDJU3xEcvFQSpW4C8iqGqviFLE0WlhKTGVvnwiMO lXTnyyadQMrMQW8XIgcgyNZ5b3asiTAC1TOXtaTWiFR2QPgfxZSvEoaxu/AMmep3 HegMWA0qXXCvj7E0xUECRs3tXG6hbxhaRJima8FdPeCLWcNtd12PC44xj+EuufQ= =7wMd -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 09:52:06 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A08D1106566C; Sun, 10 Jun 2012 09:52:06 +0000 (UTC) (envelope-from simon@FreeBSD.org) Received: from emx.nitro.dk (emx.nitro.dk [IPv6:2a01:4f8:120:7384::102]) by mx1.freebsd.org (Postfix) with ESMTP id 31ED78FC12; Sun, 10 Jun 2012 09:52:06 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id 5B697252964; Sun, 10 Jun 2012 09:52:05 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id GOjNNcuJ_gDS; Sun, 10 Jun 2012 09:52:03 +0000 (UTC) Received: from [192.168.4.24] (unknown [46.7.100.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id 4BA14252962; Sun, 10 Jun 2012 09:52:03 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Simon L. B. Nielsen" In-Reply-To: <20120609085141.GA1153@reks> Date: Sun, 10 Jun 2012 10:52:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75AEDB7C-6246-4F01-AC6B-5521114F3205@FreeBSD.org> References: <20120531194825.GB1400@garage.freebsd.pl> <20120609085141.GA1153@reks> To: Gleb Kurtsou X-Mailer: Apple Mail (2.1278) Cc: freebsd-security@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: OpenSSL change for review. X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 09:52:06 -0000 On 9 Jun 2012, at 09:51, Gleb Kurtsou wrote: > On (31/05/2012 21:48), Pawel Jakub Dawidek wrote: >> As learned on someone else's mistakes, I'd like to ask for a review = of >> those changes related to random data handling: >>=20 >> http://people.freebsd.org/~pjd/patches/libc_arc4random.c.patch >> http://people.freebsd.org/~pjd/patches/openssl_rand_unix.c.patch >>=20 >> The first patch changes arc4random() to use sysctl to obtain random = data >> instead of opening /dev/random. The main reason here is to make it = more >> sandbox-friendly. Once closed in sandbox, a process can no longer = open >> files, so it has no access to proper random data. As a side-effect it >> should be a bit faster as instead of three system calls (open, read = and >> close) we use only one (__sysctl). >>=20 >> The second patch enables the use of libc's arc4random(3) in OpenSSL. >=20 > While at it, did you consider replacing default homegrown OpenSSL = random > generator (ssleay_rand_*) with something standard (this "hash > uninitialized user buffer to increase entropy" thing makes me nervous, > which was also the source of well known Debian RSA key generation = issue). Changing the random number generator without having it coming from = upstream makes me even more nervous, but I agree with your general = point. > There is standard (ANSI X9.31 A.2.4) AES-based implementation under > openssl/fips/rand. Replacing fips_get_dt with our arc4random_buf() = looks > straightforward. It may be performance improvement as well, = considering > both OpenSSL and hardware support AESNI. Or simply replace the whole > thing with arc4random_*.. If somebody is interested in doing things along these lines, I strongly = suggest trying to rope in some OpenSSL people, e.g. benl@. > Patches are good to commit, IMHO. Thanks for giving the patch more eyes. --=20 Simon L. B. Nielsen From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 10:02:51 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 256111065673 for ; Sun, 10 Jun 2012 10:02:51 +0000 (UTC) (envelope-from simon@FreeBSD.org) Received: from emx.nitro.dk (emx.nitro.dk [IPv6:2a01:4f8:120:7384::102]) by mx1.freebsd.org (Postfix) with ESMTP id D631E8FC0C for ; Sun, 10 Jun 2012 10:02:50 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id 383EB252A80; Sun, 10 Jun 2012 10:02:50 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id u-l8NUlx34_b; Sun, 10 Jun 2012 10:02:48 +0000 (UTC) Received: from [192.168.4.24] (unknown [46.7.100.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id 79292252A7E; Sun, 10 Jun 2012 10:02:48 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Simon L. B. Nielsen" In-Reply-To: <86r4tqotjo.fsf@ds4.des.no> Date: Sun, 10 Jun 2012 11:02:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> References: <86r4tqotjo.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1278) Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 10:02:51 -0000 On 8 Jun 2012, at 13:51, Dag-Erling Sm=F8rgrav wrote: > We still have MD5 as our default password hash, even though known-hash > attacks against MD5 are relatively easy these days. We've supported > SHA256 and SHA512 for many years now, so how about making SHA512 the > default instead of MD5, like on most Linux distributions? Has anyone looked at how long the SHA512 password hashing actually takes = on modern computers? The "real" solution for people who care significantly about this seems = something like the algorithm pjd implemented (I think he did it at = least) for GELI, where the number of rounds is variable and calculated = so it takes X/0.X seconds on the specific hardware used. That's of = course a lot more complicated, and I'm not sure if it would work with = the crypt() API. Also, does anyone know if our SHA512 is compatible with the format used = by Linux, other BSD's etc? --=20 Simon L. B. Nielsen From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 14:54:01 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39F7F106566B; Sun, 10 Jun 2012 14:54:01 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF388FC0C; Sun, 10 Jun 2012 14:54:00 +0000 (UTC) Received: by laai10 with SMTP id i10so2673004laa.13 for ; Sun, 10 Jun 2012 07:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=a/i5kY3jZG91Tabit+/NNIYs3KZd8ohgVo1j9qWfEZU=; b=hP8eqhqkKjJQf8OUo3PI8rowDetqSaW+LXNKjwVkZ/JYsR34/tKSvGTpODjXBc32Rp gGcIXymTAytKRqJmKqKr0UOG11zLUVx25wQJO9GOSCpoV87WiOCm0uO2wfonrWkqWdeX x+NKAnADO1SZWHCWK/8zdv0eYR9uJq+1UR+98+rakpRhIvzatqyfTt1KsRgdEIz1U9N8 kaNsTmjhOTVo+Pc5a+ysTtlTOoq2nrVcbkxIcRiHD5j0x/OykWlwqfrzB4adHGOzrhs3 +w2LS87SY6iejcuvlgCD6v82fE4V5F+v4xeB+l+iAjP4s72AXmVRNVaBNhNEfPerpgnx RCww== Received: by 10.112.46.166 with SMTP id w6mr1968668lbm.100.1339340039209; Sun, 10 Jun 2012 07:53:59 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id fd1sm7146032lbb.7.2012.06.10.07.53.56 (version=SSLv3 cipher=OTHER); Sun, 10 Jun 2012 07:53:57 -0700 (PDT) Date: Sun, 10 Jun 2012 17:53:51 +0300 From: Gleb Kurtsou To: "Simon L. B. Nielsen" Message-ID: <20120610145351.GA1098@reks> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 14:54:01 -0000 On (10/06/2012 11:02), Simon L. B. Nielsen wrote: > > On 8 Jun 2012, at 13:51, Dag-Erling Smørgrav wrote: > > > We still have MD5 as our default password hash, even though known-hash > > attacks against MD5 are relatively easy these days. We've supported > > SHA256 and SHA512 for many years now, so how about making SHA512 the > > default instead of MD5, like on most Linux distributions? > > Has anyone looked at how long the SHA512 password hashing actually takes on modern computers? > > The "real" solution for people who care significantly about this seems something like the algorithm pjd implemented (I think he did it at least) for GELI, where the number of rounds is variable and calculated so it takes X/0.X seconds on the specific hardware used. That's of course a lot more complicated, and I'm not sure if it would work with the crypt() API. Do you mean pkcs5v2_calculate from geli? It seems to have a drawback that results produced depend on actual CPU load. % ./pkcs5v-test [*] 541491 539568 542352 540376 388285 -- start several instances of pkcs5v-test in parallel 303071 284793 281110 It would be awesome to provide user with options to configure minimal and maximal iteration count and randomly choose iteration count within the range for each new password. Such trivial change should considerably complicate mass password bruteforce cracking. Variable number of rounds for a password would also require changing crypt() interface. > Also, does anyone know if our SHA512 is compatible with the format used by Linux, other BSD's etc? It's supposed to be compatible with Linux. DragonFly invented something on their own with a nasty bug in it. They could have changed to "standard" crypt on top of sha-2 after bug was discovered. http://www.openwall.com/lists/oss-security/2012/01/16/2 Why does nobody mention scrypt? It looks very attractive in longer perspective. Thanks, Gleb. * pkcs5v-test.c: #include int main(int argc, char **argv) { int i, usec; for (i = 0; i < 10; i++) { usec = pkcs5v2_calculate(2000000, 512 / 8, 4); printf("%d\n", usec); } return (0); } From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 17:47:04 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41B831065670; Sun, 10 Jun 2012 17:47:04 +0000 (UTC) (envelope-from dweber@htw-saarland.de) Received: from theia.rz.uni-saarland.de (theia.rz.uni-saarland.de [134.96.7.31]) by mx1.freebsd.org (Postfix) with ESMTP id C0E0A8FC14; Sun, 10 Jun 2012 17:47:03 +0000 (UTC) Received: from itz-mail.htw-saarland.de (itz-mail.htw-saarland.de [134.96.210.141]) by theia.rz.uni-saarland.de (8.14.1/8.14.0) with ESMTP id q5AGtN37015481; Sun, 10 Jun 2012 18:55:23 +0200 Received: from magritte.htw-saarland.de (magritte.htw-saarland.de [134.96.216.98]) by itz-mail.htw-saarland.de (8.14.5/8.14.5) with ESMTP id q5AGtMWB007150; Sun, 10 Jun 2012 18:55:22 +0200 (CEST) Date: Sun, 10 Jun 2012 18:55:18 +0200 (CEST) From: Damian Weber To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <20120610145351.GA1098@reks> Message-ID: References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <20120610145351.GA1098@reks> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2065465572-899095623-1339347323=:2189" X-Virus-Scanned: clamav-milter 0.97.3 at itz-mail X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (theia.rz.uni-saarland.de [134.96.7.31]); Sun, 10 Jun 2012 18:55:23 +0200 (CEST) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-14; AVE: 7.9.10.68; VDF: 7.11.32.116; host: AntiVir1) Cc: freebsd-security@freebsd.org, Gleb Kurtsou , "Simon L. B. Nielsen" Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 17:47:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2065465572-899095623-1339347323=:2189 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT > On 8 Jun 2012, at 13:51, Dag-Erling Smrgrav wrote: > > > We still have MD5 as our default password hash, even though known-hash > > attacks against MD5 are relatively easy these days. *collision* attacks are relatively easy these days, but against 1 MD5, not against 1000 times MD5 w.r.t. password hashes, a successful preimage attack would be threatening, which publications are you referring to? I found one preimage attack on reduced MD5, but it's theoretical (2^96 steps) "Preimage Attacks on 3-Pass HAVAL and Step-Reduced MD5*" eprint.iacr.org/2008/183.pdf > > We've supported > > SHA256 and SHA512 for many years now, so how about making SHA512 the > > default instead of MD5, like on most Linux distributions? there is a NIST hash competition running, the winner will soon be announced (and it won't be SHA256 or SHA512 ;-) http://csrc.nist.gov/groups/ST/hash/timeline.html so my suggestion would be to use all of the finalists - especially the winner - for password hashing * BLAKE * Grstl * JH * Keccak * Skein see, for example, http://www.nist.gov/itl/csd/sha3_010511.cfm -- Damian Weber, --2065465572-899095623-1339347323=:2189-- From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 20:13:51 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93E291065673 for ; Sun, 10 Jun 2012 20:13:51 +0000 (UTC) (envelope-from piechota@argolis.org) Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) by mx1.freebsd.org (Postfix) with ESMTP id 726AB8FC26 for ; Sun, 10 Jun 2012 20:13:51 +0000 (UTC) Received: from [192.168.1.4] ([unknown] [98.114.37.117]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M5F00MSS1ED0J82@vms173013.mailsrvcs.net> for freebsd-security@freebsd.org; Sun, 10 Jun 2012 14:13:25 -0500 (CDT) Message-id: <4FD4F1D5.9090900@argolis.org> Date: Sun, 10 Jun 2012 15:13:25 -0400 From: Matt Piechota User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-version: 1.0 To: freebsd-security@freebsd.org References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> In-reply-to: <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 20:13:51 -0000 On 06/10/2012 06:02 AM, Simon L. B. Nielsen wrote: > Has anyone looked at how long the SHA512 password hashing actually > takes on modern computers? The "real" solution for people who care > significantly about this seems something like the algorithm pjd > implemented (I think he did it at least) for GELI, where the number of > rounds is variable and calculated so it takes X/0.X seconds on the > specific hardware used. That's of course a lot more complicated, and > I'm not sure if it would work with the crypt() API. I'm kinda curious about this: I take it you'd encode the number of rounds in the string somehow? Otherwise, the hash wouldn't be portable to another machine (or even if you upgrade the current machine). -- Matt Piechota From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 22:26:41 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6DAA106564A for ; Sun, 10 Jun 2012 22:26:41 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id A17138FC0C for ; Sun, 10 Jun 2012 22:26:41 +0000 (UTC) Received: by ghbz22 with SMTP id z22so2376498ghb.13 for ; Sun, 10 Jun 2012 15:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KB9c3brSaXcL4Q0fPpQNAaPLa/gAa/wbiuvnkQg1/Mw=; b=tKvw+r8JiDDmAppvYkuAIIJDgtMd0pZvJFM9RwHYHAxNWzeozoQIkGCIvj+8HVb+/b IYR93yL6LVq/VwMIupCPa24l+coNfxwzN9lnUWNIqrP4nCrQ9/EPUPsdTiR46/CS/TUe 4aZjYoisU/KaN6pJKMxKLYz4Y4oba0rgbQLHFDSRd3F3293BzGq6SrkzD40pFKvYGUi7 KWk4V/Go5XYDset9vMDuSVhkInhrKLbTSPv0iJ0oE/dk2IUIEYAPRij99j8wzxaVqYXP LCQRD+/IeryGVj4Yle7bE+Mpb/1WwK/6ph3FmK/1eam/P0ON8X3/SR7d2DjZDcmWkn2p nIVQ== MIME-Version: 1.0 Received: by 10.236.201.199 with SMTP id b47mr17640415yho.44.1339367195102; Sun, 10 Jun 2012 15:26:35 -0700 (PDT) Received: by 10.236.46.233 with HTTP; Sun, 10 Jun 2012 15:26:35 -0700 (PDT) In-Reply-To: <86r4tqotjo.fsf@ds4.des.no> References: <86r4tqotjo.fsf@ds4.des.no> Date: Mon, 11 Jun 2012 00:26:35 +0200 Message-ID: From: Oliver Pinter To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: [Re: Default password hash] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 22:26:42 -0000 On 6/8/12, Dag-Erling Sm=F8rgrav wrote: > We still have MD5 as our default password hash, even though known-hash > attacks against MD5 are relatively easy these days. We've supported > SHA256 and SHA512 for many years now, so how about making SHA512 the > default instead of MD5, like on most Linux distributions? > > Index: etc/login.conf > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- etc/login.conf (revision 236616) > +++ etc/login.conf (working copy) > @@ -23,7 +23,7 @@ > # AND SEMANTICS'' section of getcap(3) for more escape sequences). > > default:\ > - :passwd_format=3Dmd5:\ > + :passwd_format=3Dsha512:\ > :copyright=3D/etc/COPYRIGHT:\ > :welcome=3D/etc/motd:\ > :setenv=3DMAIL=3D/var/mail/$,BLOCKSIZE=3DK,FTP_PASSIVE_MODE=3DYES= :\ > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" > From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 22:37:31 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC184106566B for ; Sun, 10 Jun 2012 22:37:31 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78AC58FC18 for ; Sun, 10 Jun 2012 22:37:31 +0000 (UTC) Received: by yenl8 with SMTP id l8so2391487yen.13 for ; Sun, 10 Jun 2012 15:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EcdFM5sRwDfDC/lagI3v9gT0ROgeQolErVMpq51WlF8=; b=sX4wxT+soIlTZ4vtJJwMiONtWe0ZBrbzOaSVcEKaCnG1RpJHVwG3njPwddUzQwtE5d HQRCNoievCyCSXk1X7aFGpU1ucV3JLQo6Q1fFfETt/sRdG0ZQX1/I8q1cjE56tUW72Ed yhJ71ME2fVIYAZddhbBBKwfp3IARNDPsLuitnAka7z6jzFcrWELXTTq0PijxJ/G9k9Hq Krqvre2wcLCQJfQ7hCIF70e5WswND3QOOZFEleQ+c751dxIkueI+M0eknf9K8huG3g8w iUlwD4HNkmQ0E+RgjvH25pAf5LMeql+YPUaoX6x/E6n1odS6+mb//vZO7jtrtXgyFZwW QCWA== MIME-Version: 1.0 Received: by 10.236.181.199 with SMTP id l47mr17632085yhm.85.1339367850874; Sun, 10 Jun 2012 15:37:30 -0700 (PDT) Received: by 10.236.46.233 with HTTP; Sun, 10 Jun 2012 15:37:30 -0700 (PDT) Date: Mon, 11 Jun 2012 00:37:30 +0200 Message-ID: From: Oliver Pinter To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: blf uses only 2^4 round for passwd encoding?! [Re: Default password hash] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 22:37:31 -0000 http://svnweb.freebsd.org/base/head/secure/lib/libcrypt/crypt-blowfish.c?re= vision=3D231986&view=3Dmarkup 145 static const char *magic =3D "$2a$04$"; 146 147 /* Defaults */ 148 minr =3D 'a'; 149 logr =3D 4; 150 rounds =3D 1 << logr; 151 152 /* If it starts with the magic string, then skip that */ 153 if(!strncmp(salt, magic, strlen(magic))) { 154 salt +=3D strlen(magic); 155 } grep 04 /etc/master.passwd: root:$2a$04$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:0:0::0:0:= XXX:/root:/bin/csh xxxx:$2a$04$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:100X:100X= ::0:0:XXXXXXXXXXXXX:/home/xxxx:/bin/tcsh 16 rounds in 2012? It is not to weak?! On 6/8/12, Dag-Erling Sm=F8rgrav wrote: > We still have MD5 as our default password hash, even though known-hash > attacks against MD5 are relatively easy these days. We've supported > SHA256 and SHA512 for many years now, so how about making SHA512 the > default instead of MD5, like on most Linux distributions? > > Index: etc/login.conf > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- etc/login.conf (revision 236616) > +++ etc/login.conf (working copy) > @@ -23,7 +23,7 @@ > # AND SEMANTICS'' section of getcap(3) for more escape sequences). > > default:\ > - :passwd_format=3Dmd5:\ > + :passwd_format=3Dsha512:\ > :copyright=3D/etc/COPYRIGHT:\ > :welcome=3D/etc/motd:\ > :setenv=3DMAIL=3D/var/mail/$,BLOCKSIZE=3DK,FTP_PASSIVE_MODE=3DYES= :\ > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" > From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 23:24:09 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56F71065677 for ; Sun, 10 Jun 2012 23:24:09 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE478FC21 for ; Sun, 10 Jun 2012 23:24:09 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2605217wgb.31 for ; Sun, 10 Jun 2012 16:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=Q3+WYJYCayFWkafgbHghO9FAuym7c27ZvlO9ko1q8Tg=; b=bpAaLm72RUuhYAthFpPilHbpWgrK8X4q/nfSGkEAPw2cR95dr7UiSaXyrlLAiM7F68 aGwP0JH3xhM1dOfHYEKInd1Fu/LT2JM/J/5FVX/5/QhBNUucrHK+tjqx5k4AOY0uU4ar OTVhl0vjDhIxvvl5NZW+K+OXngrwpV3b/g9UTq9v4JTWEEC3rM8//ksHFSzDTPtDdc1p X0KeeXhH2LCBzywSoMWasXR6Ax0oydlPwdJYhzlAqaiokJ5zIrppzfRKHGsCnzepNKlH TDbJ5TXP6XirRMs5+tsI9WItzzZ9zc8kf0df3BW2KpLmRFROGWYGxzZNnUNzCWTgGkLe lGEw== Received: by 10.216.134.145 with SMTP id s17mr5204997wei.22.1339370645854; Sun, 10 Jun 2012 16:24:05 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id n6sm32185959wie.7.2012.06.10.16.24.04 (version=SSLv3 cipher=OTHER); Sun, 10 Jun 2012 16:24:05 -0700 (PDT) Date: Mon, 11 Jun 2012 00:24:02 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120611002402.088b2f74@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: blf uses only 2^4 round for passwd encoding?! [Re: Default password hash] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 23:24:10 -0000 On Mon, 11 Jun 2012 00:37:30 +0200 Oliver Pinter wrote: > 16 rounds in 2012? It is not to weak?! It's hard to say. Remember that blowfish was designed as a cipher not a hash. It's designed to be fast, but to still resist known plaintext attacks at the beginning of the ciphertext. It was also designed to work directly with a passphrase because there was a history of programmers abusing DES by using simple ascii passwords as keys. For these reasons initialization is deliberately expensive, effectively it already contains an element of passphrase hashing. From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 00:03:48 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93D88106566B for ; Mon, 11 Jun 2012 00:03:48 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5798FC08 for ; Mon, 11 Jun 2012 00:03:48 +0000 (UTC) Received: by ggnm2 with SMTP id m2so2406481ggn.13 for ; Sun, 10 Jun 2012 17:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uYroG0E91hlkpNKKNVMME+uWbuGO9Q7i50jhtKl/+sU=; b=xvXbubur3LN2SSbJL9aK6mtBtTrfyZhjDG953XrouYrR7btoXhw50HtxEMoFh8lX63 y9635YI+pSvjj6oEiKpWyhbQdejM/BaOUa4wLKmU7gilLN22zFVlu1q5ABXrmx93zk1/ OkKeDl5YR8TIeA5+MVto2yPI2BDkSYHXiE5CpTWqPft1ABmPchehXNIobAAYLj/WsRfe 4IwRAy9hNCel9DE2Gl+YE2zPWb1ho4Qv4++G6lb5AiIvaU5a4xJ5RX4QmLjHETgdM7XO uZxpM3Yiq8GxQ5BDQ2mJFamGerF3p48dijzpwj6xg5Z5CV1lUurGIAtQDiZcqd8iNEgi qOgg== MIME-Version: 1.0 Received: by 10.236.114.169 with SMTP id c29mr17880769yhh.108.1339373022469; Sun, 10 Jun 2012 17:03:42 -0700 (PDT) Received: by 10.236.46.233 with HTTP; Sun, 10 Jun 2012 17:03:42 -0700 (PDT) In-Reply-To: <20120611002402.088b2f74@gumby.homeunix.com> References: <20120611002402.088b2f74@gumby.homeunix.com> Date: Mon, 11 Jun 2012 02:03:42 +0200 Message-ID: From: Oliver Pinter To: RW Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org Subject: Re: blf uses only 2^4 round for passwd encoding?! [Re: Default password hash] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 00:03:48 -0000 On 6/11/12, RW wrote: > On Mon, 11 Jun 2012 00:37:30 +0200 > Oliver Pinter wrote: > > >> 16 rounds in 2012? It is not to weak?! > > It's hard to say. Remember that blowfish was designed as a cipher not > a hash. It's designed to be fast, but to still resist known plaintext > attacks at the beginning of the ciphertext. It was also designed to > work directly with a passphrase because there was a history of > programmers abusing DES by using simple ascii passwords as keys. > > For these reasons initialization is deliberately expensive, > effectively it already contains an element of passphrase hashing. Yes, I know that the blowfish is a cipher and not hash, but I think 16 round today is too small. I checked this in a freshly installed openbsd, and they used 256 round ($2a$08$...) . > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 00:21:55 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8535E106564A for ; Mon, 11 Jun 2012 00:21:55 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3C80B8FC0A for ; Mon, 11 Jun 2012 00:21:55 +0000 (UTC) Received: by vcbfy7 with SMTP id fy7so2220545vcb.13 for ; Sun, 10 Jun 2012 17:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WovgoPdYPkxDmTy8L6C4tcqjMAJtktdNTz3otWy0mcA=; b=HiSIscgAD7uB3a15bfDcL56XNTTPS7Ox4dXVKJLSifxLhBGYHOAwxp5tqIDIpDbwD1 fbb5uW5yg9i8Am8K6c1IUffABMt+V+rWpLVXuwSnoH+tU2ASmJ3JNM6aPA4bGQSZAcmS TzfdUWsHnZrqVng2UerFxImDZDEWGPsYY4jl+4LBd4yD0lrYbBqUd4MtKVo53ODJiTGj +g2gPaie+dDYWVTyYneMbgJBUcuY8E2F+pauE9qOQAocRvee/FXAG1TfHToSJV4l2hZ9 2E0ROh6LP88DfZaPGNehCHqJXtiXFP64hRWTEkIs4WRZJyakgW54CgIq829gvkvoDBZf nn6A== MIME-Version: 1.0 Received: by 10.52.89.35 with SMTP id bl3mr2920108vdb.106.1339374114387; Sun, 10 Jun 2012 17:21:54 -0700 (PDT) Received: by 10.52.113.97 with HTTP; Sun, 10 Jun 2012 17:21:54 -0700 (PDT) Date: Sun, 10 Jun 2012 20:21:54 -0400 Message-ID: From: Robert Simmons To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Pre-boot authentication / geli-aware bootcode X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 00:21:55 -0000 Would it be possible to make FreeBSD's bootcode aware of geli encrypted volumes? I would like to enter the password and begin decryption so that the kernel and /boot are inside the encrypted volume. Ideally the only unencrypted area of the disk would be the gpt protected mbr and the bootcode. I know that Truecrypt is able to do something like this with its truecrypt boot loader, is something like this possible with FreeBSD without using Truecrypt? From owner-freebsd-security@FreeBSD.ORG Sun Jun 10 23:28:08 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0B51106566B for ; Sun, 10 Jun 2012 23:28:08 +0000 (UTC) (envelope-from emu@karma.emu.so) Received: from karma.emu.so (ns1.emu.so [199.15.250.19]) by mx1.freebsd.org (Postfix) with ESMTP id B49B78FC23 for ; Sun, 10 Jun 2012 23:28:08 +0000 (UTC) Received: by karma.emu.so (Postfix, from userid 80) id 7175E4058B4; Sun, 10 Jun 2012 19:24:57 -0400 (EDT) To: X-PHP-Originating-Script: 501:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 10 Jun 2012 19:24:57 -0400 From: emu In-Reply-To: <20120611002402.088b2f74@gumby.homeunix.com> References: <20120611002402.088b2f74@gumby.homeunix.com> Message-ID: <2d4b79dfa4ce95d66979769637db932b@karma.emu.so> X-Sender: emu@karma.emu.so User-Agent: Roundcube Webmail/0.7.2 X-Mailman-Approved-At: Mon, 11 Jun 2012 01:36:08 +0000 Subject: Re: blf uses only 2^4 round for passwd encoding?! [Re: Default password hash] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 23:28:09 -0000 On 2012-06-10 19:24, RW wrote: > On Mon, 11 Jun 2012 00:37:30 +0200 > Oliver Pinter wrote: > > >> 16 rounds in 2012? It is not to weak?! > > It's hard to say. Remember that blowfish was designed as a cipher not > a hash. It's designed to be fast, but to still resist known plaintext > attacks at the beginning of the ciphertext. It was also designed to > work directly with a passphrase because there was a history of > programmers abusing DES by using simple ascii passwords as keys. > > For these reasons initialization is deliberately expensive, > effectively it already contains an element of passphrase hashing. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" how long are we going to go on about this From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 08:48:16 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D87751065673 for ; Mon, 11 Jun 2012 08:48:16 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 99A538FC15 for ; Mon, 11 Jun 2012 08:48:16 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 4F76167AC; Mon, 11 Jun 2012 08:48:10 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 261429EC1; Mon, 11 Jun 2012 10:48:10 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> Date: Mon, 11 Jun 2012 10:48:09 +0200 In-Reply-To: <4FD334BE.4020900@sentex.net> (Mike Tancsa's message of "Sat, 09 Jun 2012 07:34:22 -0400") Message-ID: <86ipeyp73q.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 08:48:16 -0000 Mike Tancsa writes: > Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ? Its > currently not there. "not there" as in "not supported by crypt(3)"? > http://phk.freebsd.dk/sagas/md5crypt_eol.html That blog entry is (partly) why I suggested this change. I think phk is being overly pessimistic, but there is no reason not to switch to sha512 when a) it's indubitably stronger and b) that's what the rest of the world uses. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 08:51:46 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABD4A1065670; Mon, 11 Jun 2012 08:51:46 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 688468FC16; Mon, 11 Jun 2012 08:51:46 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id BFBF667B0; Mon, 11 Jun 2012 08:51:45 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 959AC9EC3; Mon, 11 Jun 2012 10:51:45 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Damian Weber References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <20120610145351.GA1098@reks> Date: Mon, 11 Jun 2012 10:51:45 +0200 In-Reply-To: (Damian Weber's message of "Sun, 10 Jun 2012 18:55:18 +0200 (CEST)") Message-ID: <86ehpmp6xq.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Gleb Kurtsou , "Simon L. B. Nielsen" Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 08:51:46 -0000 Damian Weber writes: > *collision* attacks are relatively easy these days, but against 1 MD5,=20 > not against 1000 times MD5 I'm not talking about collision attacks, I'm talking about brute-forcing hashes. > there is a NIST hash competition running, the winner will soon be announc= ed > (and it won't be SHA256 or SHA512 ;-) > http://csrc.nist.gov/groups/ST/hash/timeline.html > so my suggestion would be to use all of the finalists - especially > the winner - for password hashing > * BLAKE > * Gr=C3=B8stl=20 > * JH > * Keccak > * Skein > see, for example, http://www.nist.gov/itl/csd/sha3_010511.cfm There's a world of difference between switching the default to an algorithm we already support and which is widely used by other operating systems, and switching to a completely knew and untested algorithm. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 08:56:05 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D873106566B for ; Mon, 11 Jun 2012 08:56:05 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4AD518FC17 for ; Mon, 11 Jun 2012 08:56:05 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 9EFAA67B7; Mon, 11 Jun 2012 08:56:04 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7D98D9EC8; Mon, 11 Jun 2012 10:56:04 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Oliver Pinter References: Date: Mon, 11 Jun 2012 10:56:04 +0200 In-Reply-To: (Oliver Pinter's message of "Mon, 11 Jun 2012 00:37:30 +0200") Message-ID: <8662ayp6qj.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: blf uses only 2^4 round for passwd encoding?! [Re: Default password hash] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 08:56:05 -0000 Oliver Pinter writes: > 16 rounds in 2012? It is not to weak?! Perhaps. I don't see how that affects sha512. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 09:47:19 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D55F1065670; Mon, 11 Jun 2012 09:47:19 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id DAECD8FC1D; Mon, 11 Jun 2012 09:47:18 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 32B5467D5; Mon, 11 Jun 2012 09:47:18 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E7A569EDA; Mon, 11 Jun 2012 11:47:17 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Lars Engels References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <20120610145351.GA1098@reks> <86ehpmp6xq.fsf@ds4.des.no> <20120611093505.GN5592@e-new.0x20.net> Date: Mon, 11 Jun 2012 11:47:17 +0200 In-Reply-To: <20120611093505.GN5592@e-new.0x20.net> (Lars Engels's message of "Mon, 11 Jun 2012 11:35:05 +0200") Message-ID: <86wr3enpsq.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Damian Weber , freebsd-security@freebsd.org, Gleb Kurtsou , "Simon L. B. Nielsen" Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 09:47:19 -0000 Lars Engels writes: > BTW Solaris 10 and 11 support our Blowfish algorithm, Solaris 10 >=3D 10/= 08 > supports SHA256 and SHA512 and SHA256 was mad the default algorithm in > Solaris 11. > Some Linux variants support Blowfish and from glibc 2.7 on they have > support for SHA256 and SHA512. > > So the least common denominator if we want to use a compatible format is > SHA256/SHA512. SHA512 is the default in RedHat, Fedora, Debian and Ubuntu. I believe SUSE uses Blowfish, but I'm not sure. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 10:44:08 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 394A5106566C; Mon, 11 Jun 2012 10:44:08 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C57808FC14; Mon, 11 Jun 2012 10:44:07 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9813:befc:15f6:30d5]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 373534AC31; Mon, 11 Jun 2012 14:44:04 +0400 (MSK) Date: Mon, 11 Jun 2012 14:44:02 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <734419687.20120611144402@serebryakov.spb.ru> To: "Simon L. B. Nielsen" In-Reply-To: <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 10:44:08 -0000 Hello, Simon. You wrote 10 =E8=FE=ED=FF 2012 =E3., 14:02:50: SLBN> Has anyone looked at how long the SHA512 password hashing SLBN> actually takes on modern computers? Modern computers are not what should you afraid. Modern GPUs are. And they are incredibly fast in calculation of MD5, SHA-1 and SHA-2. Modern key-derivation schemes must be RAM-heavy, not CPU-heavy. And I don't understand, why should we use our home-grown "strengthening" algorithms instead of "standard" choices: PBKDF2[1], bcrypt[2] and (my favorite) scrypt[3]. [1] http://tools.ietf.org/html/rfc2898 [2] http://static.usenix.org/events/usenix99/provos/provos_html/node1.html [3] http://www.tarsnap.com/scrypt.html --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 10:58:21 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5431106564A for ; Mon, 11 Jun 2012 10:58:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id A90E88FC08 for ; Mon, 11 Jun 2012 10:58:21 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q5BAwJ9x094545; Mon, 11 Jun 2012 06:58:19 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4FD5CF47.7070800@sentex.net> Date: Mon, 11 Jun 2012 06:58:15 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> <86ipeyp73q.fsf@ds4.des.no> In-Reply-To: <86ipeyp73q.fsf@ds4.des.no> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 10:58:22 -0000 On 6/11/2012 4:48 AM, Dag-Erling Smørgrav wrote: > Mike Tancsa writes: >> Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ? Its >> currently not there. > > "not there" as in "not supported by crypt(3)"? If you put in sha256|sha512 in passwd_format, the passwd that gets chosen is DES, as in Data Encryption Standard, not Dag-Erling Smørgrav ;-) ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 09:35:07 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29B931065672; Mon, 11 Jun 2012 09:35:07 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id C351E8FC0A; Mon, 11 Jun 2012 09:35:06 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id 05E496A601C; Mon, 11 Jun 2012 11:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id 24bQHtLUISWr; Mon, 11 Jun 2012 11:35:05 +0200 (CEST) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id AE46B6A6006; Mon, 11 Jun 2012 11:35:05 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id q5B9Z5lx063982; Mon, 11 Jun 2012 11:35:05 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id q5B9Z5oa063834; Mon, 11 Jun 2012 11:35:05 +0200 (CEST) (envelope-from lars) Date: Mon, 11 Jun 2012 11:35:05 +0200 From: Lars Engels To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Message-ID: <20120611093505.GN5592@e-new.0x20.net> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <20120610145351.GA1098@reks> <86ehpmp6xq.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aKeOajaNu7w8cMvA" Content-Disposition: inline In-Reply-To: <86ehpmp6xq.fsf@ds4.des.no> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p2 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 11 Jun 2012 11:35:35 +0000 Cc: Damian Weber , freebsd-security@freebsd.org, Gleb Kurtsou , "Simon L. B. Nielsen" Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 09:35:07 -0000 --aKeOajaNu7w8cMvA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2012 at 10:51:45AM +0200, Dag-Erling Sm=C3=B8rgrav wrote: > Damian Weber writes: > > *collision* attacks are relatively easy these days, but against 1 MD5,= =20 > > not against 1000 times MD5 >=20 > I'm not talking about collision attacks, I'm talking about brute-forcing > hashes. >=20 > > there is a NIST hash competition running, the winner will soon be annou= nced > > (and it won't be SHA256 or SHA512 ;-) > > http://csrc.nist.gov/groups/ST/hash/timeline.html > > so my suggestion would be to use all of the finalists - especially > > the winner - for password hashing > > * BLAKE > > * Gr=C3=B8stl=20 > > * JH > > * Keccak > > * Skein > > see, for example, http://www.nist.gov/itl/csd/sha3_010511.cfm >=20 > There's a world of difference between switching the default to an > algorithm we already support and which is widely used by other operating > systems, and switching to a completely knew and untested algorithm. BTW Solaris 10 and 11 support our Blowfish algorithm, Solaris 10 >=3D 10/08 supports SHA256 and SHA512 and SHA256 was mad the default algorithm in Solaris 11. Some Linux variants support Blowfish and from glibc 2.7 on they have support for SHA256 and SHA512. So the least common denominator if we want to use a compatible format is SHA256/SHA512. --aKeOajaNu7w8cMvA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/Vu8kACgkQKc512sD3afjwPgCfejKC5+LB0Hbr6Md2NGoKCoB8 ctgAmwbE4CdEDBzm8pwcCX/SOvsm3RVF =9E9D -----END PGP SIGNATURE----- --aKeOajaNu7w8cMvA-- From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 11:43:45 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B08D1065673 for ; Mon, 11 Jun 2012 11:43:45 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id ED7D68FC17 for ; Mon, 11 Jun 2012 11:43:44 +0000 (UTC) Received: by bkvi18 with SMTP id i18so4270058bkv.13 for ; Mon, 11 Jun 2012 04:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Yi4lLMCqWic0WnFY4vAwDS42zGgm04myDjmg0PXrFyM=; b=jybltv/FqCtPL00ZMHUwl/CYvAkSJ0pcxu0UNM8iwhWHDoUBcN4Y0InFYCHUbCHxAx Le/PUAhMmOCpEveSzzuV8JchKsFvFCwRat29UrzCjxzGB5aD1wdkcGzXv7K1fk7YiEOn GszruE2hnSVufDIU5iL5wrSRp/ai12LDMdJNA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=Yi4lLMCqWic0WnFY4vAwDS42zGgm04myDjmg0PXrFyM=; b=og8TBBHPgU9Wze+M+8P62zpTMjFT+7kh4SAXw4tGGcWZ8Pmt9cOq80jnTQXWoJrdib z5AwPh5dcinQ/a8htrGf1Udxjf4sSGnuQpBK6SqPQb3m8D7jOAPJtRtZrl5WxPFiKAjZ SEKfcXt+7W/pGI3+BLYk12xeDFpBnjsUVvEzMpf3SI2YCPnpR5RcDtEoaMMl2YrpqBis LovTyGH5ARGCrUjnjKaGNflSVGycsy8ylkzXDOPItQECkYj08+xMvWJ101U5fgbfuKzO NjOay2Xq9t5lafCt2785M6i01OEOowWLT2BD4XinGGY+pPGc4ePQYfjn1TGTLIAxeb/f Ltig== MIME-Version: 1.0 Received: by 10.204.155.139 with SMTP id s11mr10342417bkw.106.1339415023622; Mon, 11 Jun 2012 04:43:43 -0700 (PDT) Sender: simon@qxnitro.org Received: by 10.205.39.199 with HTTP; Mon, 11 Jun 2012 04:43:43 -0700 (PDT) X-Originating-IP: [2620:0:1040:204:be30:5bff:fee8:f39d] In-Reply-To: <20120610145351.GA1098@reks> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <20120610145351.GA1098@reks> Date: Mon, 11 Jun 2012 12:43:43 +0100 X-Google-Sender-Auth: yAbI7S3s_8Bd1xEvkkOUtkbpA4o Message-ID: From: "Simon L. B. Nielsen" To: Gleb Kurtsou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQndVvO+ArK8WuuhYgijxUO48SurrcgnChi4GlRI/QC4FuBezBuPB2/4ElElDlf7ocKN5XLA Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 11:43:45 -0000 On Sun, Jun 10, 2012 at 3:53 PM, Gleb Kurtsou wrot= e: > On (10/06/2012 11:02), Simon L. B. Nielsen wrote: >> >> On 8 Jun 2012, at 13:51, Dag-Erling Sm=C3=B8rgrav wrote: >> >> > We still have MD5 as our default password hash, even though known-hash >> > attacks against MD5 are relatively easy these days. =C2=A0We've suppor= ted >> > SHA256 and SHA512 for many years now, so how about making SHA512 the >> > default instead of MD5, like on most Linux distributions? >> >> Has anyone looked at how long the SHA512 password hashing actually takes= on modern computers? >> >> The "real" solution for people who care significantly about this seems s= omething like the algorithm pjd implemented (I think he did it at least) fo= r GELI, where the number of rounds is variable and calculated so it takes X= /0.X seconds on the specific hardware used. That's of course a lot more com= plicated, and I'm not sure if it would work with the crypt() API. > > Do you mean pkcs5v2_calculate from geli? It seems to have a drawback Correct. > that results produced depend on actual CPU load. That's not the drawback, but the whole point (well, at least a point). While it can of course produce fewer rounds on different systems, especially on fast systems you will likely end up with a lot more rounds than whatever the default is. > % ./pkcs5v-test [*] > 541491 > 539568 > 542352 > 540376 > 388285 -- start several instances of pkcs5v-test in parallel > 303071 > 284793 > 281110 > > It would be awesome to provide user with options to configure minimal > and maximal iteration count and randomly choose iteration count within > the range for each new password. Such trivial change should considerably > complicate mass password bruteforce cracking. That's also an option. I'm not sure how well that would work in practice. > Variable number of rounds for a password would also require changing > crypt() interface. Exactly, so probably not actually a working solution for normal case, and possibly just not worth the trouble at all due to compatibility. > Why does nobody mention scrypt? It looks very attractive in longer > perspective. It's not in the base system yet, last I checked anyway, so I assume that either Colin still don't find it ready for general use, or he has just been too busy. --=20 Simon From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 11:51:49 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F132106566B for ; Mon, 11 Jun 2012 11:51:49 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 893E68FC12 for ; Mon, 11 Jun 2012 11:51:48 +0000 (UTC) Received: by bkvi18 with SMTP id i18so4278194bkv.13 for ; Mon, 11 Jun 2012 04:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7Ky3dttyMzpFvQpV12krTdvK+M4vTMQVmsBY4SssrCw=; b=fT1UaSDIR2EhRwj5vFrvPcrVf8+4RZQyz07gc8CXkytAP+LCJdVZIkkonUqLFt4/Bb OgobsW9qhJRGXnt7v6Q6K/16qGlzcTAY6E0rpr6oWK/xjNUcN/Ysy8JhescHZ655xb4R ynz97AXdT0pwi5hTj/j/K5qUW9VBZ2LzKCPzM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=7Ky3dttyMzpFvQpV12krTdvK+M4vTMQVmsBY4SssrCw=; b=KvQjb3SR6DVvIfyipHVAiVD5IHNxGo1E44tPGfqLac6KML1tx9LObJOceUC7LImyYU l4Z38wwUqstdnTJxoMQzsnp+I2tBgAR8EAdaabbx4/RE9CRdWi+SzNeQKqVA7rz2LRYq ZhNcx3SMT60eWiSYi9ycIQJoo4zHQvd1ldEIbfOwa5p08+Vhz6LDU9a/j8ZBgZYQCbzM msC2U/lkgkXSoNENyMYPiATVjurbLf1Cb1aX/Ho+5CiTh87ptsP5b9l1gibcRpbJjJk7 V3H4v+Fu8VT3RCb0HECZudtAlJvqorahPJB2uFwBE7Nz1D6U8jVz56LtLyPTVkET/ea1 VdZg== MIME-Version: 1.0 Received: by 10.204.156.217 with SMTP id y25mr10123913bkw.65.1339415507371; Mon, 11 Jun 2012 04:51:47 -0700 (PDT) Sender: simon@qxnitro.org Received: by 10.205.39.199 with HTTP; Mon, 11 Jun 2012 04:51:47 -0700 (PDT) X-Originating-IP: [2620:0:1040:204:be30:5bff:fee8:f39d] In-Reply-To: <734419687.20120611144402@serebryakov.spb.ru> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <734419687.20120611144402@serebryakov.spb.ru> Date: Mon, 11 Jun 2012 12:51:47 +0100 X-Google-Sender-Auth: aDov3GkJmRlHZ_8kRDEcTmcNktU Message-ID: From: "Simon L. B. Nielsen" To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlXYcwq3nILc02HIia4OhAHwq1vCZA9GY++wNokEUMiBT7f4SX30L0MICU2Q10J9T7WJrRi Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 11:51:49 -0000 On Mon, Jun 11, 2012 at 11:44 AM, Lev Serebryakov wrote: > Hello, Simon. > You wrote 10 =D0=B8=D1=8E=D0=BD=D1=8F 2012 =D0=B3., 14:02:50: > > SLBN> Has anyone looked at how long the SHA512 password hashing > SLBN> actually takes on modern computers? > =C2=A0Modern =C2=A0computers =C2=A0are =C2=A0not what should you afraid. = Modern GPUs are. > And they are incredibly fast in calculation of MD5, SHA-1 and SHA-2. > > =C2=A0Modern key-derivation schemes must be RAM-heavy, not CPU-heavy. But the modern CPU's will limit the number of rounds you can use for a hash (if you use same system as md5crypt), as you can't let users wait 10+ seconds to check their password. > =C2=A0And =C2=A0 I =C2=A0 don't =C2=A0 understand, =C2=A0 why =C2=A0shoul= d =C2=A0we =C2=A0use =C2=A0our =C2=A0home-grown > "strengthening" algorithms instead of "standard" choices: PBKDF2[1], > bcrypt[2] and (my favorite) scrypt[3]. Recall that FreeBSD's MD5 strengthening probably predates most of the other systems by a while (I'm too lazy to look it up). That said, I generally agree we should go with something standard or existing unless there is a very good reason not to. PBKDF2 / RFC2898 is what GELI uses (which I mentioned previously). > [1] http://tools.ietf.org/html/rfc2898 > [2] http://static.usenix.org/events/usenix99/provos/provos_html/node1.htm= l > [3] http://www.tarsnap.com/scrypt.html --=20 Simon From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 14:00:16 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 491C91065670 for ; Mon, 11 Jun 2012 14:00:16 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id EDF9C8FC08 for ; Mon, 11 Jun 2012 14:00:15 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id B6B2868B6; Mon, 11 Jun 2012 14:00:14 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 758FF9F0A; Mon, 11 Jun 2012 16:00:14 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> <86ipeyp73q.fsf@ds4.des.no> <4FD5CF47.7070800@sentex.net> Date: Mon, 11 Jun 2012 16:00:14 +0200 In-Reply-To: <4FD5CF47.7070800@sentex.net> (Mike Tancsa's message of "Mon, 11 Jun 2012 06:58:15 -0400") Message-ID: <867gvene35.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:00:16 -0000 Mike Tancsa writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Mike Tancsa writes: > > > Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ? Its > > > currently not there. > > "not there" as in "not supported by crypt(3)"? > If you put in sha256|sha512 in passwd_format, the passwd that gets > chosen is DES, as in Data Encryption Standard, not Dag-Erling Sm=C3=B8rgr= av > ;-) This is non-trivial to fix, as the code that would need to be MFCed depends on libc changes. I'm worried about collateral damage from MFCing those changes. It may be possible to backport the sha2 code. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 14:12:09 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D365106564A for ; Mon, 11 Jun 2012 14:12:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id F29218FC08 for ; Mon, 11 Jun 2012 14:12:08 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q5BEC6eD023345; Mon, 11 Jun 2012 10:12:07 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4FD5FCB3.80000@sentex.net> Date: Mon, 11 Jun 2012 10:12:03 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> <86ipeyp73q.fsf@ds4.des.no> <4FD5CF47.7070800@sentex.net> <867gvene35.fsf@ds4.des.no> In-Reply-To: <867gvene35.fsf@ds4.des.no> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:12:09 -0000 On 6/11/2012 10:00 AM, Dag-Erling Smørgrav wrote: > Mike Tancsa writes: >> Dag-Erling Smørgrav writes: >>> Mike Tancsa writes: >>>> Actually, any chance of MFC'ing SHA256 and 512 in RELENG_7 ? Its >>>> currently not there. >>> "not there" as in "not supported by crypt(3)"? >> If you put in sha256|sha512 in passwd_format, the passwd that gets >> chosen is DES, as in Data Encryption Standard, not Dag-Erling Smørgrav >> ;-) > > This is non-trivial to fix, as the code that would need to be MFCed > depends on libc changes. I'm worried about collateral damage from > MFCing those changes. > > It may be possible to backport the sha2 code. Locally, we still have a need to share some passwd files between a couple of RELENG_8 and RELENG_7 boxes. But it might be better to just upgrade the new boxes to 8 if need be. If not, is Blowfish as its currently implemented on RELENG_7 considered strong enough ? There has been some discussion suggesting its not and some that it is. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 14:58:48 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B37A106564A for ; Mon, 11 Jun 2012 14:58:48 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4B78D8FC1B for ; Mon, 11 Jun 2012 14:58:48 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id A6F4268E3; Mon, 11 Jun 2012 14:58:47 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 76EEF9F23; Mon, 11 Jun 2012 16:58:47 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> <86ipeyp73q.fsf@ds4.des.no> <4FD5CF47.7070800@sentex.net> <867gvene35.fsf@ds4.des.no> <4FD5FCB3.80000@sentex.net> Date: Mon, 11 Jun 2012 16:58:47 +0200 In-Reply-To: <4FD5FCB3.80000@sentex.net> (Mike Tancsa's message of "Mon, 11 Jun 2012 10:12:03 -0400") Message-ID: <863961opy0.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:58:48 -0000 Mike Tancsa writes: > Locally, we still have a need to share some passwd files between a > couple of RELENG_8 and RELENG_7 boxes. But it might be better to just > upgrade the new boxes to 8 if need be. If not, is Blowfish as its > currently implemented on RELENG_7 considered strong enough ? There has > been some discussion suggesting its not and some that it is. I'm build-testing a backport of the sha2 code to 7 as we speak. I vastly prefer sha512 to blf, as that is what the rest of the world uses. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 15:04:22 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17921106566B; Mon, 11 Jun 2012 15:04:22 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CBFFB8FC16; Mon, 11 Jun 2012 15:04:21 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id B71D368E8; Mon, 11 Jun 2012 15:04:20 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 868C99F28; Mon, 11 Jun 2012 17:04:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "O. Hartmann" References: <86r4tqotjo.fsf@ds4.des.no> <4FD2FE87.1060708@zedat.fu-berlin.de> Date: Mon, 11 Jun 2012 17:04:20 +0200 In-Reply-To: <4FD2FE87.1060708@zedat.fu-berlin.de> (O. Hartmann's message of "Sat, 09 Jun 2012 09:43:03 +0200") Message-ID: <86vcixnb4b.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, "freebsd-cur >> Current FreeBSD" Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:04:22 -0000 "O. Hartmann" writes: > You should also file a PR for change-requets, so it is not only in the > email list. I have no idea what you mean by that... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 15:05:49 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71B68106564A; Mon, 11 Jun 2012 15:05:49 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2FC918FC14; Mon, 11 Jun 2012 15:05:49 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 9503068EA; Mon, 11 Jun 2012 15:05:48 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 77A189F2A; Mon, 11 Jun 2012 17:05:48 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Damian Weber References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <20120610145351.GA1098@reks> <86ehpmp6xq.fsf@ds4.des.no> Date: Mon, 11 Jun 2012 17:05:48 +0200 In-Reply-To: <86ehpmp6xq.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon, 11 Jun 2012 10:51:45 +0200") Message-ID: <86r4tlnb1v.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Gleb Kurtsou , "Simon L. B. Nielsen" Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:05:49 -0000 Dag-Erling Sm=C3=B8rgrav writes: > There's a world of difference between switching the default to an > algorithm we already support and which is widely used by other operating > systems, and switching to a completely knew and untested algorithm. ouch. s/knew/new/. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 15:12:10 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D197A1065670 for ; Mon, 11 Jun 2012 15:12:10 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 51D658FC1A for ; Mon, 11 Jun 2012 15:12:10 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 9409A68F4; Mon, 11 Jun 2012 15:12:09 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 6DAAF9F2D; Mon, 11 Jun 2012 17:12:09 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Simmons References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> <4FD350EF.6080802@sentex.net> Date: Mon, 11 Jun 2012 17:12:09 +0200 In-Reply-To: (Robert Simmons's message of "Sat, 9 Jun 2012 16:16:55 -0400") Message-ID: <86mx49nara.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:12:10 -0000 Robert Simmons writes: > Mike Tancsa writes: > > change the users passwd to something new, or just use the old > > passwd, but re-enter it > Bad idea. Never reuse an old password. What's an even worse idea is to learn such things by rote and spew them back out without ever reflecting on what they mean or whether they even apply to the current situation... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 16:24:33 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B480E1065670; Mon, 11 Jun 2012 16:24:33 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id BFB9F8FC0C; Mon, 11 Jun 2012 16:24:32 +0000 (UTC) Received: by laai10 with SMTP id i10so3473567laa.13 for ; Mon, 11 Jun 2012 09:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=OTymvtA9Ac1l1P5QUT+RLZYSbPP4t6PR3sUHvjNPqgo=; b=JBFZ2bYpCcVVM0FvnYRAC/SncO/hvJ8LP3iEJZ7PaygSaWpApsayznNnGxOmaJKy1/ RdhROfdf3twdWqQV+2x5oihP+5YCToUlZAyOOs7+N17OUpIS3c3qkW/HJo/jzsW233Gm KnTyA4qiwFeF5RQ/7tA7wPfg1WteuRK+LKd80zOEmkBTaxe2y22Z4b9tGJFk0qVo6QW4 yPCXOzzzuNs0FSZx19s2ZI2P0/pu1y37uniRQ4ZJYP8xqfb6EGS74/u20i45qcyM8p9H OSPzbj2/HCUWPRpjuKrf4xW+KqDDG+t6ej/ibaHKKuT96ivInMCkr7e0GMGUohRsPwtC Unog== Received: by 10.152.104.44 with SMTP id gb12mr17880704lab.29.1339431871695; Mon, 11 Jun 2012 09:24:31 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id u10sm8995562lbm.14.2012.06.11.09.24.29 (version=SSLv3 cipher=OTHER); Mon, 11 Jun 2012 09:24:30 -0700 (PDT) Date: Mon, 11 Jun 2012 19:24:23 +0300 From: Gleb Kurtsou To: "Simon L. B. Nielsen" Message-ID: <20120611162423.GA27001@reks> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <734419687.20120611144402@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , Lev Serebryakov , freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:24:33 -0000 On (11/06/2012 12:51), Simon L. B. Nielsen wrote: > On Mon, Jun 11, 2012 at 11:44 AM, Lev Serebryakov wrote: > > Hello, Simon. > > You wrote 10 июня 2012 г., 14:02:50: > > > > SLBN> Has anyone looked at how long the SHA512 password hashing > > SLBN> actually takes on modern computers? > >  Modern  computers  are  not what should you afraid. Modern GPUs are. > > And they are incredibly fast in calculation of MD5, SHA-1 and SHA-2. > > > >  Modern key-derivation schemes must be RAM-heavy, not CPU-heavy. > > But the modern CPU's will limit the number of rounds you can use for a > hash (if you use same system as md5crypt), as you can't let users wait > 10+ seconds to check their password. > > >  And   I   don't   understand,   why  should  we  use  our  home-grown > > "strengthening" algorithms instead of "standard" choices: PBKDF2[1], > > bcrypt[2] and (my favorite) scrypt[3]. > > Recall that FreeBSD's MD5 strengthening probably predates most of the > other systems by a while (I'm too lazy to look it up). > > That said, I generally agree we should go with something standard or > existing unless there is a very good reason not to. > > PBKDF2 / RFC2898 is what GELI uses (which I mentioned previously). PBKDF2 as a key derivation function is a bit different from a key stretching concept. KDF's *main* goal is to produce cryptographically good keys, but not to make bruteforce attacks hard on GPU/FPGA/etc. As already mentioned, nowadays good key stretching algorithms are supposed to be GPU-unfriendly. That is the case with crypto_blowfush, crypt_md5 and crypt_sha* thanks to data dependent branching, but it's not true for PBKDF2. I suppose everybody reading this thread has already seen recent presentation by Solar Designer on password security (video should also be available online): http://www.openwall.com/presentations/PHDays2012-Password-Security/ What particularly interesting is the following slide, comparing crypt_sha512/crypt_blowfish GPU-friendliness and performance: http://www.openwall.com/presentations/PHDays2012-Password-Security/mgp00037.html In other words, currently there is no benefit in switch default algorithm to relatively new crypt_sha512 vs 256-iterations crypt_blowfish supported on RELENG_7. crypt-md5.c except: for(i = 0; i < 1000; i++) { MD5Init(&ctx1); if(i & 1) MD5Update(&ctx1, (const u_char *)pw, strlen(pw)); else MD5Update(&ctx1, (const u_char *)final, MD5_SIZE); if(i % 3) MD5Update(&ctx1, (const u_char *)sp, (u_int)sl); if(i % 7) MD5Update(&ctx1, (const u_char *)pw, strlen(pw)); if(i & 1) MD5Update(&ctx1, (const u_char *)final, MD5_SIZE); else MD5Update(&ctx1, (const u_char *)pw, strlen(pw)); MD5Final(final, &ctx1); } > > [1] http://tools.ietf.org/html/rfc2898 > > [2] http://static.usenix.org/events/usenix99/provos/provos_html/node1.html > > [3] http://www.tarsnap.com/scrypt.html From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 16:32:56 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3614B106564A; Mon, 11 Jun 2012 16:32:56 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E74DB8FC15; Mon, 11 Jun 2012 16:32:55 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 08C6E6963; Mon, 11 Jun 2012 16:32:54 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 970209F84; Mon, 11 Jun 2012 18:32:53 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gleb Kurtsou References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <734419687.20120611144402@serebryakov.spb.ru> <20120611162423.GA27001@reks> Date: Mon, 11 Jun 2012 18:32:53 +0200 In-Reply-To: <20120611162423.GA27001@reks> (Gleb Kurtsou's message of "Mon, 11 Jun 2012 19:24:23 +0300") Message-ID: <86ipexn70q.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Lev Serebryakov , "Simon L. B. Nielsen" Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:32:56 -0000 Gleb Kurtsou writes: > In other words, currently there is no benefit in switch default > algorithm to relatively new crypt_sha512 vs 256-iterations > crypt_blowfish supported on RELENG_7. >From a cryptographic point of view, perhaps, but they are both better than the current default (md5), and all else being equal, I favor the option that maximises compatibility, i.e. sha512. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 17:15:55 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CBEB106564A for ; Mon, 11 Jun 2012 17:15:55 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 15F218FC16 for ; Mon, 11 Jun 2012 17:15:54 +0000 (UTC) Received: by eeke49 with SMTP id e49so2225188eek.13 for ; Mon, 11 Jun 2012 10:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=Noq6Wz2Vfe8W/jMwRco/P0mis/DweTHw4C71YfNy/i8=; b=h5LOI+Zq7N/w68aapu6qzFZBLybnnAM2fZ7dVHjO6jL8a/tep18TI1KFFky3AhiQ6E 4hzrwqzn48KYALIMxN/X8Gmww//wEC37MvUEVwNyGZ2lkgxgKN7UVfgaUWjXYTc3CS3J se8B0TXf4OUeWhk5/UDRwJKF+FVVfeC+PgpBokHCJMumk/RE+yTeZcInRprm/HbqM0TQ 7K0JNY/OcPbIe2RR3DqFLVhFTx8IVORLxWcjGBCAh6D+jc73OKXxjJM2dvdyKYB1g9CR N+3Tp+0FZeUzlEbjiGJfGD49b7rNk5g0Y62/mXIt9TssWV8xsPXfvOQLdDrdrFDGJteS SmOw== Received: by 10.14.45.12 with SMTP id o12mr2088108eeb.86.1339434953939; Mon, 11 Jun 2012 10:15:53 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id u16sm18732912eeb.16.2012.06.11.10.15.51 (version=SSLv3 cipher=OTHER); Mon, 11 Jun 2012 10:15:52 -0700 (PDT) Date: Mon, 11 Jun 2012 18:15:50 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120611181550.7a42ad66@gumby.homeunix.com> In-Reply-To: <734419687.20120611144402@serebryakov.spb.ru> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <734419687.20120611144402@serebryakov.spb.ru> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 17:15:55 -0000 On Mon, 11 Jun 2012 14:44:02 +0400 Lev Serebryakov wrote: > Hello, Simon. > You wrote 10 2012 ., 14:02:50: > > SLBN> Has anyone looked at how long the SHA512 password hashing > SLBN> actually takes on modern computers? > Modern computers are not what should you afraid. Modern GPUs are. > And they are incredibly fast in calculation of MD5, SHA-1 and SHA-2. > > Modern key-derivation schemes must be RAM-heavy, not CPU-heavy. They should be both, the point of scrypt is to optimize for normal ratios of cpu power to memory. > And I don't understand, why should we use our home-grown > "strengthening" algorithms instead of "standard" choices: PBKDF2[1], > bcrypt[2] and (my favorite) scrypt[3]. We already have bcrypt, it's called blowfish. I think what's needed is a self-tuning algorithm that tracks CPU time. IMO geli's PKCS #5 implementation is obsolete because it's based on core time. From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 17:57:01 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CACCE1065678; Mon, 11 Jun 2012 17:57:01 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id C19B28FC0A; Mon, 11 Jun 2012 17:57:00 +0000 (UTC) Received: by lbon10 with SMTP id n10so3676392lbo.13 for ; Mon, 11 Jun 2012 10:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=BWszj9OPczHpvYlAyRA4Q75FEb0pk4W1uhRDsyb76jk=; b=UMA4Sj0F+iN2cJ2Ae2uo6x9Quo2SyPc52XtibBibUNy4UEwd33MoE18mFrcebE7g1G Ic1AAbQhb+j68sOXI0ul28RgQqeVOjV/R0hd2IVTYPy0nw40YbiY+iiAB/GF/T0qgNwm dzuou3BtJZHEfULSZK4vS51Ykm0wc+r8BJIs4RZj/cdKXQi5JVeJvGGOL+jA8M1sD9Dx NVX7a5xFM4KsjYFJMlOF7EPW5pds0mynHPO3U6DGUYaf4q4YZYrdzh9VfUMUchQVeLKd uUwsaCHJAQrmTMx1BUwRrwgnvmZwUHJYBYDbl2gdQ+eYGaJtA8Tg3+Kqxkqga8nSpPzL 6gJw== Received: by 10.112.17.200 with SMTP id q8mr3086624lbd.11.1339437419387; Mon, 11 Jun 2012 10:56:59 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id fd1sm9117666lbb.7.2012.06.11.10.56.57 (version=SSLv3 cipher=OTHER); Mon, 11 Jun 2012 10:56:58 -0700 (PDT) Date: Mon, 11 Jun 2012 20:56:51 +0300 From: Gleb Kurtsou To: "Simon L. B. Nielsen" Message-ID: <20120611175651.GA27216@reks> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <20120610145351.GA1098@reks> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 17:57:01 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On (11/06/2012 12:43), Simon L. B. Nielsen wrote: > On Sun, Jun 10, 2012 at 3:53 PM, Gleb Kurtsou wrote: [...] > > Do you mean pkcs5v2_calculate from geli? It seems to have a drawback > > Correct. > > > that results produced depend on actual CPU load. > > That's not the drawback, but the whole point (well, at least a point). > While it can of course produce fewer rounds on different systems, > especially on fast systems you will likely end up with a lot more > rounds than whatever the default is. I meant that pkcs5v2_calculate() should be constant or nearly constant for a given system. It shouldn't depend on CPU load at the moment user decides to change his/her password -- function will return fewer number of rounds than it normally would. GELI use case is ok, normally one won't shuffle encrypted hard disks between machines, which is often the case with password database (the same password database accessed by all machines in network/cluster, fast and dog slow). > > % ./pkcs5v-test [*] > > 541491 > > 539568 > > 542352 > > 540376 > > 388285 -- start several instances of pkcs5v-test in parallel > > 303071 > > 284793 > > 281110 > > > > It would be awesome to provide user with options to configure minimal > > and maximal iteration count and randomly choose iteration count within > > the range for each new password. Such trivial change should considerably > > complicate mass password bruteforce cracking. > > That's also an option. I'm not sure how well that would work in practice. > > > Variable number of rounds for a password would also require changing > > crypt() interface. > > Exactly, so probably not actually a working solution for normal case, > and possibly just not worth the trouble at all due to compatibility. It turned out to be fairly easy to implement without nasty hacks. Please find the patch attached. I believe patch to be correct. There is no standard way to extract and pass salt from hashed password due to differences in formats, so universal workaround for crypt() interface limitations is the following: check password: strcmp(crypt(hashed_pass, realpw), realpw) == 0 set new password: crypt_set_format("hash type") hashed_new_pass = crypt(new_pass, random_salt); Thanks, Gleb. --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="crypt_sha2.incrandom.patch.txt" commit d8b1a55a18365b805b3025496a91899df9def8f0 Author: Gleb Kurtsou Date: Mon Jun 11 20:55:23 2012 +0300 libcrypt: Use random number of rounds in crypt_sha* for new passwords By default randomly increment number of rounds by at most 10%. diff --git a/lib/libcrypt/crypt-sha256.c b/lib/libcrypt/crypt-sha256.c index cab7405..1e91648 100644 --- a/lib/libcrypt/crypt-sha256.c +++ b/lib/libcrypt/crypt-sha256.c @@ -58,6 +58,8 @@ static const char sha256_rounds_prefix[] = "rounds="; #define ROUNDS_MIN 1000 /* Maximum number of rounds. */ #define ROUNDS_MAX 999999999 +/* Random number of rounds increment, set 0 to disable. */ +#define ROUNDS_INCRANDOM (ROUNDS_DEFAULT / 10) static char * crypt_sha256_r(const char *key, const char *salt, char *buffer, int buflen) @@ -69,7 +71,7 @@ crypt_sha256_r(const char *key, const char *salt, char *buffer, int buflen) size_t salt_len, key_len, cnt, rounds; char *cp, *copied_key, *copied_salt, *p_bytes, *s_bytes, *endp; const char *num; - bool rounds_custom; + bool rounds_custom, has_salt_prefix; copied_key = NULL; copied_salt = NULL; @@ -77,12 +79,16 @@ crypt_sha256_r(const char *key, const char *salt, char *buffer, int buflen) /* Default number of rounds. */ rounds = ROUNDS_DEFAULT; rounds_custom = false; + has_salt_prefix = false; /* Find beginning of salt string. The prefix should normally always * be present. Just in case it is not. */ - if (strncmp(sha256_salt_prefix, salt, sizeof(sha256_salt_prefix) - 1) == 0) + if (strncmp(sha256_salt_prefix, salt, sizeof(sha256_salt_prefix) - 1) + == 0) { /* Skip salt prefix. */ salt += sizeof(sha256_salt_prefix) - 1; + has_salt_prefix = true; + } if (strncmp(salt, sha256_rounds_prefix, sizeof(sha256_rounds_prefix) - 1) == 0) { @@ -94,6 +100,9 @@ crypt_sha256_r(const char *key, const char *salt, char *buffer, int buflen) rounds = MAX(ROUNDS_MIN, MIN(srounds, ROUNDS_MAX)); rounds_custom = true; } + } else if (!has_salt_prefix && ROUNDS_INCRANDOM != 0) { + rounds += arc4random() % ROUNDS_INCRANDOM; + rounds_custom = true; } salt_len = MIN(strcspn(salt, "$"), SALT_LEN_MAX); diff --git a/lib/libcrypt/crypt-sha512.c b/lib/libcrypt/crypt-sha512.c index 8e0054f..8cc710b 100644 --- a/lib/libcrypt/crypt-sha512.c +++ b/lib/libcrypt/crypt-sha512.c @@ -58,6 +58,8 @@ static const char sha512_rounds_prefix[] = "rounds="; #define ROUNDS_MIN 1000 /* Maximum number of rounds. */ #define ROUNDS_MAX 999999999 +/* Random number of rounds increment, set 0 to disable. */ +#define ROUNDS_INCRANDOM (ROUNDS_DEFAULT / 10) static char * crypt_sha512_r(const char *key, const char *salt, char *buffer, int buflen) @@ -69,7 +71,7 @@ crypt_sha512_r(const char *key, const char *salt, char *buffer, int buflen) size_t salt_len, key_len, cnt, rounds; char *cp, *copied_key, *copied_salt, *p_bytes, *s_bytes, *endp; const char *num; - bool rounds_custom; + bool rounds_custom, has_salt_prefix; copied_key = NULL; copied_salt = NULL; @@ -80,9 +82,12 @@ crypt_sha512_r(const char *key, const char *salt, char *buffer, int buflen) /* Find beginning of salt string. The prefix should normally always * be present. Just in case it is not. */ - if (strncmp(sha512_salt_prefix, salt, sizeof(sha512_salt_prefix) - 1) == 0) + if (strncmp(sha512_salt_prefix, salt, sizeof(sha512_salt_prefix) - 1) + == 0) { /* Skip salt prefix. */ salt += sizeof(sha512_salt_prefix) - 1; + has_salt_prefix = true; + } if (strncmp(salt, sha512_rounds_prefix, sizeof(sha512_rounds_prefix) - 1) == 0) { @@ -94,6 +99,9 @@ crypt_sha512_r(const char *key, const char *salt, char *buffer, int buflen) rounds = MAX(ROUNDS_MIN, MIN(srounds, ROUNDS_MAX)); rounds_custom = true; } + } else if (!has_salt_prefix && ROUNDS_INCRANDOM != 0) { + rounds += arc4random() % ROUNDS_INCRANDOM; + rounds_custom = true; } salt_len = MIN(strcspn(salt, "$"), SALT_LEN_MAX); --ew6BAiZeqk4r7MaW-- From owner-freebsd-security@FreeBSD.ORG Mon Jun 11 21:36:17 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0567106566B for ; Mon, 11 Jun 2012 21:36:17 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [IPv6:2604:e700:b0:1::200]) by mx1.freebsd.org (Postfix) with ESMTP id 90D288FC14 for ; Mon, 11 Jun 2012 21:36:17 +0000 (UTC) Received: from magnum.bit0.com (localhost [127.0.0.1]) by magnum.bit0.com (Postfix) with ESMTP id E0337D9F2 for ; Mon, 11 Jun 2012 17:36:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=bit0.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=boogity; bh=AA3CEzWn9 igWoMG4yqUYBe+aa+GZDyjGVg/XkRZTSTI=; b=p3ShRTAcbraiqyvtt7M9/+QFA e9lPS20gB6tZ9LSXYEWllMEVnGXxjrbC6NDY5GEFX5l65lbiGAtkyi2kl8mu+Wx1 VrJbx1Y17Un3CHWA1pH0NhAC86KAqvB3dO11ki4aiTq9ZAMuAwohWymBaoT3BHm1 eOJu7n8JhozCVjaqrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bit0.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=boogity; b=GsO GXxWMA6W9lJEd5Z9TIf7+DgXk+1toNZGkhgdhKszfofYwePAFgSsXuc7UJUXlrar /cxi46hiHaVP7Z5rcVEOrRTOK13SzM2UyFgFO3GZ53uGv4qySaV1akPbacyiglzk c2cFIHIUGA8HeZahFYkKxrAeFycsV3jRyOLE0zzY= Received: from millenniumforce.local (ip-64-134-165-238.public.wayport.net [64.134.165.238]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by magnum.bit0.com (Postfix) with ESMTPSA id AC03AD9F1 for ; Mon, 11 Jun 2012 17:36:16 -0400 (EDT) Message-ID: <4FD664CF.5010400@bit0.com> Date: Mon, 11 Jun 2012 17:36:15 -0400 From: Mike Andrews User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <20120611002402.088b2f74@gumby.homeunix.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: blf uses only 2^4 round for passwd encoding?! [Re: Default password hash] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 21:36:18 -0000 On 6/10/12 8:03 PM, Oliver Pinter wrote: > On 6/11/12, RW wrote: >> On Mon, 11 Jun 2012 00:37:30 +0200 >> Oliver Pinter wrote: >> >>> 16 rounds in 2012? It is not to weak?! >> It's hard to say. Remember that blowfish was designed as a cipher not >> a hash. It's designed to be fast, but to still resist known plaintext >> attacks at the beginning of the ciphertext. It was also designed to >> work directly with a passphrase because there was a history of >> programmers abusing DES by using simple ascii passwords as keys. >> >> For these reasons initialization is deliberately expensive, >> effectively it already contains an element of passphrase hashing. > Yes, I know that the blowfish is a cipher and not hash, but I think 16 > round today is too small. I checked this in a freshly installed > openbsd, and they used 256 round ($2a$08$...) . > In OpenBSD, I think the number of Blowfish rounds is configurable via login.conf. I'd think that'd be an easy change to bring over... From owner-freebsd-security@FreeBSD.ORG Tue Jun 12 11:56:50 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 041B8106566B for ; Tue, 12 Jun 2012 11:56:50 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 535E18FC08 for ; Tue, 12 Jun 2012 11:56:49 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 988A66C55; Tue, 12 Jun 2012 11:56:42 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 3A9888052; Tue, 12 Jun 2012 13:56:42 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> <86ipeyp73q.fsf@ds4.des.no> <4FD5CF47.7070800@sentex.net> <867gvene35.fsf@ds4.des.no> <4FD5FCB3.80000@sentex.net> <863961opy0.fsf@ds4.des.no> Date: Tue, 12 Jun 2012 13:56:41 +0200 In-Reply-To: <863961opy0.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon, 11 Jun 2012 16:58:47 +0200") Message-ID: <86zk88lp52.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:56:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The attached patch backports support for sha256 and sha512 hashes to stable/7. It is not an exact MFH because the sha code in head uses stpncpy(), which is not present in stable/7's libc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=sha2-stable7.diff Index: lib/libcrypt =================================================================== --- lib/libcrypt (revision 236892) +++ lib/libcrypt (working copy) Property changes on: lib/libcrypt ___________________________________________________________________ Added: svn:mergeinfo Merged /head/gnu/libcrypt:r183242 Merged /head/lib/libcrypt:r179308,183242,213738,213814,213903,216591,220497-220498,221142,221471,227006,234132 Index: lib/libcrypt/crypt.c =================================================================== --- lib/libcrypt/crypt.c (revision 236892) +++ lib/libcrypt/crypt.c (working copy) @@ -63,6 +63,16 @@ "$3$" }, { + "sha256", + crypt_sha256, + "$5$" + }, + { + "sha512", + crypt_sha512, + "$6$" + }, + { NULL, NULL, NULL Index: lib/libcrypt/crypt-sha512.c =================================================================== --- lib/libcrypt/crypt-sha512.c (working copy) +++ lib/libcrypt/crypt-sha512.c (working copy) @@ -60,7 +60,7 @@ #define ROUNDS_MAX 999999999 static char * -sha512_crypt_r(const char *key, const char *salt, char *buffer, int buflen) +crypt_sha512_r(const char *key, const char *salt, char *buffer, int buflen) { u_long srounds; int n; @@ -210,7 +210,9 @@ /* Now we can construct the result string. It consists of three * parts. */ - cp = stpncpy(buffer, sha512_salt_prefix, MAX(0, buflen)); + cp = buffer; + strncpy(buffer, sha512_salt_prefix, MAX(0, buflen)); + cp += sizeof(sha512_salt_prefix) - 1; buflen -= sizeof(sha512_salt_prefix) - 1; if (rounds_custom) { @@ -221,7 +223,8 @@ buflen -= n; } - cp = stpncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len)); + strncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len)); + cp += MIN((size_t)MAX(0, buflen), salt_len); buflen -= MIN((size_t)MAX(0, buflen), salt_len); if (buflen > 0) { @@ -280,12 +283,12 @@ /* This entry point is equivalent to crypt(3). */ char * -sha512_crypt(const char *key, const char *salt) +crypt_sha512(const char *key, const char *salt) { /* We don't want to have an arbitrary limit in the size of the * password. We can compute an upper bound for the size of the * result in advance and so we can prepare the buffer we pass to - * `sha512_crypt_r'. */ + * `crypt_sha512_r'. */ static char *buffer; static int buflen; int needed; @@ -305,7 +308,7 @@ buflen = needed; } - return sha512_crypt_r(key, salt, buffer, buflen); + return crypt_sha512_r(key, salt, buffer, buflen); } #ifdef TEST @@ -482,7 +485,7 @@ } for (cnt = 0; cnt < ntests2; ++cnt) { - char *cp = sha512_crypt(tests2[cnt].input, tests2[cnt].salt); + char *cp = crypt_sha512(tests2[cnt].input, tests2[cnt].salt); if (strcmp(cp, tests2[cnt].expected) != 0) { printf("test %d: expected \"%s\", got \"%s\"\n", Index: lib/libcrypt/crypt.h =================================================================== --- lib/libcrypt/crypt.h (revision 236892) +++ lib/libcrypt/crypt.h (working copy) @@ -36,5 +36,8 @@ char *crypt_md5(const char *pw, const char *salt); char *crypt_nthash(const char *pw, const char *salt); char *crypt_blowfish(const char *pw, const char *salt); +char *crypt_sha256 (const char *pw, const char *salt); +char *crypt_sha512 (const char *pw, const char *salt); extern void _crypt_to64(char *s, u_long v, int n); +extern void b64_from_24bit(uint8_t B2, uint8_t B1, uint8_t B0, int n, int *buflen, char **cp); Index: lib/libcrypt/crypt-sha256.c =================================================================== --- lib/libcrypt/crypt-sha256.c (working copy) +++ lib/libcrypt/crypt-sha256.c (working copy) @@ -60,7 +60,7 @@ #define ROUNDS_MAX 999999999 static char * -sha256_crypt_r(const char *key, const char *salt, char *buffer, int buflen) +crypt_sha256_r(const char *key, const char *salt, char *buffer, int buflen) { u_long srounds; int n; @@ -210,7 +210,9 @@ /* Now we can construct the result string. It consists of three * parts. */ - cp = stpncpy(buffer, sha256_salt_prefix, MAX(0, buflen)); + cp = buffer; + strncpy(buffer, sha256_salt_prefix, MAX(0, buflen)); + cp += sizeof(sha256_salt_prefix) - 1; buflen -= sizeof(sha256_salt_prefix) - 1; if (rounds_custom) { @@ -221,7 +223,8 @@ buflen -= n; } - cp = stpncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len)); + strncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len)); + cp += MIN((size_t)MAX(0, buflen), salt_len); buflen -= MIN((size_t)MAX(0, buflen), salt_len); if (buflen > 0) { @@ -268,12 +271,12 @@ /* This entry point is equivalent to crypt(3). */ char * -sha256_crypt(const char *key, const char *salt) +crypt_sha256(const char *key, const char *salt) { /* We don't want to have an arbitrary limit in the size of the * password. We can compute an upper bound for the size of the * result in advance and so we can prepare the buffer we pass to - * `sha256_crypt_r'. */ + * `crypt_sha256_r'. */ static char *buffer; static int buflen; int needed; @@ -293,7 +296,7 @@ buflen = needed; } - return sha256_crypt_r(key, salt, buffer, buflen); + return crypt_sha256_r(key, salt, buffer, buflen); } #ifdef TEST @@ -459,7 +462,7 @@ } for (cnt = 0; cnt < ntests2; ++cnt) { - char *cp = sha256_crypt(tests2[cnt].input, tests2[cnt].salt); + char *cp = crypt_sha256(tests2[cnt].input, tests2[cnt].salt); if (strcmp(cp, tests2[cnt].expected) != 0) { printf("test %d: expected \"%s\", got \"%s\"\n", Index: lib/libcrypt/crypt.3 =================================================================== --- lib/libcrypt/crypt.3 (revision 236892) +++ lib/libcrypt/crypt.3 (working copy) @@ -29,7 +29,7 @@ .\" .\" $FreeBSD$ .\" -.Dd January 19, 1997 +.Dd April 9, 2011 .Dt CRYPT 3 .Os .Sh NAME @@ -188,6 +188,12 @@ Blowfish .It NT-Hash +.It +(unused) +.It +SHA-256 +.It +SHA-512 .El .Pp Other crypt formats may be easily added. @@ -226,7 +232,9 @@ .\" .Ql des , .Ql blf , -.Ql md5 +.Ql md5 , +.Ql sha256 , +.Ql sha512 and .Ql nth . .Pp Index: lib/libcrypt/misc.c =================================================================== --- lib/libcrypt/misc.c (revision 236892) +++ lib/libcrypt/misc.c (working copy) @@ -45,3 +45,19 @@ v >>= 6; } } + +void +b64_from_24bit(uint8_t B2, uint8_t B1, uint8_t B0, int n, int *buflen, char **cp) +{ + uint32_t w; + int i; + + w = (B2 << 16) | (B1 << 8) | B0; + for (i = 0; i < n; i++) { + **cp = itoa64[w&0x3f]; + (*cp)++; + if ((*buflen)-- < 0) + break; + w >>= 6; + } +} Index: lib/libcrypt/Makefile =================================================================== --- lib/libcrypt/Makefile (revision 236892) +++ lib/libcrypt/Makefile (working copy) @@ -12,7 +12,9 @@ .PATH: ${.CURDIR}/../libmd SRCS= crypt.c misc.c \ crypt-md5.c md5c.c \ - crypt-nthash.c md4c.c + crypt-nthash.c md4c.c \ + crypt-sha256.c sha256c.c \ + crypt-sha512.c sha512c.c MAN= crypt.3 MLINKS= crypt.3 crypt_get_format.3 crypt.3 crypt_set_format.3 CFLAGS+= -I${.CURDIR}/../libmd -I${.CURDIR}/../libutil @@ -29,7 +31,9 @@ SRCS+= auth.c property.c .for sym in auth_getval property_find properties_read properties_free \ MD4Init MD4Final MD4Update MD4Pad \ - MD5Init MD5Final MD5Update MD5Pad + MD5Init MD5Final MD5Update MD5Pad \ + SHA256_Init SHA256_Final SHA256_Update \ + SHA512_Init SHA512_Final SHA512_Update CFLAGS+= -D${sym}=__${sym} .endfor Index: lib/libmd =================================================================== --- lib/libmd (revision 236892) +++ lib/libmd (working copy) Property changes on: lib/libmd ___________________________________________________________________ Added: svn:mergeinfo Merged /head/gnu/libmd:r183242 Merged /head/lib/libmd:r179308,183242,213738,213814,213903,216591,220496,223582,227006 Index: lib/libmd/sha512.3 =================================================================== --- lib/libmd/sha512.3 (working copy) +++ lib/libmd/sha512.3 (working copy) @@ -127,7 +127,7 @@ .Xr sha 3 .Sh HISTORY These functions appeared in -.Fx 4.0 . +.Fx 9.0 . .Sh AUTHORS The core hash routines were implemented by Colin Percival based on the published Index: lib/libmd/sha256.3 =================================================================== --- lib/libmd/sha256.3 (revision 236892) +++ lib/libmd/sha256.3 (working copy) @@ -127,7 +127,7 @@ .Xr sha 3 .Sh HISTORY These functions appeared in -.Fx 4.0 . +.Fx 6.0 . .Sh AUTHORS The core hash routines were implemented by Colin Percival based on the published Index: lib/libmd/Makefile =================================================================== --- lib/libmd/Makefile (revision 236892) +++ lib/libmd/Makefile (working copy) @@ -5,10 +5,11 @@ SRCS= md2c.c md4c.c md5c.c md2hl.c md4hl.c md5hl.c \ rmd160c.c rmd160hl.c \ sha0c.c sha0hl.c sha1c.c sha1hl.c \ - sha256c.c sha256hl.c -INCS= md2.h md4.h md5.h ripemd.h sha.h sha256.h + sha256c.c sha256hl.c \ + sha512c.c sha512hl.c +INCS= md2.h md4.h md5.h ripemd.h sha.h sha256.h sha512.h -MAN+= md2.3 md4.3 md5.3 ripemd.3 sha.3 sha256.3 +MAN+= md2.3 md4.3 md5.3 ripemd.3 sha.3 sha256.3 sha512.3 MLINKS+=md2.3 MD2Init.3 md2.3 MD2Update.3 md2.3 MD2Final.3 MLINKS+=md2.3 MD2End.3 md2.3 MD2File.3 md2.3 MD2FileChunk.3 MLINKS+=md2.3 MD2Data.3 @@ -32,10 +33,15 @@ MLINKS+=sha256.3 SHA256_Final.3 sha256.3 SHA256_End.3 MLINKS+=sha256.3 SHA256_File.3 sha256.3 SHA256_FileChunk.3 MLINKS+=sha256.3 SHA256_Data.3 +MLINKS+=sha512.3 SHA512_Init.3 sha512.3 SHA512_Update.3 +MLINKS+=sha512.3 SHA512_Final.3 sha512.3 SHA512_End.3 +MLINKS+=sha512.3 SHA512_File.3 sha512.3 SHA512_FileChunk.3 +MLINKS+=sha512.3 SHA512_Data.3 CLEANFILES+= md[245]hl.c md[245].ref md[245].3 mddriver \ rmd160.ref rmd160hl.c rmddriver \ sha0.ref sha0hl.c sha1.ref sha1hl.c shadriver \ - sha256.ref sha256hl.c + sha256.ref sha256hl.c sha512.ref sha512hl.c + CFLAGS+= -I${.CURDIR} .PATH: ${.CURDIR}/${MACHINE_ARCH} @@ -76,6 +82,12 @@ -e 's/SHA256__/SHA256_/g' \ ${.ALLSRC}) > ${.TARGET} +sha512hl.c: mdXhl.c + (echo '#define LENGTH 64'; \ + sed -e 's/mdX/sha512/g' -e 's/MDX/SHA512_/g' \ + -e 's/SHA512__/SHA512_/g' \ + ${.ALLSRC}) > ${.TARGET} + rmd160hl.c: mdXhl.c (echo '#define LENGTH 20'; \ sed -e 's/mdX/ripemd/g' -e 's/MDX/RIPEMD160_/g' \ @@ -105,8 +117,10 @@ @echo 'MD4 ("abc") = a448017aaf21d8525fc10ae87aa6729d' >> ${.TARGET} @echo 'MD4 ("message digest") = d9130a8164549fe818874806e1c7014b' >> ${.TARGET} @echo 'MD4 ("abcdefghijklmnopqrstuvwxyz") = d79e1c308aa5bbcdeea8ed63df412da9' >> ${.TARGET} - @echo 'MD4 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") = 043f8582f241db351ce627e153e7f0e4' >> ${.TARGET} - @echo 'MD4 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") = e33b4ddc9c38f2199c3e7b164fcc0536' >> ${.TARGET} + @echo 'MD4 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + '043f8582f241db351ce627e153e7f0e4' >> ${.TARGET} + @echo 'MD4 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + 'e33b4ddc9c38f2199c3e7b164fcc0536' >> ${.TARGET} md5.ref: echo 'MD5 test suite:' > ${.TARGET} @@ -119,54 +133,74 @@ @echo 'MD5 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") = 57edf4a22be3c955ac49da2e2107b67a' >> ${.TARGET} sha0.ref: - (echo 'SHA-0 test suite:'; \ - echo 'SHA-0 ("") = f96cea198ad1dd5617ac084a3d92c6107708c0ef'; \ - echo 'SHA-0 ("abc") = 0164b8a914cd2a5e74c4f7ff082c4d97f1edf880'; \ - echo 'SHA-0 ("message digest") =' \ - 'c1b0f222d150ebb9aa36a40cafdc8bcbed830b14'; \ - echo 'SHA-0 ("abcdefghijklmnopqrstuvwxyz") =' \ - 'b40ce07a430cfd3c033039b9fe9afec95dc1bdcd'; \ - echo 'SHA-0 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ - '79e966f7a3a990df33e40e3d7f8f18d2caebadfa'; \ - echo 'SHA-0 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ - '4aa29d14d171522ece47bee8957e35a41f3e9cff' ) > ${.TARGET} + echo 'SHA-0 test suite:' > ${.TARGET} + @echo 'SHA-0 ("") = f96cea198ad1dd5617ac084a3d92c6107708c0ef' >> ${.TARGET} + @echo 'SHA-0 ("abc") = 0164b8a914cd2a5e74c4f7ff082c4d97f1edf880' >> ${.TARGET} + @echo 'SHA-0 ("message digest") =' \ + 'c1b0f222d150ebb9aa36a40cafdc8bcbed830b14' >> ${.TARGET} + @echo 'SHA-0 ("abcdefghijklmnopqrstuvwxyz") =' \ + 'b40ce07a430cfd3c033039b9fe9afec95dc1bdcd' >> ${.TARGET} + @echo 'SHA-0 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + '79e966f7a3a990df33e40e3d7f8f18d2caebadfa' >> ${.TARGET} + @echo 'SHA-0 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + '4aa29d14d171522ece47bee8957e35a41f3e9cff' >> ${.TARGET} sha1.ref: - (echo 'SHA-1 test suite:'; \ - echo 'SHA-1 ("") = da39a3ee5e6b4b0d3255bfef95601890afd80709'; \ - echo 'SHA-1 ("abc") = a9993e364706816aba3e25717850c26c9cd0d89d'; \ - echo 'SHA-1 ("message digest") =' \ - 'c12252ceda8be8994d5fa0290a47231c1d16aae3'; \ - echo 'SHA-1 ("abcdefghijklmnopqrstuvwxyz") =' \ - '32d10c7b8cf96570ca04ce37f2a19d84240d3a89'; \ - echo 'SHA-1 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ - '761c457bf73b14d27e9e9265c46f4b4dda11f940'; \ - echo 'SHA-1 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ - '50abf5706a150990a08b2c5ea40fa0e585554732' ) > ${.TARGET} + echo 'SHA-1 test suite:' > ${.TARGET} + @echo 'SHA-1 ("") = da39a3ee5e6b4b0d3255bfef95601890afd80709' >> ${.TARGET} + @echo 'SHA-1 ("abc") = a9993e364706816aba3e25717850c26c9cd0d89d' >> ${.TARGET} + @echo 'SHA-1 ("message digest") =' \ + 'c12252ceda8be8994d5fa0290a47231c1d16aae3' >> ${.TARGET} + @echo 'SHA-1 ("abcdefghijklmnopqrstuvwxyz") =' \ + '32d10c7b8cf96570ca04ce37f2a19d84240d3a89' >> ${.TARGET} + @echo 'SHA-1 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + '761c457bf73b14d27e9e9265c46f4b4dda11f940' >> ${.TARGET} + @echo 'SHA-1 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + '50abf5706a150990a08b2c5ea40fa0e585554732' >> ${.TARGET} sha256.ref: echo 'SHA-256 test suite:' > ${.TARGET} @echo 'SHA-256 ("") = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855' >> ${.TARGET} - @echo 'SHA-256 ("abc") = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad' >> ${.TARGET} - @echo 'SHA-256 ("message digest") = f7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650' >> ${.TARGET} - @echo 'SHA-256 ("abcdefghijklmnopqrstuvwxyz") = 71c480df93d6ae2f1efad1447c66c9525e316218cf51fc8d9ed832f2daf18b73' >> ${.TARGET} - @echo 'SHA-256 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") = db4bfcbd4da0cd85a60c3c37d3fbd8805c77f15fc6b1fdfe614ee0a7c8fdb4c0' >> ${.TARGET} - @echo 'SHA-256 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") = f371bc4a311f2b009eef952dd83ca80e2b60026c8e935592d0f9c308453c813e' >> ${.TARGET} + @echo 'SHA-256 ("abc") =' \ + 'ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad' >> ${.TARGET} + @echo 'SHA-256 ("message digest") =' \ + 'f7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650' >> ${.TARGET} + @echo 'SHA-256 ("abcdefghijklmnopqrstuvwxyz") =' \ + '71c480df93d6ae2f1efad1447c66c9525e316218cf51fc8d9ed832f2daf18b73' >> ${.TARGET} + @echo 'SHA-256 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + 'db4bfcbd4da0cd85a60c3c37d3fbd8805c77f15fc6b1fdfe614ee0a7c8fdb4c0' >> ${.TARGET} + @echo 'SHA-256 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + 'f371bc4a311f2b009eef952dd83ca80e2b60026c8e935592d0f9c308453c813e' >> ${.TARGET} +sha512.ref: + echo 'SHA-512 test suite:' > ${.TARGET} + @echo 'SHA-512 ("") =' \ + 'cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e' >> ${.TARGET} + @echo 'SHA-512 ("abc") =' \ + 'ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f' >> ${.TARGET} + @echo 'SHA-512 ("message digest") =' \ + '107dbf389d9e9f71a3a95f6c055b9251bc5268c2be16d6c13492ea45b0199f3309e16455ab1e96118e8a905d5597b72038ddb372a89826046de66687bb420e7c' >> ${.TARGET} + @echo 'SHA-512 ("abcdefghijklmnopqrstuvwxyz") =' \ + '4dbff86cc2ca1bae1e16468a05cb9881c97f1753bce3619034898faa1aabe429955a1bf8ec483d7421fe3c1646613a59ed5441fb0f321389f77f48a879c7b1f1' >> ${.TARGET} + @echo 'SHA-512 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + '1e07be23c26a86ea37ea810c8ec7809352515a970e9253c26f536cfc7a9996c45c8370583e0a78fa4a90041d71a4ceab7423f19c71b9d5a3e01249f0bebd5894' >> ${.TARGET} + @echo 'SHA-512 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + '72ec1ef1124a45b047e8b7c75a932195135bb61de24ec0d1914042246e0aec3a2354e093d76f3048b456764346900cb130d2a4fd5dd16abb5e30bcb850dee843' >> ${.TARGET} + rmd160.ref: - (echo 'RIPEMD160 test suite:'; \ - echo 'RIPEMD160 ("") = 9c1185a5c5e9fc54612808977ee8f548b2258d31'; \ - echo 'RIPEMD160 ("abc") = 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc'; \ - echo 'RIPEMD160 ("message digest") =' \ - '5d0689ef49d2fae572b881b123a85ffa21595f36'; \ - echo 'RIPEMD160 ("abcdefghijklmnopqrstuvwxyz") =' \ - 'f71c27109c692c1b56bbdceb5b9d2865b3708dbc'; \ - echo 'RIPEMD160 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ - 'b0e20b6e3116640286ed3a87a5713079b21f5189'; \ - echo 'RIPEMD160 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ - '9b752e45573d4b39f4dbd3323cab82bf63326bfb' ) > ${.TARGET} + echo 'RIPEMD160 test suite:' > ${.TARGET} + @echo 'RIPEMD160 ("") = 9c1185a5c5e9fc54612808977ee8f548b2258d31' >> ${.TARGET} + @echo 'RIPEMD160 ("abc") = 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc' >> ${.TARGET} + @echo 'RIPEMD160 ("message digest") =' \ + '5d0689ef49d2fae572b881b123a85ffa21595f36' >> ${.TARGET} + @echo 'RIPEMD160 ("abcdefghijklmnopqrstuvwxyz") =' \ + 'f71c27109c692c1b56bbdceb5b9d2865b3708dbc' >> ${.TARGET} + @echo 'RIPEMD160 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + 'b0e20b6e3116640286ed3a87a5713079b21f5189' >> ${.TARGET} + @echo 'RIPEMD160 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + '9b752e45573d4b39f4dbd3323cab82bf63326bfb' >> ${.TARGET} -test: md2.ref md4.ref md5.ref sha0.ref rmd160.ref sha1.ref sha256.ref +test: md2.ref md4.ref md5.ref sha0.ref rmd160.ref sha1.ref sha256.ref sha512.ref @${ECHO} if any of these test fail, the code produces wrong results @${ECHO} and should NOT be used. ${CC} ${CFLAGS} ${LDFLAGS} -DMD=2 -o mddriver ${.CURDIR}/mddriver.c -L. -lmd @@ -192,6 +226,9 @@ ${CC} ${CFLAGS} ${LDFLAGS} -DSHA=256 -o shadriver ${.CURDIR}/shadriver.c -L. -lmd ./shadriver | cmp sha256.ref - @${ECHO} SHA-256 passed test + ${CC} ${CFLAGS} ${LDFLAGS} -DSHA=512 -o shadriver ${.CURDIR}/shadriver.c libmd.a + ./shadriver | cmp sha512.ref - + @${ECHO} SHA-512 passed test -rm -f shadriver .include Index: lib/libmd/rmddriver.c =================================================================== --- lib/libmd/rmddriver.c (revision 236892) +++ lib/libmd/rmddriver.c (working copy) @@ -1,53 +1,51 @@ -/* RIPEMD160DRIVER.C - test driver for RIPEMD160 - */ +/* RIPEMD160DRIVER.C - test driver for RIPEMD160 */ +/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All rights + * reserved. + * + * RSA Data Security, Inc. makes no representations concerning either the + * merchantability of this software or the suitability of this software for + * any particular purpose. It is provided "as is" without express or implied + * warranty of any kind. + * + * These notices must be retained in any copies of any part of this + * documentation and/or software. */ + #include __FBSDID("$FreeBSD$"); -/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All - rights reserved. - - RSA Data Security, Inc. makes no representations concerning either - the merchantability of this software or the suitability of this - software for any particular purpose. It is provided "as is" - without express or implied warranty of any kind. - - These notices must be retained in any copies of any part of this - documentation and/or software. - */ - #include #include #include #include + #include "ripemd.h" -/* Digests a string and prints the result. - */ -static void RIPEMD160String (string) -char *string; +/* Digests a string and prints the result. */ +static void +RIPEMD160String(char *string) { - char buf[2*20+1]; + char buf[2*20 + 1]; - printf ("RIPEMD160 (\"%s\") = %s\n", - string, RIPEMD160_Data(string,strlen(string),buf)); + printf("RIPEMD160 (\"%s\") = %s\n", + string, RIPEMD160_Data(string, strlen(string), buf)); } -/* Digests a reference suite of strings and prints the results. - */ -main() +/* Digests a reference suite of strings and prints the results. */ +int +main(void) { - printf ("RIPEMD160 test suite:\n"); + printf("RIPEMD160 test suite:\n"); - RIPEMD160String (""); - RIPEMD160String ("abc"); - RIPEMD160String ("message digest"); - RIPEMD160String ("abcdefghijklmnopqrstuvwxyz"); - RIPEMD160String - ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"); - RIPEMD160String - ("1234567890123456789012345678901234567890\ -1234567890123456789012345678901234567890"); - return 0; + RIPEMD160String(""); + RIPEMD160String("abc"); + RIPEMD160String("message digest"); + RIPEMD160String("abcdefghijklmnopqrstuvwxyz"); + RIPEMD160String("ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz0123456789"); + RIPEMD160String("1234567890123456789012345678901234567890" + "1234567890123456789012345678901234567890"); + + return 0; } Index: lib/libmd/mddriver.c =================================================================== --- lib/libmd/mddriver.c (revision 236892) +++ lib/libmd/mddriver.c (working copy) @@ -1,33 +1,31 @@ -/* MDDRIVER.C - test driver for MD2, MD4 and MD5 - */ +/* MDDRIVER.C - test driver for MD2, MD4 and MD5 */ +/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All rights + * reserved. + * + * RSA Data Security, Inc. makes no representations concerning either the + * merchantability of this software or the suitability of this software for + * any particular purpose. It is provided "as is" without express or implied + * warranty of any kind. + * + * These notices must be retained in any copies of any part of this + * documentation and/or software. */ + #include __FBSDID("$FreeBSD$"); -/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All - rights reserved. +#include - RSA Data Security, Inc. makes no representations concerning either - the merchantability of this software or the suitability of this - software for any particular purpose. It is provided "as is" - without express or implied warranty of any kind. +#include +#include +#include - These notices must be retained in any copies of any part of this - documentation and/or software. - */ - -/* The following makes MD default to MD5 if it has not already been - defined with C compiler flags. - */ +/* The following makes MD default to MD5 if it has not already been defined + * with C compiler flags. */ #ifndef MD #define MD 5 #endif -#include - -#include -#include -#include #if MD == 2 #include "md2.h" #define MDData MD2Data @@ -41,32 +39,31 @@ #define MDData MD5Data #endif -/* Digests a string and prints the result. - */ -static void MDString (string) -char *string; +/* Digests a string and prints the result. */ +static void +MDString(char *string) { - char buf[33]; + char buf[33]; - printf ("MD%d (\"%s\") = %s\n", - MD, string, MDData(string,strlen(string),buf)); + printf("MD%d (\"%s\") = %s\n", + MD, string, MDData(string, strlen(string), buf)); } -/* Digests a reference suite of strings and prints the results. - */ -main() +/* Digests a reference suite of strings and prints the results. */ +int +main(void) { - printf ("MD%d test suite:\n", MD); + printf("MD%d test suite:\n", MD); - MDString (""); - MDString ("a"); - MDString ("abc"); - MDString ("message digest"); - MDString ("abcdefghijklmnopqrstuvwxyz"); - MDString - ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"); - MDString - ("1234567890123456789012345678901234567890\ -1234567890123456789012345678901234567890"); - return 0; + MDString(""); + MDString("a"); + MDString("abc"); + MDString("message digest"); + MDString("abcdefghijklmnopqrstuvwxyz"); + MDString("ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz0123456789"); + MDString("1234567890123456789012345678901234567890" + "1234567890123456789012345678901234567890"); + + return 0; } Index: lib/libmd/shadriver.c =================================================================== --- lib/libmd/shadriver.c (revision 236892) +++ lib/libmd/shadriver.c (working copy) @@ -1,66 +1,67 @@ -/* SHADRIVER.C - test driver for SHA-1 (and SHA-0) - */ +/* SHADRIVER.C - test driver for SHA-1 (and SHA-2) */ +/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All rights + * reserved. + * + * RSA Data Security, Inc. makes no representations concerning either the + * merchantability of this software or the suitability of this software for + * any particular purpose. It is provided "as is" without express or implied + * warranty of any kind. + * + * These notices must be retained in any copies of any part of this + * documentation and/or software. */ + #include __FBSDID("$FreeBSD$"); -/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All - rights reserved. +#include - RSA Data Security, Inc. makes no representations concerning either - the merchantability of this software or the suitability of this - software for any particular purpose. It is provided "as is" - without express or implied warranty of any kind. +#include +#include +#include - These notices must be retained in any copies of any part of this - documentation and/or software. - */ +#include "sha.h" +#include "sha256.h" +#include "sha512.h" /* The following makes SHA default to SHA-1 if it has not already been - defined with C compiler flags. - */ + * defined with C compiler flags. */ #ifndef SHA #define SHA 1 #endif -#include - -#include -#include -#include -#include "sha.h" -#include "sha256.h" #if SHA == 1 #define SHA_Data SHA1_Data #elif SHA == 256 #define SHA_Data SHA256_Data +#elif SHA == 512 +#define SHA_Data SHA512_Data #endif -/* Digests a string and prints the result. - */ -static void SHAString (string) -char *string; +/* Digests a string and prints the result. */ +static void +SHAString(char *string) { - char buf[2*32+1]; + char buf[2*64 + 1]; - printf ("SHA-%d (\"%s\") = %s\n", - SHA, string, SHA_Data(string,strlen(string),buf)); + printf("SHA-%d (\"%s\") = %s\n", + SHA, string, SHA_Data(string, strlen(string), buf)); } -/* Digests a reference suite of strings and prints the results. - */ -main() +/* Digests a reference suite of strings and prints the results. */ +int +main(void) { - printf ("SHA-%d test suite:\n", SHA); + printf("SHA-%d test suite:\n", SHA); - SHAString (""); - SHAString ("abc"); - SHAString ("message digest"); - SHAString ("abcdefghijklmnopqrstuvwxyz"); - SHAString - ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"); - SHAString - ("1234567890123456789012345678901234567890\ -1234567890123456789012345678901234567890"); - return 0; + SHAString(""); + SHAString("abc"); + SHAString("message digest"); + SHAString("abcdefghijklmnopqrstuvwxyz"); + SHAString("ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz0123456789"); + SHAString("1234567890123456789012345678901234567890" + "1234567890123456789012345678901234567890"); + + return 0; } --=-=-=-- From owner-freebsd-security@FreeBSD.ORG Tue Jun 12 11:58:20 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 790DA106566C for ; Tue, 12 Jun 2012 11:58:20 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C7FE98FC16 for ; Tue, 12 Jun 2012 11:58:19 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 137246C57; Tue, 12 Jun 2012 11:58:19 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E5C828055; Tue, 12 Jun 2012 13:58:18 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa In-Reply-To: <863961opy0.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon, 11 Jun 2012 16:58:47 +0200") References: <86r4tqotjo.fsf@ds4.des.no> <4FD334BE.4020900@sentex.net> <86ipeyp73q.fsf@ds4.des.no> <4FD5CF47.7070800@sentex.net> <867gvene35.fsf@ds4.des.no> <4FD5FCB3.80000@sentex.net> <863961opy0.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) Date: Tue, 12 Jun 2012 13:58:18 +0200 Message-ID: <86r4tklp2d.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-security@freebsd.org Subject: Re: Default password hash X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:58:20 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The attached patch backports support for sha256 and sha512 hashes to stable/7. It is not an exact MFH because the sha code in head uses stpncpy(), which is not present in stable/7's libc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=sha2-stable7.diff Index: lib/libcrypt =================================================================== --- lib/libcrypt (revision 236892) +++ lib/libcrypt (working copy) Property changes on: lib/libcrypt ___________________________________________________________________ Added: svn:mergeinfo Merged /head/gnu/libcrypt:r183242 Merged /head/lib/libcrypt:r179308,183242,213738,213814,213903,216591,220497-220498,221142,221471,227006,234132 Index: lib/libcrypt/crypt.c =================================================================== --- lib/libcrypt/crypt.c (revision 236892) +++ lib/libcrypt/crypt.c (working copy) @@ -63,6 +63,16 @@ "$3$" }, { + "sha256", + crypt_sha256, + "$5$" + }, + { + "sha512", + crypt_sha512, + "$6$" + }, + { NULL, NULL, NULL Index: lib/libcrypt/crypt-sha512.c =================================================================== --- lib/libcrypt/crypt-sha512.c (working copy) +++ lib/libcrypt/crypt-sha512.c (working copy) @@ -60,7 +60,7 @@ #define ROUNDS_MAX 999999999 static char * -sha512_crypt_r(const char *key, const char *salt, char *buffer, int buflen) +crypt_sha512_r(const char *key, const char *salt, char *buffer, int buflen) { u_long srounds; int n; @@ -210,7 +210,9 @@ /* Now we can construct the result string. It consists of three * parts. */ - cp = stpncpy(buffer, sha512_salt_prefix, MAX(0, buflen)); + cp = buffer; + strncpy(buffer, sha512_salt_prefix, MAX(0, buflen)); + cp += sizeof(sha512_salt_prefix) - 1; buflen -= sizeof(sha512_salt_prefix) - 1; if (rounds_custom) { @@ -221,7 +223,8 @@ buflen -= n; } - cp = stpncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len)); + strncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len)); + cp += MIN((size_t)MAX(0, buflen), salt_len); buflen -= MIN((size_t)MAX(0, buflen), salt_len); if (buflen > 0) { @@ -280,12 +283,12 @@ /* This entry point is equivalent to crypt(3). */ char * -sha512_crypt(const char *key, const char *salt) +crypt_sha512(const char *key, const char *salt) { /* We don't want to have an arbitrary limit in the size of the * password. We can compute an upper bound for the size of the * result in advance and so we can prepare the buffer we pass to - * `sha512_crypt_r'. */ + * `crypt_sha512_r'. */ static char *buffer; static int buflen; int needed; @@ -305,7 +308,7 @@ buflen = needed; } - return sha512_crypt_r(key, salt, buffer, buflen); + return crypt_sha512_r(key, salt, buffer, buflen); } #ifdef TEST @@ -482,7 +485,7 @@ } for (cnt = 0; cnt < ntests2; ++cnt) { - char *cp = sha512_crypt(tests2[cnt].input, tests2[cnt].salt); + char *cp = crypt_sha512(tests2[cnt].input, tests2[cnt].salt); if (strcmp(cp, tests2[cnt].expected) != 0) { printf("test %d: expected \"%s\", got \"%s\"\n", Index: lib/libcrypt/crypt.h =================================================================== --- lib/libcrypt/crypt.h (revision 236892) +++ lib/libcrypt/crypt.h (working copy) @@ -36,5 +36,8 @@ char *crypt_md5(const char *pw, const char *salt); char *crypt_nthash(const char *pw, const char *salt); char *crypt_blowfish(const char *pw, const char *salt); +char *crypt_sha256 (const char *pw, const char *salt); +char *crypt_sha512 (const char *pw, const char *salt); extern void _crypt_to64(char *s, u_long v, int n); +extern void b64_from_24bit(uint8_t B2, uint8_t B1, uint8_t B0, int n, int *buflen, char **cp); Index: lib/libcrypt/crypt-sha256.c =================================================================== --- lib/libcrypt/crypt-sha256.c (working copy) +++ lib/libcrypt/crypt-sha256.c (working copy) @@ -60,7 +60,7 @@ #define ROUNDS_MAX 999999999 static char * -sha256_crypt_r(const char *key, const char *salt, char *buffer, int buflen) +crypt_sha256_r(const char *key, const char *salt, char *buffer, int buflen) { u_long srounds; int n; @@ -210,7 +210,9 @@ /* Now we can construct the result string. It consists of three * parts. */ - cp = stpncpy(buffer, sha256_salt_prefix, MAX(0, buflen)); + cp = buffer; + strncpy(buffer, sha256_salt_prefix, MAX(0, buflen)); + cp += sizeof(sha256_salt_prefix) - 1; buflen -= sizeof(sha256_salt_prefix) - 1; if (rounds_custom) { @@ -221,7 +223,8 @@ buflen -= n; } - cp = stpncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len)); + strncpy(cp, salt, MIN((size_t)MAX(0, buflen), salt_len)); + cp += MIN((size_t)MAX(0, buflen), salt_len); buflen -= MIN((size_t)MAX(0, buflen), salt_len); if (buflen > 0) { @@ -268,12 +271,12 @@ /* This entry point is equivalent to crypt(3). */ char * -sha256_crypt(const char *key, const char *salt) +crypt_sha256(const char *key, const char *salt) { /* We don't want to have an arbitrary limit in the size of the * password. We can compute an upper bound for the size of the * result in advance and so we can prepare the buffer we pass to - * `sha256_crypt_r'. */ + * `crypt_sha256_r'. */ static char *buffer; static int buflen; int needed; @@ -293,7 +296,7 @@ buflen = needed; } - return sha256_crypt_r(key, salt, buffer, buflen); + return crypt_sha256_r(key, salt, buffer, buflen); } #ifdef TEST @@ -459,7 +462,7 @@ } for (cnt = 0; cnt < ntests2; ++cnt) { - char *cp = sha256_crypt(tests2[cnt].input, tests2[cnt].salt); + char *cp = crypt_sha256(tests2[cnt].input, tests2[cnt].salt); if (strcmp(cp, tests2[cnt].expected) != 0) { printf("test %d: expected \"%s\", got \"%s\"\n", Index: lib/libcrypt/crypt.3 =================================================================== --- lib/libcrypt/crypt.3 (revision 236892) +++ lib/libcrypt/crypt.3 (working copy) @@ -29,7 +29,7 @@ .\" .\" $FreeBSD$ .\" -.Dd January 19, 1997 +.Dd April 9, 2011 .Dt CRYPT 3 .Os .Sh NAME @@ -188,6 +188,12 @@ Blowfish .It NT-Hash +.It +(unused) +.It +SHA-256 +.It +SHA-512 .El .Pp Other crypt formats may be easily added. @@ -226,7 +232,9 @@ .\" .Ql des , .Ql blf , -.Ql md5 +.Ql md5 , +.Ql sha256 , +.Ql sha512 and .Ql nth . .Pp Index: lib/libcrypt/misc.c =================================================================== --- lib/libcrypt/misc.c (revision 236892) +++ lib/libcrypt/misc.c (working copy) @@ -45,3 +45,19 @@ v >>= 6; } } + +void +b64_from_24bit(uint8_t B2, uint8_t B1, uint8_t B0, int n, int *buflen, char **cp) +{ + uint32_t w; + int i; + + w = (B2 << 16) | (B1 << 8) | B0; + for (i = 0; i < n; i++) { + **cp = itoa64[w&0x3f]; + (*cp)++; + if ((*buflen)-- < 0) + break; + w >>= 6; + } +} Index: lib/libcrypt/Makefile =================================================================== --- lib/libcrypt/Makefile (revision 236892) +++ lib/libcrypt/Makefile (working copy) @@ -12,7 +12,9 @@ .PATH: ${.CURDIR}/../libmd SRCS= crypt.c misc.c \ crypt-md5.c md5c.c \ - crypt-nthash.c md4c.c + crypt-nthash.c md4c.c \ + crypt-sha256.c sha256c.c \ + crypt-sha512.c sha512c.c MAN= crypt.3 MLINKS= crypt.3 crypt_get_format.3 crypt.3 crypt_set_format.3 CFLAGS+= -I${.CURDIR}/../libmd -I${.CURDIR}/../libutil @@ -29,7 +31,9 @@ SRCS+= auth.c property.c .for sym in auth_getval property_find properties_read properties_free \ MD4Init MD4Final MD4Update MD4Pad \ - MD5Init MD5Final MD5Update MD5Pad + MD5Init MD5Final MD5Update MD5Pad \ + SHA256_Init SHA256_Final SHA256_Update \ + SHA512_Init SHA512_Final SHA512_Update CFLAGS+= -D${sym}=__${sym} .endfor Index: lib/libmd =================================================================== --- lib/libmd (revision 236892) +++ lib/libmd (working copy) Property changes on: lib/libmd ___________________________________________________________________ Added: svn:mergeinfo Merged /head/gnu/libmd:r183242 Merged /head/lib/libmd:r179308,183242,213738,213814,213903,216591,220496,223582,227006 Index: lib/libmd/sha512.3 =================================================================== --- lib/libmd/sha512.3 (working copy) +++ lib/libmd/sha512.3 (working copy) @@ -127,7 +127,7 @@ .Xr sha 3 .Sh HISTORY These functions appeared in -.Fx 4.0 . +.Fx 9.0 . .Sh AUTHORS The core hash routines were implemented by Colin Percival based on the published Index: lib/libmd/sha256.3 =================================================================== --- lib/libmd/sha256.3 (revision 236892) +++ lib/libmd/sha256.3 (working copy) @@ -127,7 +127,7 @@ .Xr sha 3 .Sh HISTORY These functions appeared in -.Fx 4.0 . +.Fx 6.0 . .Sh AUTHORS The core hash routines were implemented by Colin Percival based on the published Index: lib/libmd/Makefile =================================================================== --- lib/libmd/Makefile (revision 236892) +++ lib/libmd/Makefile (working copy) @@ -5,10 +5,11 @@ SRCS= md2c.c md4c.c md5c.c md2hl.c md4hl.c md5hl.c \ rmd160c.c rmd160hl.c \ sha0c.c sha0hl.c sha1c.c sha1hl.c \ - sha256c.c sha256hl.c -INCS= md2.h md4.h md5.h ripemd.h sha.h sha256.h + sha256c.c sha256hl.c \ + sha512c.c sha512hl.c +INCS= md2.h md4.h md5.h ripemd.h sha.h sha256.h sha512.h -MAN+= md2.3 md4.3 md5.3 ripemd.3 sha.3 sha256.3 +MAN+= md2.3 md4.3 md5.3 ripemd.3 sha.3 sha256.3 sha512.3 MLINKS+=md2.3 MD2Init.3 md2.3 MD2Update.3 md2.3 MD2Final.3 MLINKS+=md2.3 MD2End.3 md2.3 MD2File.3 md2.3 MD2FileChunk.3 MLINKS+=md2.3 MD2Data.3 @@ -32,10 +33,15 @@ MLINKS+=sha256.3 SHA256_Final.3 sha256.3 SHA256_End.3 MLINKS+=sha256.3 SHA256_File.3 sha256.3 SHA256_FileChunk.3 MLINKS+=sha256.3 SHA256_Data.3 +MLINKS+=sha512.3 SHA512_Init.3 sha512.3 SHA512_Update.3 +MLINKS+=sha512.3 SHA512_Final.3 sha512.3 SHA512_End.3 +MLINKS+=sha512.3 SHA512_File.3 sha512.3 SHA512_FileChunk.3 +MLINKS+=sha512.3 SHA512_Data.3 CLEANFILES+= md[245]hl.c md[245].ref md[245].3 mddriver \ rmd160.ref rmd160hl.c rmddriver \ sha0.ref sha0hl.c sha1.ref sha1hl.c shadriver \ - sha256.ref sha256hl.c + sha256.ref sha256hl.c sha512.ref sha512hl.c + CFLAGS+= -I${.CURDIR} .PATH: ${.CURDIR}/${MACHINE_ARCH} @@ -76,6 +82,12 @@ -e 's/SHA256__/SHA256_/g' \ ${.ALLSRC}) > ${.TARGET} +sha512hl.c: mdXhl.c + (echo '#define LENGTH 64'; \ + sed -e 's/mdX/sha512/g' -e 's/MDX/SHA512_/g' \ + -e 's/SHA512__/SHA512_/g' \ + ${.ALLSRC}) > ${.TARGET} + rmd160hl.c: mdXhl.c (echo '#define LENGTH 20'; \ sed -e 's/mdX/ripemd/g' -e 's/MDX/RIPEMD160_/g' \ @@ -105,8 +117,10 @@ @echo 'MD4 ("abc") = a448017aaf21d8525fc10ae87aa6729d' >> ${.TARGET} @echo 'MD4 ("message digest") = d9130a8164549fe818874806e1c7014b' >> ${.TARGET} @echo 'MD4 ("abcdefghijklmnopqrstuvwxyz") = d79e1c308aa5bbcdeea8ed63df412da9' >> ${.TARGET} - @echo 'MD4 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") = 043f8582f241db351ce627e153e7f0e4' >> ${.TARGET} - @echo 'MD4 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") = e33b4ddc9c38f2199c3e7b164fcc0536' >> ${.TARGET} + @echo 'MD4 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + '043f8582f241db351ce627e153e7f0e4' >> ${.TARGET} + @echo 'MD4 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + 'e33b4ddc9c38f2199c3e7b164fcc0536' >> ${.TARGET} md5.ref: echo 'MD5 test suite:' > ${.TARGET} @@ -119,54 +133,74 @@ @echo 'MD5 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") = 57edf4a22be3c955ac49da2e2107b67a' >> ${.TARGET} sha0.ref: - (echo 'SHA-0 test suite:'; \ - echo 'SHA-0 ("") = f96cea198ad1dd5617ac084a3d92c6107708c0ef'; \ - echo 'SHA-0 ("abc") = 0164b8a914cd2a5e74c4f7ff082c4d97f1edf880'; \ - echo 'SHA-0 ("message digest") =' \ - 'c1b0f222d150ebb9aa36a40cafdc8bcbed830b14'; \ - echo 'SHA-0 ("abcdefghijklmnopqrstuvwxyz") =' \ - 'b40ce07a430cfd3c033039b9fe9afec95dc1bdcd'; \ - echo 'SHA-0 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ - '79e966f7a3a990df33e40e3d7f8f18d2caebadfa'; \ - echo 'SHA-0 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ - '4aa29d14d171522ece47bee8957e35a41f3e9cff' ) > ${.TARGET} + echo 'SHA-0 test suite:' > ${.TARGET} + @echo 'SHA-0 ("") = f96cea198ad1dd5617ac084a3d92c6107708c0ef' >> ${.TARGET} + @echo 'SHA-0 ("abc") = 0164b8a914cd2a5e74c4f7ff082c4d97f1edf880' >> ${.TARGET} + @echo 'SHA-0 ("message digest") =' \ + 'c1b0f222d150ebb9aa36a40cafdc8bcbed830b14' >> ${.TARGET} + @echo 'SHA-0 ("abcdefghijklmnopqrstuvwxyz") =' \ + 'b40ce07a430cfd3c033039b9fe9afec95dc1bdcd' >> ${.TARGET} + @echo 'SHA-0 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + '79e966f7a3a990df33e40e3d7f8f18d2caebadfa' >> ${.TARGET} + @echo 'SHA-0 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + '4aa29d14d171522ece47bee8957e35a41f3e9cff' >> ${.TARGET} sha1.ref: - (echo 'SHA-1 test suite:'; \ - echo 'SHA-1 ("") = da39a3ee5e6b4b0d3255bfef95601890afd80709'; \ - echo 'SHA-1 ("abc") = a9993e364706816aba3e25717850c26c9cd0d89d'; \ - echo 'SHA-1 ("message digest") =' \ - 'c12252ceda8be8994d5fa0290a47231c1d16aae3'; \ - echo 'SHA-1 ("abcdefghijklmnopqrstuvwxyz") =' \ - '32d10c7b8cf96570ca04ce37f2a19d84240d3a89'; \ - echo 'SHA-1 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ - '761c457bf73b14d27e9e9265c46f4b4dda11f940'; \ - echo 'SHA-1 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ - '50abf5706a150990a08b2c5ea40fa0e585554732' ) > ${.TARGET} + echo 'SHA-1 test suite:' > ${.TARGET} + @echo 'SHA-1 ("") = da39a3ee5e6b4b0d3255bfef95601890afd80709' >> ${.TARGET} + @echo 'SHA-1 ("abc") = a9993e364706816aba3e25717850c26c9cd0d89d' >> ${.TARGET} + @echo 'SHA-1 ("message digest") =' \ + 'c12252ceda8be8994d5fa0290a47231c1d16aae3' >> ${.TARGET} + @echo 'SHA-1 ("abcdefghijklmnopqrstuvwxyz") =' \ + '32d10c7b8cf96570ca04ce37f2a19d84240d3a89' >> ${.TARGET} + @echo 'SHA-1 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + '761c457bf73b14d27e9e9265c46f4b4dda11f940' >> ${.TARGET} + @echo 'SHA-1 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + '50abf5706a150990a08b2c5ea40fa0e585554732' >> ${.TARGET} sha256.ref: echo 'SHA-256 test suite:' > ${.TARGET} @echo 'SHA-256 ("") = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855' >> ${.TARGET} - @echo 'SHA-256 ("abc") = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad' >> ${.TARGET} - @echo 'SHA-256 ("message digest") = f7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650' >> ${.TARGET} - @echo 'SHA-256 ("abcdefghijklmnopqrstuvwxyz") = 71c480df93d6ae2f1efad1447c66c9525e316218cf51fc8d9ed832f2daf18b73' >> ${.TARGET} - @echo 'SHA-256 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") = db4bfcbd4da0cd85a60c3c37d3fbd8805c77f15fc6b1fdfe614ee0a7c8fdb4c0' >> ${.TARGET} - @echo 'SHA-256 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") = f371bc4a311f2b009eef952dd83ca80e2b60026c8e935592d0f9c308453c813e' >> ${.TARGET} + @echo 'SHA-256 ("abc") =' \ + 'ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad' >> ${.TARGET} + @echo 'SHA-256 ("message digest") =' \ + 'f7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650' >> ${.TARGET} + @echo 'SHA-256 ("abcdefghijklmnopqrstuvwxyz") =' \ + '71c480df93d6ae2f1efad1447c66c9525e316218cf51fc8d9ed832f2daf18b73' >> ${.TARGET} + @echo 'SHA-256 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + 'db4bfcbd4da0cd85a60c3c37d3fbd8805c77f15fc6b1fdfe614ee0a7c8fdb4c0' >> ${.TARGET} + @echo 'SHA-256 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + 'f371bc4a311f2b009eef952dd83ca80e2b60026c8e935592d0f9c308453c813e' >> ${.TARGET} +sha512.ref: + echo 'SHA-512 test suite:' > ${.TARGET} + @echo 'SHA-512 ("") =' \ + 'cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e' >> ${.TARGET} + @echo 'SHA-512 ("abc") =' \ + 'ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f' >> ${.TARGET} + @echo 'SHA-512 ("message digest") =' \ + '107dbf389d9e9f71a3a95f6c055b9251bc5268c2be16d6c13492ea45b0199f3309e16455ab1e96118e8a905d5597b72038ddb372a89826046de66687bb420e7c' >> ${.TARGET} + @echo 'SHA-512 ("abcdefghijklmnopqrstuvwxyz") =' \ + '4dbff86cc2ca1bae1e16468a05cb9881c97f1753bce3619034898faa1aabe429955a1bf8ec483d7421fe3c1646613a59ed5441fb0f321389f77f48a879c7b1f1' >> ${.TARGET} + @echo 'SHA-512 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + '1e07be23c26a86ea37ea810c8ec7809352515a970e9253c26f536cfc7a9996c45c8370583e0a78fa4a90041d71a4ceab7423f19c71b9d5a3e01249f0bebd5894' >> ${.TARGET} + @echo 'SHA-512 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + '72ec1ef1124a45b047e8b7c75a932195135bb61de24ec0d1914042246e0aec3a2354e093d76f3048b456764346900cb130d2a4fd5dd16abb5e30bcb850dee843' >> ${.TARGET} + rmd160.ref: - (echo 'RIPEMD160 test suite:'; \ - echo 'RIPEMD160 ("") = 9c1185a5c5e9fc54612808977ee8f548b2258d31'; \ - echo 'RIPEMD160 ("abc") = 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc'; \ - echo 'RIPEMD160 ("message digest") =' \ - '5d0689ef49d2fae572b881b123a85ffa21595f36'; \ - echo 'RIPEMD160 ("abcdefghijklmnopqrstuvwxyz") =' \ - 'f71c27109c692c1b56bbdceb5b9d2865b3708dbc'; \ - echo 'RIPEMD160 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ - 'b0e20b6e3116640286ed3a87a5713079b21f5189'; \ - echo 'RIPEMD160 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ - '9b752e45573d4b39f4dbd3323cab82bf63326bfb' ) > ${.TARGET} + echo 'RIPEMD160 test suite:' > ${.TARGET} + @echo 'RIPEMD160 ("") = 9c1185a5c5e9fc54612808977ee8f548b2258d31' >> ${.TARGET} + @echo 'RIPEMD160 ("abc") = 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc' >> ${.TARGET} + @echo 'RIPEMD160 ("message digest") =' \ + '5d0689ef49d2fae572b881b123a85ffa21595f36' >> ${.TARGET} + @echo 'RIPEMD160 ("abcdefghijklmnopqrstuvwxyz") =' \ + 'f71c27109c692c1b56bbdceb5b9d2865b3708dbc' >> ${.TARGET} + @echo 'RIPEMD160 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =' \ + 'b0e20b6e3116640286ed3a87a5713079b21f5189' >> ${.TARGET} + @echo 'RIPEMD160 ("12345678901234567890123456789012345678901234567890123456789012345678901234567890") =' \ + '9b752e45573d4b39f4dbd3323cab82bf63326bfb' >> ${.TARGET} -test: md2.ref md4.ref md5.ref sha0.ref rmd160.ref sha1.ref sha256.ref +test: md2.ref md4.ref md5.ref sha0.ref rmd160.ref sha1.ref sha256.ref sha512.ref @${ECHO} if any of these test fail, the code produces wrong results @${ECHO} and should NOT be used. ${CC} ${CFLAGS} ${LDFLAGS} -DMD=2 -o mddriver ${.CURDIR}/mddriver.c -L. -lmd @@ -192,6 +226,9 @@ ${CC} ${CFLAGS} ${LDFLAGS} -DSHA=256 -o shadriver ${.CURDIR}/shadriver.c -L. -lmd ./shadriver | cmp sha256.ref - @${ECHO} SHA-256 passed test + ${CC} ${CFLAGS} ${LDFLAGS} -DSHA=512 -o shadriver ${.CURDIR}/shadriver.c libmd.a + ./shadriver | cmp sha512.ref - + @${ECHO} SHA-512 passed test -rm -f shadriver .include Index: lib/libmd/rmddriver.c =================================================================== --- lib/libmd/rmddriver.c (revision 236892) +++ lib/libmd/rmddriver.c (working copy) @@ -1,53 +1,51 @@ -/* RIPEMD160DRIVER.C - test driver for RIPEMD160 - */ +/* RIPEMD160DRIVER.C - test driver for RIPEMD160 */ +/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All rights + * reserved. + * + * RSA Data Security, Inc. makes no representations concerning either the + * merchantability of this software or the suitability of this software for + * any particular purpose. It is provided "as is" without express or implied + * warranty of any kind. + * + * These notices must be retained in any copies of any part of this + * documentation and/or software. */ + #include __FBSDID("$FreeBSD$"); -/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All - rights reserved. - - RSA Data Security, Inc. makes no representations concerning either - the merchantability of this software or the suitability of this - software for any particular purpose. It is provided "as is" - without express or implied warranty of any kind. - - These notices must be retained in any copies of any part of this - documentation and/or software. - */ - #include #include #include #include + #include "ripemd.h" -/* Digests a string and prints the result. - */ -static void RIPEMD160String (string) -char *string; +/* Digests a string and prints the result. */ +static void +RIPEMD160String(char *string) { - char buf[2*20+1]; + char buf[2*20 + 1]; - printf ("RIPEMD160 (\"%s\") = %s\n", - string, RIPEMD160_Data(string,strlen(string),buf)); + printf("RIPEMD160 (\"%s\") = %s\n", + string, RIPEMD160_Data(string, strlen(string), buf)); } -/* Digests a reference suite of strings and prints the results. - */ -main() +/* Digests a reference suite of strings and prints the results. */ +int +main(void) { - printf ("RIPEMD160 test suite:\n"); + printf("RIPEMD160 test suite:\n"); - RIPEMD160String (""); - RIPEMD160String ("abc"); - RIPEMD160String ("message digest"); - RIPEMD160String ("abcdefghijklmnopqrstuvwxyz"); - RIPEMD160String - ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"); - RIPEMD160String - ("1234567890123456789012345678901234567890\ -1234567890123456789012345678901234567890"); - return 0; + RIPEMD160String(""); + RIPEMD160String("abc"); + RIPEMD160String("message digest"); + RIPEMD160String("abcdefghijklmnopqrstuvwxyz"); + RIPEMD160String("ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz0123456789"); + RIPEMD160String("1234567890123456789012345678901234567890" + "1234567890123456789012345678901234567890"); + + return 0; } Index: lib/libmd/mddriver.c =================================================================== --- lib/libmd/mddriver.c (revision 236892) +++ lib/libmd/mddriver.c (working copy) @@ -1,33 +1,31 @@ -/* MDDRIVER.C - test driver for MD2, MD4 and MD5 - */ +/* MDDRIVER.C - test driver for MD2, MD4 and MD5 */ +/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All rights + * reserved. + * + * RSA Data Security, Inc. makes no representations concerning either the + * merchantability of this software or the suitability of this software for + * any particular purpose. It is provided "as is" without express or implied + * warranty of any kind. + * + * These notices must be retained in any copies of any part of this + * documentation and/or software. */ + #include __FBSDID("$FreeBSD$"); -/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All - rights reserved. +#include - RSA Data Security, Inc. makes no representations concerning either - the merchantability of this software or the suitability of this - software for any particular purpose. It is provided "as is" - without express or implied warranty of any kind. +#include +#include +#include - These notices must be retained in any copies of any part of this - documentation and/or software. - */ - -/* The following makes MD default to MD5 if it has not already been - defined with C compiler flags. - */ +/* The following makes MD default to MD5 if it has not already been defined + * with C compiler flags. */ #ifndef MD #define MD 5 #endif -#include - -#include -#include -#include #if MD == 2 #include "md2.h" #define MDData MD2Data @@ -41,32 +39,31 @@ #define MDData MD5Data #endif -/* Digests a string and prints the result. - */ -static void MDString (string) -char *string; +/* Digests a string and prints the result. */ +static void +MDString(char *string) { - char buf[33]; + char buf[33]; - printf ("MD%d (\"%s\") = %s\n", - MD, string, MDData(string,strlen(string),buf)); + printf("MD%d (\"%s\") = %s\n", + MD, string, MDData(string, strlen(string), buf)); } -/* Digests a reference suite of strings and prints the results. - */ -main() +/* Digests a reference suite of strings and prints the results. */ +int +main(void) { - printf ("MD%d test suite:\n", MD); + printf("MD%d test suite:\n", MD); - MDString (""); - MDString ("a"); - MDString ("abc"); - MDString ("message digest"); - MDString ("abcdefghijklmnopqrstuvwxyz"); - MDString - ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"); - MDString - ("1234567890123456789012345678901234567890\ -1234567890123456789012345678901234567890"); - return 0; + MDString(""); + MDString("a"); + MDString("abc"); + MDString("message digest"); + MDString("abcdefghijklmnopqrstuvwxyz"); + MDString("ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz0123456789"); + MDString("1234567890123456789012345678901234567890" + "1234567890123456789012345678901234567890"); + + return 0; } Index: lib/libmd/shadriver.c =================================================================== --- lib/libmd/shadriver.c (revision 236892) +++ lib/libmd/shadriver.c (working copy) @@ -1,66 +1,67 @@ -/* SHADRIVER.C - test driver for SHA-1 (and SHA-0) - */ +/* SHADRIVER.C - test driver for SHA-1 (and SHA-2) */ +/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All rights + * reserved. + * + * RSA Data Security, Inc. makes no representations concerning either the + * merchantability of this software or the suitability of this software for + * any particular purpose. It is provided "as is" without express or implied + * warranty of any kind. + * + * These notices must be retained in any copies of any part of this + * documentation and/or software. */ + #include __FBSDID("$FreeBSD$"); -/* Copyright (C) 1990-2, RSA Data Security, Inc. Created 1990. All - rights reserved. +#include - RSA Data Security, Inc. makes no representations concerning either - the merchantability of this software or the suitability of this - software for any particular purpose. It is provided "as is" - without express or implied warranty of any kind. +#include +#include +#include - These notices must be retained in any copies of any part of this - documentation and/or software. - */ +#include "sha.h" +#include "sha256.h" +#include "sha512.h" /* The following makes SHA default to SHA-1 if it has not already been - defined with C compiler flags. - */ + * defined with C compiler flags. */ #ifndef SHA #define SHA 1 #endif -#include - -#include -#include -#include -#include "sha.h" -#include "sha256.h" #if SHA == 1 #define SHA_Data SHA1_Data #elif SHA == 256 #define SHA_Data SHA256_Data +#elif SHA == 512 +#define SHA_Data SHA512_Data #endif -/* Digests a string and prints the result. - */ -static void SHAString (string) -char *string; +/* Digests a string and prints the result. */ +static void +SHAString(char *string) { - char buf[2*32+1]; + char buf[2*64 + 1]; - printf ("SHA-%d (\"%s\") = %s\n", - SHA, string, SHA_Data(string,strlen(string),buf)); + printf("SHA-%d (\"%s\") = %s\n", + SHA, string, SHA_Data(string, strlen(string), buf)); } -/* Digests a reference suite of strings and prints the results. - */ -main() +/* Digests a reference suite of strings and prints the results. */ +int +main(void) { - printf ("SHA-%d test suite:\n", SHA); + printf("SHA-%d test suite:\n", SHA); - SHAString (""); - SHAString ("abc"); - SHAString ("message digest"); - SHAString ("abcdefghijklmnopqrstuvwxyz"); - SHAString - ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"); - SHAString - ("1234567890123456789012345678901234567890\ -1234567890123456789012345678901234567890"); - return 0; + SHAString(""); + SHAString("abc"); + SHAString("message digest"); + SHAString("abcdefghijklmnopqrstuvwxyz"); + SHAString("ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz0123456789"); + SHAString("1234567890123456789012345678901234567890" + "1234567890123456789012345678901234567890"); + + return 0; } --=-=-=-- From owner-freebsd-security@FreeBSD.ORG Tue Jun 12 13:25:23 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53168106567B; Tue, 12 Jun 2012 13:25:23 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3B64D8FC1B; Tue, 12 Jun 2012 13:25:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5CDPN2T078475; Tue, 12 Jun 2012 13:25:23 GMT (envelope-from security-advisories@freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5CDPNOo078473; Tue, 12 Jun 2012 13:25:23 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 12 Jun 2012 13:25:23 GMT Message-Id: <201206121325.q5CDPNOo078473@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: bz set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Cc: Subject: FreeBSD Security Advisory FreeBSD-SA-12:03.bind X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 13:25:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-12:03.bind Security Advisory The FreeBSD Project Topic: Incorrect handling of zero-length RDATA fields in named(8) Category: contrib Module: bind Announced: 2012-06-12 Credits: Dan Luther, Jeffrey A. Spain Affects: All supported versions of FreeBSD Corrected: 2012-06-12 12:10:10 UTC (RELENG_7, 7.4-STABLE) 2012-06-12 12:10:10 UTC (RELENG_7_4, 7.4-RELEASE-p9) 2012-06-04 22:21:55 UTC (RELENG_8, 8.3-STABLE) 2012-06-12 12:10:10 UTC (RELENG_8_3, 8.3-RELEASE-p3) 2012-06-12 12:10:10 UTC (RELENG_8_2, 8.2-RELEASE-p9) 2012-06-12 12:10:10 UTC (RELENG_8_1, 8.1-RELEASE-p11) 2012-06-04 22:14:33 UTC (RELENG_9, 9.0-STABLE) 2012-06-12 12:10:10 UTC (RELENG_9_0, 9.0-RELEASE-p3) CVE Name: CVE-2012-1667 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background BIND 9 is an implementation of the Domain Name System (DNS) protocols. The named(8) daemon is an Internet Domain Name Server. II. Problem Description The named(8) server does not properly handle DNS resource records where the RDATA field is zero length, which may cause various issues for the servers handling them. III. Impact Resolving servers may crash or disclose some portion of memory to the client. Authoritative servers may crash on restart after transferring a zone containing records with zero-length RDATA fields. These would result in a denial of service, or leak of sensitive information. IV. Workaround No workaround is available, but systems not running the BIND name server are not affected. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 7-STABLE, 8-STABLE, or 9-STABLE, or to the RELENG_7_4, RELENG_8_3, RELENG_8_2, RELENG_8_1, or RELENG_9_0 security branch dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to FreeBSD 7.4, 8.3, 8.2, 8.1 and 9.0 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 7.4-RELEASE, 8.3-RELEASE, 8.2-RELEASE, and 8.1-RELEASE] # fetch http://security.FreeBSD.org/patches/SA-12:03/bind.patch # fetch http://security.FreeBSD.org/patches/SA-12:03/bind.patch.asc [FreeBSD 9.0-RELEASE] # fetch http://security.FreeBSD.org/patches/SA-12:03/bind-90.patch # fetch http://security.FreeBSD.org/patches/SA-12:03/bind-90.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/lib/bind/ # make obj && make depend && make && make install # cd /usr/src/usr.sbin/named # make obj && make depend && make && make install 3) To update your vulnerable system via a binary patch: Systems running 7.4-RELEASE, 8.3-RELEASE, 8.2-RELEASE, 8.1-RELEASE, or 9.0-RELEASE on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 4) Install and run BIND from the Ports Collection after the correction date. The following versions and newer versions of BIND installed from the Ports Collection are not affected by this vulnerability: bind96-9.6.3.1.ESV.R7.1 bind97-9.7.6.1 bind98-9.8.3.1 bind99-9.9.1.1 VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - ------------------------------------------------------------------------- RELENG_7 src/contrib/bind9/lib/dns/rdata.c 1.1.1.5.2.4 src/contrib/bind9/lib/dns/rdataslab.c 1.1.1.2.2.5 RELENG_7_4 src/UPDATING 1.507.2.36.2.11 src/sys/conf/newvers.sh 1.72.2.18.2.14 src/contrib/bind9/lib/dns/rdata.c 1.1.1.5.2.1.2.1 src/contrib/bind9/lib/dns/rdataslab.c 1.1.1.2.2.3.2.1 RELENG_8 src/contrib/bind9/lib/dns/rdata.c 1.2.2.4 src/contrib/bind9/lib/dns/rdataslab.c 1.2.2.5 RELENG_8_3 src/UPDATING 1.632.2.26.2.5 src/sys/conf/newvers.sh 1.83.2.15.2.7 src/contrib/bind9/lib/dns/rdata.c 1.2.2.2.2.1 src/contrib/bind9/lib/dns/rdataslab.c 1.2.2.3.2.1 RELENG_8_2 src/UPDATING 1.632.2.19.2.11 src/sys/conf/newvers.sh 1.83.2.12.2.14 src/contrib/bind9/lib/dns/rdata.c 1.2.8.1 src/contrib/bind9/lib/dns/rdataslab.c 1.2.2.2.2.1 RELENG_8_1 src/UPDATING 1.632.2.14.2.14 src/sys/conf/newvers.sh 1.83.2.10.2.15 src/contrib/bind9/lib/dns/rdata.c 1.2.6.1 src/contrib/bind9/lib/dns/rdataslab.c 1.2.2.1.2.1 RELENG_9 src/contrib/bind9/lib/dns/rdata.c 1.5.2.2 src/contrib/bind9/lib/dns/rdataslab.c 1.7.2.2 RELENG_9_0 src/UPDATING 1.702.2.4.2.5 src/sys/conf/newvers.sh 1.95.2.4.2.7 src/contrib/bind9/lib/dns/rdata.c 1.5.4.1 src/contrib/bind9/lib/dns/rdataslab.c 1.7.4.1 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- stable/7/ r236953 releng/7.4/ r236953 stable/8/ r236590 releng/8.3/ r236953 releng/8.2/ r236953 releng/8.1/ r236953 stable/9/ r236587 releng/9.0/ r236953 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1667 http://www.isc.org/software/bind/advisories/cve-2012-1667 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-12:03.bind.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/XQGEACgkQFdaIBMps37LU+gCfcP1MdQy8s5gjNWJfW+BiP6oI CWkAnRZzIRxAKWgD2spPAuBu04S9ZQkA =aI2g -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jun 12 13:26:33 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A517610657B4; Tue, 12 Jun 2012 13:26:33 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8DCC98FC1D; Tue, 12 Jun 2012 13:26:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5CDQX9N078538; Tue, 12 Jun 2012 13:26:33 GMT (envelope-from security-advisories@freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5CDQXca078536; Tue, 12 Jun 2012 13:26:33 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 12 Jun 2012 13:26:33 GMT Message-Id: <201206121326.q5CDQXca078536@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: bz set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Cc: Subject: FreeBSD Security Advisory FreeBSD-SA-12:04.sysret X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 13:26:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-12:04.sysret Security Advisory The FreeBSD Project Topic: Privilege escalation when returning from kernel Category: core Module: sys_amd64 Announced: 2012-06-12 Credits: Rafal Wojtczuk, John Baldwin Affects: All supported versions of FreeBSD Corrected: 2012-06-12 12:10:10 UTC (RELENG_7, 7.4-STABLE) 2012-06-12 12:10:10 UTC (RELENG_7_4, 7.4-RELEASE-p9) 2012-06-12 12:10:10 UTC (RELENG_8, 8.3-STABLE) 2012-06-12 12:10:10 UTC (RELENG_8_3, 8.3-RELEASE-p3) 2012-06-12 12:10:10 UTC (RELENG_8_2, 8.2-RELEASE-p9) 2012-06-12 12:10:10 UTC (RELENG_8_1, 8.1-RELEASE-p11) 2012-06-12 12:10:10 UTC (RELENG_9, 9.0-STABLE) 2012-06-12 12:10:10 UTC (RELENG_9_0, 9.0-RELEASE-p3) CVE Name: CVE-2012-0217 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The FreeBSD operating system implements a rings model of security, where privileged operations are done in the kernel, and most applications request access to these operations by making a system call, which puts the CPU into the required privilege level and passes control to the kernel. II. Problem Description FreeBSD/amd64 runs on CPUs from different vendors. Due to varying behaviour of CPUs in 64 bit mode a sanity check of the kernel may be insufficient when returning from a system call. III. Impact Successful exploitation of the problem can lead to local kernel privilege escalation, kernel data corruption and/or crash. To exploit this vulnerability, an attacker must be able to run code with user privileges on the target system. IV. Workaround No workaround is available. However FreeBSD/amd64 running on AMD CPUs is not vulnerable to this particular problem. Systems with 64 bit capable CPUs, but running the 32 bit FreeBSD/i386 kernel are not vulnerable, nor are systems running on different processor architectures. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 7-STABLE, 8-STABLE, or 9-STABLE, or to the RELENG_7_4, RELENG_8_3, RELENG_8_2, RELENG_8_1, or RELENG_9_0 security branch dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to FreeBSD 7.4, 8.3, 8.2, 8.1 and 9.0 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-12:04/sysret.patch # fetch http://security.FreeBSD.org/patches/SA-12:04/sysret.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. 3) To update your vulnerable system via a binary patch: Systems running 7.4-RELEASE, 8.3-RELEASE, 8.2-RELEASE, 8.1-RELEASE, or 9.0-RELEASE on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - ------------------------------------------------------------------------- RELENG_7 src/sys/amd64/amd64/trap.c 1.319.2.14 RELENG_7_4 src/UPDATING 1.507.2.36.2.11 src/sys/conf/newvers.sh 1.72.2.18.2.14 src/sys/amd64/amd64/trap.c 1.319.2.12.2.2 RELENG_8 src/sys/amd64/amd64/trap.c 1.332.2.24 RELENG_8_3 src/UPDATING 1.632.2.26.2.5 src/sys/conf/newvers.sh 1.83.2.15.2.7 src/sys/amd64/amd64/trap.c 1.332.2.21.2.2 RELENG_8_2 src/UPDATING 1.632.2.19.2.11 src/sys/conf/newvers.sh 1.83.2.12.2.14 src/sys/amd64/amd64/trap.c 1.332.2.14.2.2 RELENG_8_1 src/UPDATING 1.632.2.14.2.14 src/sys/conf/newvers.sh 1.83.2.10.2.15 src/sys/amd64/amd64/trap.c 1.332.2.10.2.2 RELENG_9 src/sys/amd64/amd64/trap.c 1.357.2.9 RELENG_9_0 src/UPDATING 1.702.2.4.2.5 src/sys/conf/newvers.sh 1.95.2.4.2.7 src/sys/amd64/amd64/trap.c 1.357.2.2.2.3 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- stable/7/ r236953 releng/7.4/ r236953 stable/8/ r236953 releng/8.3/ r236953 releng/8.2/ r236953 releng/8.1/ r236953 stable/9/ r236953 releng/9.0/ r236953 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0217 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-12:04.sysret.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/XQGgACgkQFdaIBMps37KCsACdEvLcb0JhWKmVlvq5SuKzuW1Q fhsAnRVLFoGa2WGnRpfQrLYCjL9gs8Rd =RvZd -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jun 12 17:40:03 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 218A41065670 for ; Tue, 12 Jun 2012 17:40:03 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A64598FC15 for ; Tue, 12 Jun 2012 17:40:02 +0000 (UTC) Received: by yhgm50 with SMTP id m50so4211153yhg.13 for ; Tue, 12 Jun 2012 10:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:content-transfer-encoding; bh=VcbCFsi6Tu0ycc4zcVPiJB/ios3RtJgDRtB138bId8s=; b=fYp4Z9tNkz8nUmkbt89kvgTKj17VRqLVVhe91RZ+FiF9LE5+DSdk87BaiJWq5lSfAl 7Rzk1HkneiFmH48PmjomS1Qa4m+16Yuifg5Pslr8eqEbZg3x94BPnsAxOzMwDtwL8lbv HUTSCRTqW3kqnKFqsPk59KEfIiWGAFbdFh4DM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:content-transfer-encoding:x-gm-message-state; bh=VcbCFsi6Tu0ycc4zcVPiJB/ios3RtJgDRtB138bId8s=; b=gdOj5Z8djDb9nKC15k2miQ1ULSr3l0oSLaKUjAE+xmh0PPxWOjHJjerVkrpl767S7i n21V0AC761ofa6JXeQ3hZp9wj6WF3h7xHZCFu64WIN5uOe+gLJ0wlWTUmh18KytLDac0 /fi7lB3OrvtY8n1y/hBmmevIxwvFxoBuL0l6yBM5isW+pVwXVEqavSJssXUOeStmGdA5 yDkIJLGIkTA87TcZLIXTtvUUyowRQxpJrxl0wmjVRx61kqfdoDVav1WxhEEORJL/v30n 4gD0qrHRbQfbFGcevRqysgScwSnppiyR1jbhNlV/8XoZxDYLfiUl6v8RAMwZMzO+TNhZ SOMw== Received: by 10.101.131.14 with SMTP id i14mr8700399ann.44.1339522802077; Tue, 12 Jun 2012 10:40:02 -0700 (PDT) Received: from DataIX.net (75-128-120-86.dhcp.aldl.mi.charter.com. [75.128.120.86]) by mx.google.com with ESMTPS id z19sm23632anh.22.2012.06.12.10.40.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jun 2012 10:40:01 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q5CHdxcw087908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2012 13:39:59 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q5CHdxUm087907; Tue, 12 Jun 2012 13:39:59 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Tue, 12 Jun 2012 13:39:58 -0400 From: Jason Hellenthal To: freebsd-security@freebsd.org Message-ID: <20120612173958.GA78172@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnZGmYDJT1GzXPQvxmnnfuCTMcWtQkswlvcNIFFJKKEuVo812hPbk2MkBTxwbcfGiEyyBqn Cc: freebsd-ports@freebsd.org Subject: [0x721427d8@gmail.com: [php<=5.4.3] Parsing Bug in PHP PDO prepared statements may lead to access violation] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:40:03 -0000 FYI I verified this on a working system. ----- Forwarded message from 0x721427D8 0x721427D8 <0x721427d8@gmail.com> ----- Date: Sun, 10 Jun 2012 15:02:43 +0200 From: 0x721427D8 0x721427D8 <0x721427d8@gmail.com> To: bugtraq@securityfocus.com Subject: [php<=5.4.3] Parsing Bug in PHP PDO prepared statements may lead to access violation [php<=5.4.3] Parsing Bug in PHP PDO prepared statements may lead to access violation Affected Product:     PHP Affected Component:   PDO - PHP Data Objects Affected Versions:    <=5.4.3 (latest version and trunk) PHP Bug Ref:          #61755 Patch:                bug61755.diff Discovery Date:       Feb 2012 Advisory Date:        2012-06-10 Description: ------------ Inconsistent parsing of PHP PDO prepared statements. Erroneous design of parsers state machine. Under special circumstances parsing of prepared statements does not stop leading in cycling the whole stack without terminating on \0. This leads to access violations, accessing of stack data, DoS. Bug Description: ---------------- There are several design errors in the state-machine responsible for parsing PHP PDO based statement objects. These errors are based on the state-machines inability to consistently check the supplied SQL-Query. Under special circumstances an attacker is able to force the responsible PDO code to iterate beyond the termination of the supplied query string resulting in a buffer out of bounds access. This access may lead to uncontrollable as well as attacker controllable behavior and Access Violations caused by the code iterating the whole stack and trying to access addresses beyond the stack end. In very unlikely and constructed environments it may also be possible to force parameter rebinding of prepared statements - even though some context specific input filtering is applied - by utilizing the stack cycling behavior of the state machine. This can be accomplished by 1) pushing a manipulated SQL string containing fake parameter bindings (:named:, ?) onto the stack (e.g. using post variables) 2) manipulating the main SQL query string (see preconditions) to make the pdo_parser cycle the stack 3) until it cycles into the fake query previously pushed to stack where the magic happens. This forces the state machine into cycling into random stack data and then into the previously pushed manipulated SQL string with fake parameter bindings. To finalize this attack the manipulated SQL string then terminates the SQL parsing resulting in rebinding of prepared parameters. The attacker needs to know the original binding names (for named parameters) and the number of bound params for this attack to succeed. This scenario is unlikely to occur but as usual in computer security this may be used in conjunction with other attacks to multiply the impact. Preconditions: -------------- * PDO is used to access the DB * For remote attacks: User must be able to directly control any part of the query string prior its preparation (stm->prepare()). We are well aware that this is a general coding fault which leads to other security relevant implications but sadly enough it’s also quite common in many frameworks, projects to use prepared statements with user controlled data instead of binding them after preparation. State-Machine Graph, Test-Scripts, Traces, PoCs are available. Vendor Response: ---------------- * Patch 2012-04-19 (bug61755.diff) (see php bugref) Patch available, but still not fixed in 5.4.3 (latest) Timeline: --------- * 2012 Feb   - Discovered in 5.3.8, verified for 5.3.0/5.3.10 and 5.4.0 * 2012 March - Responsible Disclosure via SSD/BeyondSecurity * 2012 April - Patch available 2012-04-19 * 2012 May/June - No trace of bugfix in svn for 5.3/5.4/trunk although mentioned in bugref #61755 * 2012 June  - No trace of bugfix in svn for 5.3/5.4/trunk, code ... * 2012 June  - public disclosure CREDITS: -------- Discovered by 0x721427D8 via BeyondSecurity - SecuriTeam Secure Disclosure Refs: ----- http://php.net/ http://www.php.net/manual/en/intro.pdo.php http://svn.php.net/viewvc/php/php-src/trunk/ext/pdo/ http://www.securiteam.com/ ----- End forwarded message ----- -- - (2^(N-1)) From owner-freebsd-security@FreeBSD.ORG Tue Jun 12 17:55:18 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 770B01065674; Tue, 12 Jun 2012 17:55:18 +0000 (UTC) (envelope-from felipensp@gmail.com) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id DEF4F8FC0A; Tue, 12 Jun 2012 17:55:17 +0000 (UTC) Received: by qabj40 with SMTP id j40so654697qab.15 for ; Tue, 12 Jun 2012 10:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=aVZaGnDwAoeX7G4OruGLtv0RYBfUvsqdByAeKMC6Kt4=; b=LKtA31/su0fKun64BFaszbqFS+0icnSPfciRVnjuDUauP2eUCx/VHoON2I+L+DHkI9 tjLGGlsyS+xOzGEM9QoHFVffoh/br2Is+HxvsdTlh9dvzc1gCeMwksKvfau6sNRFjRgW KKO2JKh/sQshxx/LO7o+mSkM6IPMvmFdnBrwFXU2NFP+l+ehu0SBxpBon8fcA0DEZNhe APSmb4+5NJKjaEImhCgIioo6FrXD2cgqAOQJVhuikeYopMW2HHYj3za4mGZIT46yXff0 4BMk8RxM3ut4i+B0QWi+sE5TIb6Pxh3e/acWnH/tpCu6yCHCwan0GyqjgmOduiB4x6hk GXkA== Received: by 10.229.135.209 with SMTP id o17mr8545642qct.18.1339523717208; Tue, 12 Jun 2012 10:55:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.99.144 with HTTP; Tue, 12 Jun 2012 10:54:56 -0700 (PDT) In-Reply-To: <20120612173958.GA78172@DataIX.net> References: <20120612173958.GA78172@DataIX.net> From: Felipe Pena Date: Tue, 12 Jun 2012 14:54:56 -0300 Message-ID: To: Jason Hellenthal Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [0x721427d8@gmail.com: [php<=5.4.3] Parsing Bug in PHP PDO prepared statements may lead to access violation] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:55:18 -0000 Hi, 2012/6/12 Jason Hellenthal : [...] > > Timeline: > --------- > * 2012 Feb =C2=A0 - Discovered in 5.3.8, verified for 5.3.0/5.3.10 and 5.= 4.0 > * 2012 March - Responsible Disclosure via SSD/BeyondSecurity > * 2012 April - Patch available 2012-04-19 > * 2012 May/June - No trace of bugfix in svn for 5.3/5.4/trunk although > mentioned in bugref #61755 > * 2012 June =C2=A0- No trace of bugfix in svn for 5.3/5.4/trunk, code ... > * 2012 June =C2=A0- public disclosure > No trace of bugfix in June? It has been fixed in Apr. http://git.php.net/?p=3Dphp-src.git;a=3Dcommitdiff;h=3D1b78aef426a8f413ddd7= 0854eb3fd5fbc95ef675 --=20 Regards, Felipe Pena From owner-freebsd-security@FreeBSD.ORG Wed Jun 13 15:38:51 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906BA106564A for ; Wed, 13 Jun 2012 15:38:51 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 427188FC16 for ; Wed, 13 Jun 2012 15:38:51 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 66CD963D; Wed, 13 Jun 2012 17:38:49 +0200 (CEST) Date: Wed, 13 Jun 2012 17:36:54 +0200 From: Pawel Jakub Dawidek To: Gleb Kurtsou Message-ID: <20120613153654.GA1399@garage.freebsd.pl> References: <20120531194825.GB1400@garage.freebsd.pl> <20120609085141.GA1153@reks> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <20120609085141.GA1153@reks> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@FreeBSD.org Subject: Re: OpenSSL change for review. X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 15:38:51 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 09, 2012 at 11:51:41AM +0300, Gleb Kurtsou wrote: > On (31/05/2012 21:48), Pawel Jakub Dawidek wrote: > > As learned on someone else's mistakes, I'd like to ask for a review of > > those changes related to random data handling: > >=20 > > http://people.freebsd.org/~pjd/patches/libc_arc4random.c.patch > > http://people.freebsd.org/~pjd/patches/openssl_rand_unix.c.patch > >=20 > > The first patch changes arc4random() to use sysctl to obtain random data > > instead of opening /dev/random. The main reason here is to make it more > > sandbox-friendly. Once closed in sandbox, a process can no longer open > > files, so it has no access to proper random data. As a side-effect it > > should be a bit faster as instead of three system calls (open, read and > > close) we use only one (__sysctl). > > > > The second patch enables the use of libc's arc4random(3) in OpenSSL. >=20 > While at it, did you consider replacing default homegrown OpenSSL random > generator (ssleay_rand_*) with something standard (this "hash > uninitialized user buffer to increase entropy" thing makes me nervous, > which was also the source of well known Debian RSA key generation issue). Nope, sorry. This is out of my scope currently. > Patches are good to commit, IMHO. Thanks for review. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/Ys5YACgkQForvXbEpPzTmWgCgjHYDoZ1C7j+hLTaclxewniEC SlgAn3i4Aed/vC1wV06zvVQLkfPBN/o7 =yXji -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-security@FreeBSD.ORG Wed Jun 13 22:37:26 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C14F1065673 for ; Wed, 13 Jun 2012 22:37:26 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (gerbercreations.com [71.39.140.16]) by mx1.freebsd.org (Postfix) with ESMTP id F103C8FC20 for ; Wed, 13 Jun 2012 22:37:25 +0000 (UTC) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.14.5/8.14.5) with ESMTP id q5DMbwQM072829 for ; Wed, 13 Jun 2012 15:37:59 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.14.5/8.14.5/Submit) id q5DMbwUw072828 for freebsd-security@freebsd.org; Wed, 13 Jun 2012 15:37:58 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Wed, 13 Jun 2012 15:37:58 -0700 From: Greg Lewis To: freebsd-security@freebsd.org Message-ID: <20120613223758.GA72817@misty.eyesbeyond.com> References: <201206121326.q5CDQXca078536@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201206121326.q5CDQXca078536@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-12:04.sysret X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 22:37:26 -0000 On Tue, Jun 12, 2012 at 01:26:33PM +0000, FreeBSD Security Advisories wrote: > IV. Workaround > > No workaround is available. > > However FreeBSD/amd64 running on AMD CPUs is not vulnerable to this > particular problem. > > Systems with 64 bit capable CPUs, but running the 32 bit FreeBSD/i386 > kernel are not vulnerable, nor are systems running on different > processor architectures. I found these last two paragraphs a little confusing. Is the correct interpretation that FreeBSD/amd64 running on Intel CPUs is the vulnerable combination? -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Thu Jun 14 00:23:03 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30EF106564A for ; Thu, 14 Jun 2012 00:23:03 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8BBB28FC08 for ; Thu, 14 Jun 2012 00:23:03 +0000 (UTC) Received: by ggnm2 with SMTP id m2so1127751ggn.13 for ; Wed, 13 Jun 2012 17:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nwAHvrjDJBSGlKvvR4Q8F3l+FYKyUbN/UHEL/MeHhS8=; b=lwj6xqFYj16lZjFu9Y7I2cjty+75EOfzxad2pSmgz+vxS4+Cym1xhKN/psod+UIdNT iGyvDnRdbugwO9lwCxOm+hK7Hmgd0GjEwtVFj1iJ++ICpwjlAgRccsMGmK6hsSicQ+k6 KklP/OIdgKFp6oY8jcqqlgHNo0T4OQyP8mRXetYywJOZRQC2iOxBLWR+eRrKha/OZh27 rK97B0Fg7rF1zt8WcOqG5j1dhfO2GOn66FgMyfntzWHYaxDKjAh64S5dpbiFFkKZwCq+ Xo5ZZdN82WkCdfCMFznFmPqGCNzA7+sVp/nB8+gUe/t+b5v0c4mXXSxhfIVzx3v+Guje W2XQ== MIME-Version: 1.0 Received: by 10.236.181.199 with SMTP id l47mr36513995yhm.85.1339633382867; Wed, 13 Jun 2012 17:23:02 -0700 (PDT) Received: by 10.236.46.233 with HTTP; Wed, 13 Jun 2012 17:23:02 -0700 (PDT) In-Reply-To: <20120613223758.GA72817@misty.eyesbeyond.com> References: <201206121326.q5CDQXca078536@freefall.freebsd.org> <20120613223758.GA72817@misty.eyesbeyond.com> Date: Thu, 14 Jun 2012 02:23:02 +0200 Message-ID: From: Oliver Pinter To: Greg Lewis Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-12:04.sysret X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:23:03 -0000 On 6/14/12, Greg Lewis wrote: > On Tue, Jun 12, 2012 at 01:26:33PM +0000, FreeBSD Security Advisories > wrote: >> IV. Workaround >> >> No workaround is available. >> >> However FreeBSD/amd64 running on AMD CPUs is not vulnerable to this >> particular problem. >> >> Systems with 64 bit capable CPUs, but running the 32 bit FreeBSD/i386 >> kernel are not vulnerable, nor are systems running on different >> processor architectures. > > I found these last two paragraphs a little confusing. Is the correct > interpretation that FreeBSD/amd64 running on Intel CPUs is the vulnerable > combination? > > -- > Greg Lewis Email : glewis@eyesbeyond.com > Eyes Beyond Web : http://www.eyesbeyond.com > Information Technology FreeBSD : glewis@FreeBSD.org > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=649219&SearchOrder=4 From owner-freebsd-security@FreeBSD.ORG Thu Jun 14 00:27:20 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F561106564A for ; Thu, 14 Jun 2012 00:27:20 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 32EBC8FC14 for ; Thu, 14 Jun 2012 00:27:20 +0000 (UTC) Received: from delta.delphij.net (unknown [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id E38EAF6BB; Wed, 13 Jun 2012 17:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1339633639; bh=sqftKMATfogYYRPeNncyGcxN1kTKi66cVm8ofRf0ViU=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=hdg0zj3UKaOskf+vN/JZz/DMhtoMGrVxnsZuk/TQZvDWabNwZJtD5X71FSAt7vcGt R1D7bCGZk2a7r8Lun26+2joX7TatgkeVHrdl6BqaeCnPF1p+d2+myQP3idVNG5uu2n FxmYP3MFamABJwhvzuKHpVX3urYdJR/roZ80GBKk= Message-ID: <4FD92FD6.1090007@delphij.net> Date: Wed, 13 Jun 2012 17:27:02 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Greg Lewis References: <201206121326.q5CDQXca078536@freefall.freebsd.org> <20120613223758.GA72817@misty.eyesbeyond.com> In-Reply-To: <20120613223758.GA72817@misty.eyesbeyond.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, d@delphij.net Subject: Re: FreeBSD Security Advisory FreeBSD-SA-12:04.sysret X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:27:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/13/12 15:37, Greg Lewis wrote: > On Tue, Jun 12, 2012 at 01:26:33PM +0000, FreeBSD Security > Advisories wrote: >> IV. Workaround >> >> No workaround is available. >> >> However FreeBSD/amd64 running on AMD CPUs is not vulnerable to >> this particular problem. >> >> Systems with 64 bit capable CPUs, but running the 32 bit >> FreeBSD/i386 kernel are not vulnerable, nor are systems running >> on different processor architectures. > > I found these last two paragraphs a little confusing. Is the > correct interpretation that FreeBSD/amd64 running on Intel CPUs is > the vulnerable combination? Correct. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP2S/WAAoJEG80Jeu8UPuz9JMIALQwTqb6SDKAUwLkxupOgyEa 7dSHYAxwbNWKNvjbK0brS05kx5RdEmxdkoRqdKOlPcY8JnbqpbROWIbUHA8XIfCW igHIISTgQhiw5nx8XqMMoEfzztPR7UKr9rE+CToWLT8GbHWEpiYlE1RpIQgoZ0TK ldlQSOOMZ32zushxbM1ZncSM0/Rm9ie+ISezGfCV/lXqQUycVxnxjV/Euf6OKzxC xQC2nI21UIu1nZi8sfT0Qnlz8o/ehEYMmHDJgkphxLxMqtWW6l/WqdPMtEGWwBVB rBGRVQvkCrqu8aKBUsOFmX9+vZ4riDtggrXjSadAUGVQNMtBlHBPJ83vmyiQ5LA= =Qpu0 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Jun 14 00:41:56 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BB481065672 for ; Thu, 14 Jun 2012 00:41:56 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (gerbercreations.com [71.39.140.16]) by mx1.freebsd.org (Postfix) with ESMTP id CE14C8FC0A for ; Thu, 14 Jun 2012 00:41:55 +0000 (UTC) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.14.5/8.14.5) with ESMTP id q5E0gRZw073675; Wed, 13 Jun 2012 17:42:28 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.14.5/8.14.5/Submit) id q5E0gRER073674; Wed, 13 Jun 2012 17:42:27 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Wed, 13 Jun 2012 17:42:27 -0700 From: Greg Lewis To: Oliver Pinter Message-ID: <20120614004227.GA73665@misty.eyesbeyond.com> References: <201206121326.q5CDQXca078536@freefall.freebsd.org> <20120613223758.GA72817@misty.eyesbeyond.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-12:04.sysret X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:41:56 -0000 On Thu, Jun 14, 2012 at 02:23:02AM +0200, Oliver Pinter wrote: > On 6/14/12, Greg Lewis wrote: > > On Tue, Jun 12, 2012 at 01:26:33PM +0000, FreeBSD Security Advisories > > wrote: > >> IV. Workaround > >> > >> No workaround is available. > >> > >> However FreeBSD/amd64 running on AMD CPUs is not vulnerable to this > >> particular problem. > >> > >> Systems with 64 bit capable CPUs, but running the 32 bit FreeBSD/i386 > >> kernel are not vulnerable, nor are systems running on different > >> processor architectures. > > > > I found these last two paragraphs a little confusing. Is the correct > > interpretation that FreeBSD/amd64 running on Intel CPUs is the vulnerable > > combination? > > http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=649219&SearchOrder=4 Thanks :). That was much clearer. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Thu Jun 14 15:09:44 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE24D106566C for ; Thu, 14 Jun 2012 15:09:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by mx1.freebsd.org (Postfix) with ESMTP id BD6B38FC12 for ; Thu, 14 Jun 2012 15:09:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E9A98B986; Thu, 14 Jun 2012 11:09:43 -0400 (EDT) From: John Baldwin To: freebsd-security@freebsd.org Date: Thu, 14 Jun 2012 08:21:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <201206121326.q5CDQXca078536@freefall.freebsd.org> <20120613223758.GA72817@misty.eyesbeyond.com> In-Reply-To: <20120613223758.GA72817@misty.eyesbeyond.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206140821.47265.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 14 Jun 2012 11:09:44 -0400 (EDT) Cc: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-12:04.sysret X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:09:45 -0000 On Wednesday, June 13, 2012 6:37:58 pm Greg Lewis wrote: > On Tue, Jun 12, 2012 at 01:26:33PM +0000, FreeBSD Security Advisories wrote: > > IV. Workaround > > > > No workaround is available. > > > > However FreeBSD/amd64 running on AMD CPUs is not vulnerable to this > > particular problem. > > > > Systems with 64 bit capable CPUs, but running the 32 bit FreeBSD/i386 > > kernel are not vulnerable, nor are systems running on different > > processor architectures. > > I found these last two paragraphs a little confusing. Is the correct > interpretation that FreeBSD/amd64 running on Intel CPUs is the vulnerable > combination? It is only know that AMD CPUs are safe. It is not known if non-AMD, non-Intel CPUs (e.g. the 64-bit capable VIA CPUs) are vulnerable. -- John Baldwin From owner-freebsd-security@FreeBSD.ORG Fri Jun 15 13:39:03 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AC781065673 for ; Fri, 15 Jun 2012 13:39:03 +0000 (UTC) (envelope-from azet@azet.org) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0B2D08FC0C for ; Fri, 15 Jun 2012 13:39:02 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so545245wgb.1 for ; Fri, 15 Jun 2012 06:39:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=zOXgvX8F6rsHlSYtbc0zrnkoFS4EUQRQYB3fThqNyig=; b=McSRPpMSWw4rhjFNzHM6kJ5598bLdDg1P010I565kUsFYPXSVOi84u1S5qluEFWd9M yeB+7ZH3ZD/bycqy9Bpfktxc8h+ktQDHwaXDNXII6Bi0HRhso0rnJpRXben0+u0i5YmL tWu6zJdQrLmSxIjZdsCmZyUbzkCup6m54ytdT6lhs4Uo5/uLKuPZzaPkbzem32z2xXbV mDy22YvUV6bF379FhEKcJQa9tZhSZu0Fmf71mKeXZydKPUwji3RXyV2HY/6nopIsUg5I efG+anllzAKACpo9E+hi7/Ev958UuCQ5LrjBcX0Zs7aGtxFUNzCl9tk7x2Hgnrf4Q9/H ngvA== MIME-Version: 1.0 Received: by 10.180.80.74 with SMTP id p10mr4694050wix.10.1339767541877; Fri, 15 Jun 2012 06:39:01 -0700 (PDT) Received: by 10.194.32.6 with HTTP; Fri, 15 Jun 2012 06:39:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 15:39:01 +0200 Message-ID: From: Aaron Zauner To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmlHGZRM1Kvi/RwHNfYixtqXBOg8WwyY+Kf+/De0jQS5KsOHSNTn67OCntrvle3MANzEoJQ Subject: Re: Pre-boot authentication / geli-aware bootcode X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 13:39:03 -0000 AFAIK you'd need something similary to initrd (http://en.wikipedia.org/wiki/Initrd), which, to the best of my knowledge, does not currently exist in freebsd. so long, azet On Mon, Jun 11, 2012 at 2:21 AM, Robert Simmons wrote= : > Would it be possible to make FreeBSD's bootcode aware of geli encrypted v= olumes? > > I would like to enter the password and begin decryption so that the > kernel and /boot are inside the encrypted volume. =C2=A0Ideally the only > unencrypted area of the disk would be the gpt protected mbr and the > bootcode. > > I know that Truecrypt is able to do something like this with its > truecrypt boot loader, is something like this possible with FreeBSD > without using Truecrypt? > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" From owner-freebsd-security@FreeBSD.ORG Fri Jun 15 15:05:50 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AA3110657AA for ; Fri, 15 Jun 2012 15:05:50 +0000 (UTC) (envelope-from piechota@argolis.org) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by mx1.freebsd.org (Postfix) with ESMTP id 48FBB8FC14 for ; Fri, 15 Jun 2012 15:05:50 +0000 (UTC) Received: from [192.168.1.5] ([unknown] [98.114.37.117]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M5N000FRWFVRZH0@vms173005.mailsrvcs.net> for freebsd-security@freebsd.org; Fri, 15 Jun 2012 09:04:55 -0500 (CDT) Message-id: <4FDB40FB.2090806@argolis.org> Date: Fri, 15 Jun 2012 10:04:43 -0400 From: Matt Piechota User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-version: 1.0 To: freebsd-security@freebsd.org References: In-reply-to: Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit Subject: Re: Pre-boot authentication / geli-aware bootcode X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 15:05:50 -0000 On 06/15/2012 09:39 AM, Aaron Zauner wrote: > AFAIK you'd need something similary to initrd > (http://en.wikipedia.org/wiki/Initrd), which, to the best of my > knowledge, does not currently exist in freebsd. > Even that leaves the initrd (and /boot) unencrypted (as in Linux). The Windowsy ones I've seen appear to load the decryption driver right out of the MBR and work from there. I haven't done detailed investigation on it, but I think TrueCrypt does work this way and is FOSS (although with their own license that requires attribution and whatnot). http://www.truecrypt.org/legal/license -- Matt Piechota From owner-freebsd-security@FreeBSD.ORG Fri Jun 15 15:42:24 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1CD5106566C for ; Fri, 15 Jun 2012 15:42:24 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id AFCE48FC14 for ; Fri, 15 Jun 2012 15:42:24 +0000 (UTC) Received: by dadv36 with SMTP id v36so4434421dad.13 for ; Fri, 15 Jun 2012 08:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=FTb/ZE7S4CktbiwDKOUVFzujssrNtTLFqUgxZeHUq1k=; b=B4ak5US14ymfyFiw6HZ65oSf0jjxafrTON16jyHg0CDQDcFBf0BtytxBZQi48UpTZO PukYbOD5XqJ7BPkxfZgugzFKziMgeGgiwNrNjHQXmY5qBikVtcQ3NprdxU3okstIxlB0 aAIoMQBka6OCyQVxZGDSDo8l4uZ/BHfsvzTnFegITMkKN/uD2KE3lKB+c9yqp4r8d1cv 9nIxua6Eoz+bKj+1VfTKZBQ7UBdJj6wJ7FWVqQA44L3gBkhJmhU5NdTUYfHXRBXzYTby UdE2+lk8BpJdiq4bKHXwg3gYINc/lFWuBbgGdRCmDk1xSUMZop/BKEGHHXNKBs29lBof 62ww== Received: by 10.68.197.70 with SMTP id is6mr3089493pbc.64.1339774944364; Fri, 15 Jun 2012 08:42:24 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id qi8sm4825149pbc.36.2012.06.15.08.42.22 (version=SSLv3 cipher=OTHER); Fri, 15 Jun 2012 08:42:23 -0700 (PDT) Date: Fri, 15 Jun 2012 18:42:15 +0300 From: Gleb Kurtsou To: Aaron Zauner Message-ID: <20120615154215.GA5269@reks.swifttest.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org Subject: Re: Pre-boot authentication / geli-aware bootcode X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 15:42:25 -0000 On (15/06/2012 15:39), Aaron Zauner wrote: > AFAIK you'd need something similary to initrd > (http://en.wikipedia.org/wiki/Initrd), which, to the best of my > knowledge, does not currently exist in freebsd. FreeBSD well supports booting from memory disk which can be either embedded in kernel itself or loaded by boot loader. I think Robert meant extending loader(8) to load and boot kernel from geli encrypted file system. Thanks, Gleb. > > so long, > azet > > On Mon, Jun 11, 2012 at 2:21 AM, Robert Simmons wrote: > > Would it be possible to make FreeBSD's bootcode aware of geli encrypted volumes? > > > > I would like to enter the password and begin decryption so that the > > kernel and /boot are inside the encrypted volume.  Ideally the only > > unencrypted area of the disk would be the gpt protected mbr and the > > bootcode. > > > > I know that Truecrypt is able to do something like this with its > > truecrypt boot loader, is something like this possible with FreeBSD > > without using Truecrypt? > > _______________________________________________ > > freebsd-security@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Fri Jun 15 17:24:39 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BAFB106566C for ; Fri, 15 Jun 2012 17:24:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id DEF758FC25 for ; Fri, 15 Jun 2012 17:24:38 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBDEB4.dip.t-dialin.net [93.203.222.180]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id q5FHOabj018578; Fri, 15 Jun 2012 17:24:37 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id q5FHOQcE067219; Fri, 15 Jun 2012 19:24:26 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id q5FHODOB047794; Fri, 15 Jun 2012 19:24:19 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201206151724.q5FHODOB047794@fire.js.berklix.net> To: freebsd-security@freebsd.org From: "Julian H. Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Fri, 15 Jun 2012 19:24:13 +0200 Sender: jhs@berklix.com Cc: Kurt Buff Subject: UEFI & Microsoft thread on questions@ X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:24:39 -0000 Hi freebsd-security@freebsd.org, cc Kurt Buff A thread some of you may like to read: http://lists.freebsd.org/pipermail/freebsd-questions/2012-June/241732.html ] To: freebsd-questions@freebsd.org ] Date: Tue Jun 5 18:19:28 UTC 2012 ] From: Kurt Buff kurt.buff at gmail.com ] ] Subject: Is this something we (as consumers of FreeBSD) need to be aware of? ] ] UEFI considerations drive Fedora to pay MSFT to sign their kernel binaries ] http://cwonline.computerworld.com/t/8035515/1292406/565573/0/ ] This would seem to make compiling from source difficult. ] Kurt Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, & indent with "> ". Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ From owner-freebsd-security@FreeBSD.ORG Fri Jun 15 17:40:32 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9771106566B for ; Fri, 15 Jun 2012 17:40:32 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 361538FC0A for ; Fri, 15 Jun 2012 17:40:32 +0000 (UTC) Received: by bkvi18 with SMTP id i18so3201816bkv.13 for ; Fri, 15 Jun 2012 10:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yY/FzepZ+6j/d3gacTxQcorLq/rL2Mc4FvWrcWk+0jg=; b=lJslwFYDeyw17P6ajH2/DnpV7dSC7f/ChJvytfFBfkJi8CRAb7FvE/jaHVXGMQt30d 1x/agqrc3OkiYeebfKr64URqM371V2ynW6IWrG5/Bm8iZIxALLFEN2HcWlmCB/0ua60h i9q/OksP1XNZeELzlohKlnwDWjCXm9kZp7nAQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=yY/FzepZ+6j/d3gacTxQcorLq/rL2Mc4FvWrcWk+0jg=; b=GBdU23+GzoCOK0AgeX2ccLxE25qyL0vkjSfM6jaFTtOPgk9sJ+8phaPxVuOdsmkHp6 S5tiiXFfX29QlbH35phYFrTOKFqEnL4dN2JRNENxCbROLSmwEBDoRi6yp0Cs89tnIb2C uV6PXRJef8nyeIeviIlFwWjYDSvp2xlKxt5r+fCN+Sc6OpDvoLj7od7oYOmF62BBD6gr 3D+UiQ2vVrLvcbxlqIyyd5VdaPCpjOsxbs4hDJ2f0UgqGmpj6G9u4WXJuO0/kX7xMYTy 1s86FenCY0CMoq14XGuzbzI+mzrbuQtCNvOSADnyKZh7gxZy9tsodwZHVd6xb3ZiLTml 6exw== MIME-Version: 1.0 Received: by 10.205.134.6 with SMTP id ia6mr3302308bkc.51.1339782031031; Fri, 15 Jun 2012 10:40:31 -0700 (PDT) Sender: simon@qxnitro.org Received: by 10.205.39.199 with HTTP; Fri, 15 Jun 2012 10:40:30 -0700 (PDT) X-Originating-IP: [109.79.251.189] Received: by 10.205.39.199 with HTTP; Fri, 15 Jun 2012 10:40:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 18:40:30 +0100 X-Google-Sender-Auth: i-UtWS_wF8HWGI2cE8NUxXp7GoI Message-ID: From: "Simon L. B. Nielsen" To: Robert Simmons X-Gm-Message-State: ALoCoQm+wtLKIY91Ft+wuDqtLWAme0BsJ7u/M2/eTloGSDaum4EM/2FWiXDVx09xkoRBBui3zwK2 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-security@freebsd.org Subject: Re: Pre-boot authentication / geli-aware bootcode X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:40:32 -0000 On Jun 11, 2012 1:22 AM, "Robert Simmons" wrote: > > Would it be possible to make FreeBSD's bootcode aware of geli encrypted volumes? > > I would like to enter the password and begin decryption so that the > kernel and /boot are inside the encrypted volume. Ideally the only > unencrypted area of the disk would be the gpt protected mbr and the > bootcode. > > I know that Truecrypt is able to do something like this with its > truecrypt boot loader, is something like this possible with FreeBSD > without using Truecrypt? I just booted off a USB flash key. Then your entire drive can be encrypted. -- Simon L. B. Nielsen Mobile From owner-freebsd-security@FreeBSD.ORG Fri Jun 15 19:11:55 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D090A1065673 for ; Fri, 15 Jun 2012 19:11:55 +0000 (UTC) (envelope-from piechota@argolis.org) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by mx1.freebsd.org (Postfix) with ESMTP id AD9A38FC08 for ; Fri, 15 Jun 2012 19:11:55 +0000 (UTC) Received: from [192.168.1.5] ([unknown] [98.114.37.117]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M5O00E3R7UUCWAY@vms173011.mailsrvcs.net> for freebsd-security@freebsd.org; Fri, 15 Jun 2012 13:11:25 -0500 (CDT) Message-id: <4FDB7AC4.3060709@argolis.org> Date: Fri, 15 Jun 2012 14:11:16 -0400 From: Matt Piechota User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-version: 1.0 To: freebsd-security@freebsd.org References: In-reply-to: Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit Subject: Re: Pre-boot authentication / geli-aware bootcode X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 19:11:55 -0000 On 06/15/2012 01:40 PM, Simon L. B. Nielsen wrote: > On Jun 11, 2012 1:22 AM, "Robert Simmons" wrote: >> Would it be possible to make FreeBSD's bootcode aware of geli encrypted > volumes? >> I would like to enter the password and begin decryption so that the >> kernel and /boot are inside the encrypted volume. Ideally the only >> unencrypted area of the disk would be the gpt protected mbr and the >> bootcode. >> >> I know that Truecrypt is able to do something like this with its >> truecrypt boot loader, is something like this possible with FreeBSD >> without using Truecrypt? > I just booted off a USB flash key. Then your entire drive can be encrypted. > While true, the point (to me at least) is that with your kernel (and in Linux's case, initrd) in the clear it's possible for someone to bury a trojan of some sort in there waiting for you to boot up and start doing something nefarious (open backdoors, keylogging, etc.). I suppose you could check hashes of the kernel stuff and whatnot on booting to see if they haven't been modified, but that's not fool-proof either. That's obviously some pretty cloak and dagger stuff, but the company I work for requires full disk encryption. I've never actually asked if /boot counts, somewhat fearing the answer and resulting hassle from the largely paper-pushing security types. The USB key method isn't bad, but it realistically only adds obfuscation unless you keep your laptop and the key separate. Knowing myself, I'd forget one or the other fairly often. :) -- Matt Piechota From owner-freebsd-security@FreeBSD.ORG Fri Jun 15 21:24:31 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E9E1106566B for ; Fri, 15 Jun 2012 21:24:31 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 05B948FC08 for ; Fri, 15 Jun 2012 21:24:30 +0000 (UTC) Received: by bkvi18 with SMTP id i18so3371416bkv.13 for ; Fri, 15 Jun 2012 14:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yopQ1O07MVUOBQyZ7eOl0vs4J9l7VpgSfxvFH8wKJ7g=; b=nPHClfpDaELJLNq/NPhnJg4/SJWwPxyKCHl1cHeMtU7oENYLD9r0p4KVVZE9jgkLqL ZidOS6q6QT2ugbhPcZaN5h8UyOTaCMB69YynR2nS3X50fA0cybUNX5RSaGduNuhTqhLq sKbz3mUTbxfABKFrD8o8C7VZkgZxNg02zieuI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=yopQ1O07MVUOBQyZ7eOl0vs4J9l7VpgSfxvFH8wKJ7g=; b=l4DqodUvRlHB9brypqe2u8E19+Ec++wddDZBm33Et/thJViMgKItZH6mSFx/OrcXSF SGdbt9vmQ/lRFfXQ9kj2Ce0jL2Ys4Ol7W1JyAphbT88LDFx2LoXTLH6+c1wxlsyvd5rx i+e9TY/fS2mxlaZHWq1ePZC46DyRR/t40oao6luiD922FZKrD1k4EhmjOSlN6qsG1yI3 +VEi2xIlLzQ8EVlGpzNgY4mLEPLn30KGlhfogeFscXo9IQkgaXSyEhoT1xccSP1TqNL9 t65jW8HXaZmFgdVmSFEy5h3OU4YOsMbMeOHh/SBea+jS9d1jLu9TihncLSjbyLyP4JRm dakw== MIME-Version: 1.0 Received: by 10.205.134.6 with SMTP id ia6mr3515129bkc.51.1339795469439; Fri, 15 Jun 2012 14:24:29 -0700 (PDT) Sender: simon@qxnitro.org Received: by 10.205.39.199 with HTTP; Fri, 15 Jun 2012 14:24:29 -0700 (PDT) X-Originating-IP: [46.7.100.49] In-Reply-To: <4FDB7AC4.3060709@argolis.org> References: <4FDB7AC4.3060709@argolis.org> Date: Fri, 15 Jun 2012 22:24:29 +0100 X-Google-Sender-Auth: sPrJ3KwrXg3YoHJs5bQXUlrGg-I Message-ID: From: "Simon L. B. Nielsen" To: Matt Piechota Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlbzvJvdHkMslfqsNtQRjuCaS1zL/y5KZYfQ6BtszGvH3hEFI1VHuFpRLGKbjkQRtFsOifd Cc: freebsd-security@freebsd.org Subject: Re: Pre-boot authentication / geli-aware bootcode X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 21:24:31 -0000 On Fri, Jun 15, 2012 at 7:11 PM, Matt Piechota wrote= : > On 06/15/2012 01:40 PM, Simon L. B. Nielsen wrote: >> >> On Jun 11, 2012 1:22 AM, "Robert Simmons" =C2=A0wro= te: >>> >>> Would it be possible to make FreeBSD's bootcode aware of geli encrypted >> >> volumes? >>> >>> I would like to enter the password and begin decryption so that the >>> kernel and /boot are inside the encrypted volume. =C2=A0Ideally the onl= y >>> unencrypted area of the disk would be the gpt protected mbr and the >>> bootcode. >>> >>> I know that Truecrypt is able to do something like this with its >>> truecrypt boot loader, is something like this possible with FreeBSD >>> without using Truecrypt? >> >> I just booted off a USB flash key. Then your entire drive can be >> encrypted. >> > > While true, the point (to me at least) is that with your kernel (and in > Linux's case, initrd) in the clear it's possible for someone to bury a > trojan of some sort in there waiting for you to boot up and start doing > something nefarious (open backdoors, keylogging, etc.). I suppose you cou= ld > check hashes of the kernel stuff and whatnot on booting to see if they > haven't been modified, but that's not fool-proof either. That's obviously > some pretty cloak and dagger stuff, but the company I work for requires f= ull > disk encryption. I've never actually asked if /boot counts, somewhat fear= ing > the answer and resulting hassle from the largely paper-pushing security > types. If you are worried about somebody compromising the system with direct access, you can't fix that if you are booting of it. Truecrypt does not prevent somebody compromising the truecrypt loader from gaining access to your system after you have supplied the compromised loader with your password. 10 seconds of google searching: http://theinvisiblethings.blogspot.ie/2009/10/evil-maid-goes-after-truecryp= t.html > The USB key method isn't bad, but it realistically only adds obfuscation > unless you keep your laptop and the key separate. Knowing myself, I'd for= get > one or the other fairly often. :) I got a USB key which was ~1.2x2cm (from memory) so I just kept it in my keychain, and it was only attached to a computer when the system was booting (well, mostly) and when I had to upgrade kernel so I would say it added more than obfuscation, but nothing is perfect. As I could not get in at home without said keychain forgetting it wasn't really much of a problem (or rather, more of a problem wrt. getting in than wrt. booting laptop :-) ). It also provide a second factor'ish authentcation for the laptop as I used GELI keyfiles on the USB key as part of the encryption key. Not saying it's perfect, but worked well for me (past tense as I don't use a FreeBSD laptop anymore). Frankly I think there is a much simpler solution to this problem... if you ever not loose access long enough to the laptop that somebody could have done something funny, wipe drive and reinstall. It all depends on your level of paranoia / requirements for security. PS. just because you are paranoid, doesn't mean they are not out to get you= :-). --=20 Simon From owner-freebsd-security@FreeBSD.ORG Fri Jun 15 21:43:51 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 303EE106566C for ; Fri, 15 Jun 2012 21:43:51 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D1EDD8FC0A for ; Fri, 15 Jun 2012 21:43:50 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2466822vbm.13 for ; Fri, 15 Jun 2012 14:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=X1Vy5Lua5VDAkqL1zgEvY6aDJWFzw5IXJi0J1hPrCu0=; b=BZs8k7kBi5jKh2l+y2k7NoAv3HOwISmHdWkc9diUez6vYdLRQ3CpvtFGnrHirmgyXP vDAU77N7ivdnIUrLRYkFdQTxxt8Asr13wj7wJPPmv9iFUBIBA/l3TuJeN4xOXvXnNmXx DIuooGlgPnKOOCmISBXAJswwcwDuoBTsY3dBZDaPWVePzDIBtUg4WZkbrDNrheGilzFH qA4PP6v+ZKUqmEiWaquqYi+Xm6Rm49ZmXXVYTopPs5oywR5kEJ/cN535iNLxDMEd0wiY QbIcY9cyUU3qsHaxR0piI6vLFsJP8tiOEzSxry2yf5S4tpC0S5K+2Y657Mtsu9RE8BlJ U97g== MIME-Version: 1.0 Received: by 10.52.176.232 with SMTP id cl8mr3022496vdc.115.1339796630231; Fri, 15 Jun 2012 14:43:50 -0700 (PDT) Received: by 10.52.113.97 with HTTP; Fri, 15 Jun 2012 14:43:50 -0700 (PDT) In-Reply-To: References: <4FDB7AC4.3060709@argolis.org> Date: Fri, 15 Jun 2012 17:43:50 -0400 Message-ID: From: Robert Simmons To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Pre-boot authentication / geli-aware bootcode X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 21:43:51 -0000 On Fri, Jun 15, 2012 at 5:24 PM, Simon L. B. Nielsen wr= ote: > On Fri, Jun 15, 2012 at 7:11 PM, Matt Piechota wro= te: >> On 06/15/2012 01:40 PM, Simon L. B. Nielsen wrote: >>> >>> On Jun 11, 2012 1:22 AM, "Robert Simmons" =A0wrote= : >>>> >>>> Would it be possible to make FreeBSD's bootcode aware of geli encrypte= d >>> >>> volumes? >>>> >>>> I would like to enter the password and begin decryption so that the >>>> kernel and /boot are inside the encrypted volume. =A0Ideally the only >>>> unencrypted area of the disk would be the gpt protected mbr and the >>>> bootcode. >>>> >>>> I know that Truecrypt is able to do something like this with its >>>> truecrypt boot loader, is something like this possible with FreeBSD >>>> without using Truecrypt? >>> >>> I just booted off a USB flash key. Then your entire drive can be >>> encrypted. >>> >> >> While true, the point (to me at least) is that with your kernel (and in >> Linux's case, initrd) in the clear it's possible for someone to bury a >> trojan of some sort in there waiting for you to boot up and start doing >> something nefarious (open backdoors, keylogging, etc.). I suppose you co= uld >> check hashes of the kernel stuff and whatnot on booting to see if they >> haven't been modified, but that's not fool-proof either. That's obviousl= y >> some pretty cloak and dagger stuff, but the company I work for requires = full >> disk encryption. I've never actually asked if /boot counts, somewhat fea= ring >> the answer and resulting hassle from the largely paper-pushing security >> types. > > If you are worried about somebody compromising the system with direct > access, you can't fix that if you are booting of it. Truecrypt does > not prevent somebody compromising the truecrypt loader from gaining > access to your system after you have supplied the compromised loader > with your password. > > 10 seconds of google searching: > http://theinvisiblethings.blogspot.ie/2009/10/evil-maid-goes-after-truecr= ypt.html > >> The USB key method isn't bad, but it realistically only adds obfuscation >> unless you keep your laptop and the key separate. Knowing myself, I'd fo= rget >> one or the other fairly often. :) > > I got a USB key which was ~1.2x2cm (from memory) so I just kept it in > my keychain, and it was only attached to a computer when the system > was booting (well, mostly) and when I had to upgrade kernel so I would > say it added more than obfuscation, but nothing is perfect. As I could > not get in at home without said keychain forgetting it wasn't really > much of a problem (or rather, more of a problem wrt. getting in than > wrt. booting laptop :-) ). > > It also provide a second factor'ish authentcation for the laptop as I > used GELI keyfiles on the USB key as part of the encryption key. > > Not saying it's perfect, but worked well for me (past tense as I don't > use a FreeBSD laptop anymore). > > Frankly I think there is a much simpler solution to this problem... if > you ever not loose access long enough to the laptop that somebody > could have done something funny, wipe drive and reinstall. It all > depends on your level of paranoia / requirements for security. > > PS. just because you are paranoid, doesn't mean they are not out to get y= ou :-). That article is a fascinating read. I like the idea of the Disk Hasher stick solution. Perhaps that idea could be made more secure if the hash stick itself was encrypted: http://www.imation.com/en-US/Mobile-Security/Mobile-Security-Products/Secur= e-Data/Imation-Flash-Drives-Powered-by-IronKey/Imation-Enterprise-S200-Flas= h-Drive-Powered-by-IronKey/ Along those lines, I wonder if a GPF Crypto Stick could be used to authenticate the geli decryption process rather than your insecure USB stick? http://www.privacyfoundation.de/crypto_stick/crypto_stick_english/ From owner-freebsd-security@FreeBSD.ORG Sat Jun 16 17:57:54 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5328106566B; Sat, 16 Jun 2012 17:57:54 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from falkenstein-2.sn.de.cluster.ok24.net (falkenstein-2.sn.de.cluster.ok24.net [IPv6:2002:4e2f:2f89:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5474D8FC15; Sat, 16 Jun 2012 17:57:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=12.2011; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=r64VtXZARRpK4k1YKf1QdEb7lrbpvQfjGFo+IbLX0Gg=; b=gzmzmGide8lz5swDJWIqtkncm7hX4RDFlHJZUnYH/eV2UwHog7Inmeu6D0y04CVxOnIGg++bAP7wmXRTiYSMEfSIFl5j8FQEOO77QoViLUPT+8UN0r+ybRm5fXmhApI0GbWOKjZWOaF1fiUtK0cenptR/a1qi9wvSHjwLTuy488=; X-Spam-Status: No, score=-1.1 required=2.0 tests=ALL_TRUSTED, BAYES_00, DKIM_ADSP_DISCARD, TVD_RCVD_IP Received: from 188-220-33-66.zone11.bethere.co.uk ([188.220.33.66] helo=guisborough-1.rcc.uk.cluster.ok24.net) by falkenstein-2.sn.de.cluster.ok24.net with esmtp (Exim 4.72) (envelope-from ) id 1SfxFv-0003NI-A0; Sat, 16 Jun 2012 18:57:53 +0100 X-Spam-Status: No, score=-4.4 required=2.0 tests=ALL_TRUSTED, BAYES_00, DKIM_POLICY_SIGNALL Received: from [192.168.0.110] (helo=[192.168.0.9]) by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SfxFr-0003fk-09; Sat, 16 Jun 2012 18:57:50 +0100 Message-ID: <4FDCC91A.7080403@pyro.eu.org> Date: Sat, 16 Jun 2012 18:57:46 +0100 From: Steven Chamberlain User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120503 Icedove/3.0.11 MIME-Version: 1.0 To: freebsd-security@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bz@freebsd.org, simon@freebsd.org Subject: SA-12:04 commit on RELENG_8_1 incorrect? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 17:57:54 -0000 Hi, This was the commit of SA-12:04.sysret to RELENG_7_4, which makes sense to me: http://svnweb.freebsd.org/base/releng/7.4/sys/amd64/amd64/trap.c?r1=216618&r2=236953 But when it was applied to RELENG_8_1, it looks wrong, as if it was applied in the wrong place. The indentation is broken, and the code inserted looks like it wouldn't be effective: http://svnweb.freebsd.org/base/releng/8.1/sys/amd64/amd64/trap.c?revision=236953&view=markup#l965 Please could someone take a look at this and let me know if it was really intended. Thanks! Regards, -- Steven Chamberlain steven@pyro.eu.org From owner-freebsd-security@FreeBSD.ORG Sat Jun 16 18:27:20 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 369FA106564A for ; Sat, 16 Jun 2012 18:27:20 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E40C68FC14 for ; Sat, 16 Jun 2012 18:27:19 +0000 (UTC) Received: by vcbfy7 with SMTP id fy7so2676335vcb.13 for ; Sat, 16 Jun 2012 11:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=1nCBpGHyULFq/fSG7YfcqrqgyqxYx486ZNHFUoJHAL0=; b=DM+Vgy0gBgLEUEkRftoaggXkIbnWOODVY9eL7ob8qU2XnyDHfsuwhVIv7yxdgmq84f lMwwBk0jyJ7S0YrBVG6nr2wbOmBYcCUqAG7l5LABrrAwA1lFjepjij+zXhC3/hfaggCu 5cMzHlvDBDNmCWW4/IS6YWbAoRIomZ9seZj+wLJEDxdTuXUCe+ldq12xp+lLhOyh6sOH O2RUBxJhtzzG1TTdcVDa3pyvTYNQI2gUVbNXrtN6BID1tMX9WVwOIspInQWC9d47Uaxe uDnuK/qfMgwIDnbTcYccDiSYfk2K5HgyCKWwUm1s2Qh+b63FfDpi82K2hh7PINkCXDNa h7VQ== MIME-Version: 1.0 Received: by 10.52.88.176 with SMTP id bh16mr4154213vdb.132.1339871239072; Sat, 16 Jun 2012 11:27:19 -0700 (PDT) Received: by 10.52.113.97 with HTTP; Sat, 16 Jun 2012 11:27:19 -0700 (PDT) In-Reply-To: <4FDCC91A.7080403@pyro.eu.org> References: <4FDCC91A.7080403@pyro.eu.org> Date: Sat, 16 Jun 2012 14:27:19 -0400 Message-ID: From: Robert Simmons To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: SA-12:04 commit on RELENG_8_1 incorrect? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 18:27:20 -0000 On Sat, Jun 16, 2012 at 1:57 PM, Steven Chamberlain wr= ote: > Hi, > > This was the commit of SA-12:04.sysret to RELENG_7_4, which makes sense > to me: > > http://svnweb.freebsd.org/base/releng/7.4/sys/amd64/amd64/trap.c?r1=3D216= 618&r2=3D236953 > > But when it was applied to RELENG_8_1, it looks wrong, as if it was > applied in the wrong place. =A0The indentation is broken, and the code > inserted looks like it wouldn't be effective: > > http://svnweb.freebsd.org/base/releng/8.1/sys/amd64/amd64/trap.c?revision= =3D236953&view=3Dmarkup#l965 > > Please could someone take a look at this and let me know if it was > really intended. Looks like the if statement was inserted inside the if statement above it by accident. where in the other patch the new if statement occurs before. Certainly looks incorrect to me. From owner-freebsd-security@FreeBSD.ORG Sat Jun 16 18:14:14 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1239E106566B for ; Sat, 16 Jun 2012 18:14:14 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id B5A008FC1B for ; Sat, 16 Jun 2012 18:14:13 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5205825D389C; Sat, 16 Jun 2012 18:14:12 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 4F0A3BE857E; Sat, 16 Jun 2012 18:14:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id gJcbf_SnU67X; Sat, 16 Jun 2012 18:14:09 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A2453BE83AB; Sat, 16 Jun 2012 18:14:09 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4FDCC91A.7080403@pyro.eu.org> Date: Sat, 16 Jun 2012 18:14:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FDCC91A.7080403@pyro.eu.org> To: Steven Chamberlain X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 16 Jun 2012 19:52:59 +0000 Cc: freebsd-security@freebsd.org Subject: Re: SA-12:04 commit on RELENG_8_1 incorrect? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 18:14:14 -0000 On 16. Jun 2012, at 17:57 , Steven Chamberlain wrote: > Hi, >=20 > This was the commit of SA-12:04.sysret to RELENG_7_4, which makes = sense > to me: >=20 > = http://svnweb.freebsd.org/base/releng/7.4/sys/amd64/amd64/trap.c?r1=3D2166= 18&r2=3D236953 >=20 > But when it was applied to RELENG_8_1, it looks wrong, as if it was > applied in the wrong place. The indentation is broken, and the code > inserted looks like it wouldn't be effective: >=20 > = http://svnweb.freebsd.org/base/releng/8.1/sys/amd64/amd64/trap.c?revision=3D= 236953&view=3Dmarkup#l965 >=20 > Please could someone take a look at this and let me know if it was > really intended. That 8.1 one is definitively wrong and had gone unnoticed. I'll make sure it'll be fixed. Thanks a lot for letting us know. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!