From owner-freebsd-security@FreeBSD.ORG Sun Feb 24 16:45:57 2008 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 EBCE716A402; Sun, 24 Feb 2008 16:45:57 +0000 (UTC) (envelope-from w@wrzask.pl) Received: from mx.oak.pl (mx.oak.pl [217.96.108.251]) by mx1.freebsd.org (Postfix) with ESMTP id 9547213C461; Sun, 24 Feb 2008 16:45:57 +0000 (UTC) (envelope-from w@wrzask.pl) Received: by oak.pl (Postfix, from userid 1002) id 48C4D1CD0E; Sun, 24 Feb 2008 17:30:05 +0100 (CET) Date: Sun, 24 Feb 2008 17:30:05 +0100 From: Jan Srzednicki To: freebsd-stable@freebsd.org, freebsd-security@freebsd.org Message-ID: <20080224163005.GG15445@oak.pl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Sun, 24 Feb 2008 17:00:08 +0000 Cc: Subject: A simple rc.d jail patch to enable priority 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, 24 Feb 2008 16:45:58 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I have written this tiny little patch to the jail rc.d script, which allows user to set jail nice value. It doesn't change any default behaviour. Can that make it to the trees? Patch attached. -- Jan Srzednicki :: http://wrzask.pl/ "Remember, remember, the fifth of November" -- V for Vendetta --r5Pyd7+fXNt84Ff3 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="jail.diff" --- /etc/rc.d/jail 2007-06-06 16:42:01.000000000 +0200 +++ /srv/home/winfried/jail.new 2008-02-24 17:26:42.000000000 +0100 @@ -69,6 +69,7 @@ [ -z "${_flags}" ] && _flags="-l -U root" eval _consolelog=\"\${jail_${_j}_consolelog:-${jail_consolelog}}\" [ -z "${_consolelog}" ] && _consolelog="/var/log/jail_${_j}_console.log" + eval _nice=\"\${jail_${_j}_nice:-${jail_nice}}\" # Debugging aid # @@ -89,6 +90,7 @@ debug "$_j exec stop: $_exec_stop" debug "$_j flags: $_flags" debug "$_j consolelog: $_consolelog" + [ -n "${_nice}" ] && debug "$_j nice: $_nice" if [ -z "${_hostname}" ]; then err 3 "$name: No hostname has been defined for ${_j}" @@ -322,7 +324,14 @@ fi fi _tmp_jail=${_tmp_dir}/jail.$$ - eval jail ${_flags} -i ${_rootdir} ${_hostname} \ + + if [ -z "${_nice}" ]; then + _nice_cmd="" + else + _nice_cmd="nice -n${_nice}" + fi + + eval ${_nice_cmd} jail ${_flags} -i ${_rootdir} ${_hostname} \ ${_ip} ${_exec_start} > ${_tmp_jail} 2>&1 if [ "$?" -eq 0 ] ; then echo -n " $_hostname" --r5Pyd7+fXNt84Ff3-- From owner-freebsd-security@FreeBSD.ORG Sun Feb 24 21:37:34 2008 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 0D87E16A400 for ; Sun, 24 Feb 2008 21:37:34 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 972A713C448 for ; Sun, 24 Feb 2008 21:37:33 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Resent-From:Resent-Date:Resent-Message-ID:Resent-To:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:In-Reply-To:Resent-Sender:Resent-Date:X-Spam-Status:Subject; b=H8YrmufFYtYmEmigLa7BBQi6eY3GuglV/l1+zO+KdTropROZphZKAJ/UpyYYzMS6s8chqv3dZ30f4RetV2JWw1LW/8E/f+FOdfnXfeDUFwvk67uJqU8MJC6iFdbHRppr9jrYBHfXhjZ6+zwMZ3f0pT+EJnyD83+hOUXBoQV/4nE=; Received: from amnesiac.at.no.dns (ppp85-141-160-161.pppoe.mtu-net.ru [85.141.160.161]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JTOXM-0000Vu-6k for freebsd-security@freebsd.org; Mon, 25 Feb 2008 00:37:32 +0300 Resent-From: rea-fbsd@codelabs.ru Resent-Date: Mon, 25 Feb 2008 00:37:31 +0300 Resent-Message-ID: Resent-To: freebsd-security@freebsd.org Date: Mon, 25 Feb 2008 00:16:22 +0300 From: Eygene Ryabinkin To: Jeremy Chadwick Message-ID: References: <20080223010856.7244.qmail@smasher.org> <47C068B5.2090000@thedarkside.nl> <20080223185620.GA98105@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Resent-Sender: rea-fbsd@codelabs.ru Resent-Date: Mon, 25 Feb 2008 00:37:32 +0300 X-Spam-Status: No, score=-2.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_20 Cc: freebsd-security@freebsd.org, hackers@freebsd.org Subject: Re: Zeroing sensitive memory chunks [Was: Security Flaw in Popular Disk Encryption Technologies] 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, 24 Feb 2008 21:37:34 -0000 Good day. I am posting the follow-up to the -hackers and CC'ing to the -security, because some more-or-less nasty points were found. Sat, Feb 23, 2008 at 10:32:02PM +0300, Eygene Ryabinkin wrote: > But there is another concern with bzero(): it is well-known function. > Especially for compilers. And it is bad: some arrays inside g_eli, > that hold decryption keys are the local variables. And they are > not used after the final bzero() call, so optimizing compiler can > eliminate the bzero() completely, as the "not relevant". I don't > know if GCC does it -- I should check and will do this tomorrow, > because it is already too late in Russia for this day ;)) Generally speaking, there is nothing special in this finding: "Secure Programming Cookbook for C and C++" from O'Reilly warns the reader about it (page 705 and below, citing by the current edition, http://www.oreilly.com/catalog/secureprgckbk/). OK, gcc 4.2.1 does the dead code removal and sometimes bzero/memset can be omitted (gcc 3.4.6, the one I have at hand from the 3.x branch, is never omitting these functions). It really depends on the size of the local array. The test program is: ----- #include #include #include #define bar(n) \ void bar ## n(void) \ { \ char b[n]; \ scanf("%" #n "s", b); \ memset(b, '\0', sizeof(b)); \ } #define foo(n) \ void foo ## n(void) \ { \ char b[n]; \ scanf("%" #n "s", b); \ bzero(b, sizeof(b)); \ } foo(16) foo(24) foo(32) foo(1024) bar(16) bar(24) bar(28) bar(30) bar(31) bar(32) bar(1024) int main(void) { foo16(); foo24(); foo28(); foo32(); foo1024(); bar16(); bar24(); bar28(); bar30(); bar31(); bar32(); bar1024(); return 0; } ----- Compiled with '-O' switch, it eliminates bzero/memset for all functions with the local array size < 32. For example, this is the assembler code of bar31 (taken from 'gcc -O -S -o test.s test.c'): ----- .globl bar31 .type bar31, @function bar31: pushl %ebp movl %esp, %ebp subl $40, %esp leal -31(%ebp), %eax movl %eax, 4(%esp) movl $.LC2, (%esp) call scanf leave ret .size bar31, .-bar31 .section .rodata.str1.1 .LC3: .string "%30s" .text .p2align 4,,15 ----- The simple PoC session transcript follows: ----- $ cat poc.c #include #include #include void pass(void) { char buffer[31]; printf("Password: "); scanf("%30s", buffer); memset(buffer, 0, sizeof(buffer)); } int main(void) { pass(); return 0; } $ gcc -O -g -o poc poc.c $ gdb poc GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) b main Breakpoint 1 at 0x8048450: file poc.c, line 15. (gdb) run Starting program: /some/path/poc Breakpoint 1, main () at poc.c:15 15 { (gdb) step main () at poc.c:16 16 pass(); (gdb) step pass () at poc.c:9 9 printf("Password: "); (gdb) print &buffer $1 = (char (*)[31]) 0xbfbfec69 (gdb) step 10 scanf("%30s", buffer); (gdb) Password: ASDFGHJKLQWERTYUIO 12 } (gdb) main () at poc.c:18 18 } (gdb) 0x080483af in _start () (gdb) x/35c 0xbfbfec69 0xbfbfec69: 65 'A' 83 'S' 68 'D' 70 'F' 71 'G' 72 'H' 74 'J' 75 'K' 0xbfbfec71: 76 'L' 81 'Q' 87 'W' 69 'E' 82 'R' 84 'T' 89 'Y' 85 'U' 0xbfbfec79: 73 'I' 79 'O' 0 '\0' 1 '\001' 0 '\0' 0 '\0' 0 '\0' -36 'Ü' 0xbfbfec81: -20 'ì' -65 '¿' -65 '¿' 0 '\0' 0 '\0' 0 '\0' 0 '\0' -104 '\230' 0xbfbfec89: -20 'ì' -65 '¿' -65 '¿' (gdb) ----- Currently, I was not able to identify gcc's code that removes the memset in question, so if anyone has ideas -- it will be appreciated. Just now there should be no flaws in the geli code if not dead code elimination occurs for array sizes >= 32: all local buffers that are cleared by bzero() are at least 64 bytes. But there can be other parts of a kernel that needs to be verified and gcc's conditions for the memset elimination should be analyzed. I will continue to investigate. And still, if some old/new gcc's (or other compilers, although they are not suspported for the kernel builds) will change their mind about elimination conditions for the tail memset(), we can be in trouble. Sure, stack-based variables can be rewritten by further calls to other functions, but it is better to be safe, then sorry ;-/ And it seems not to matter that kernel library has its own memset implementation, because a) gcc changes bzero -> memset in the single pass and the internal memset is tried first (gcc's builtins.c, lines 3529 and down); b) gcc tries to eliminate memset() even if there is such local function. Here is the test example: ----- $ cat poc1.c #include #include void * memset(void *b, int c, size_t len) { char *bb; for (bb = (char *)b; len--; ) *bb++ = c; return (b); } int foo31() { char buffer[31]; scanf("%30s", buffer); memset(buffer, 0, sizeof(buffer)); } int bar31() { char buffer[31]; scanf("%30s", buffer); bzero(buffer, sizeof(buffer)); } int main() { bar31(); foo31(); return 0; } ----- As one can verify with 'gcc -O -S -o poc1.s poc1.c', there will be no cleaning in both foo31() and bar31(). > For example, OpenSSL has the OPENSSL_cleanse() function whose purpose > is two-fold (from http://cvs.openssl.org/chngview?cn=9301): > ----- > *) New function OPENSSL_cleanse(), which is used to cleanse a section of > memory from it's contents. This is done with a counter that will > place alternating values in each byte. This can be used to solve > two issues: 1) the removal of calls to memset() by highly optimizing > compilers, and 2) cleansing with other values than 0, since those can > be read through on certain media, for example a swap space on disk. > [Geoff Thorpe] > ----- > > The '1)' is what I was talking about. '2)' is not very clear to > me now, I should research what Geoff meant. If anyone has an idea, > please comment. > > May be the crypto(4,9) framework should receive the function, that > will be simular to the OPENSSL_cleanse. And that function should > be used for wiping of the sensitive data. I rethinked this issue: the function should go (if it should be ever added) to the general kernel library. The reason is that there can be other code that will need data sanitization and it should not rely on the crypto framework. -- Eygene From owner-freebsd-security@FreeBSD.ORG Mon Feb 25 14:30:47 2008 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 041B116A406; Mon, 25 Feb 2008 14:30:47 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id B6CEF13C46B; Mon, 25 Feb 2008 14:30:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A56D7A.dip.t-dialin.net [84.165.109.122]) by redbull.bpaserver.net (Postfix) with ESMTP id 432F52E25E; Mon, 25 Feb 2008 15:13:09 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5625E7C48F; Mon, 25 Feb 2008 15:13:05 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m1PED4Kw068920; Mon, 25 Feb 2008 15:13:04 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 25 Feb 2008 15:13:04 +0100 Message-ID: <20080225151304.nan0he4xcs8kk00w@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 25 Feb 2008 15:13:04 +0100 From: Alexander Leidinger To: Jan Srzednicki References: <20080224163005.GG15445@oak.pl> In-Reply-To: <20080224163005.GG15445@oak.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.3, required 6, BAYES_00 -15.00, J_CHICKENPOX_21 0.60, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Mon, 25 Feb 2008 14:34:20 +0000 Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: A simple rc.d jail patch to enable priority 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, 25 Feb 2008 14:30:47 -0000 Quoting Jan Srzednicki (from Sun, 24 Feb 2008 17:30:05 +0100): > Hello, > > I have written this tiny little patch to the jail rc.d script, which > allows user to set jail nice value. It doesn't change any default > behaviour. > > Can that make it to the trees? > Patch attached. You need to provide documentation for it if you want that someone considers it for inclusion into the tree. Bye, Alexander. -- "But Huey, you PROMISED!" "Tell 'em I lied." http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-security@FreeBSD.ORG Sat Mar 1 23:54:04 2008 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 B81AE106566B for ; Sat, 1 Mar 2008 23:54:04 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 60B858FC22 for ; Sat, 1 Mar 2008 23:54:04 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Resent-From:Resent-Date:Resent-Message-ID:Resent-To:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Resent-Sender:Resent-Date:X-Spam-Status:Subject; b=d+m+SQz1VF3U8e9q97CAV0I5ZN9gvvJl4lK6K4J0s+n4jN9AibC2IcffVwuOKuoAVJuG9g0yyn/WUcQZzOr4G7quNcX1AI79SX4KE4xtGV8DwK7clKo3WcVrOGNeebDgQIiiTxGPAcz7yKP4QLMN0SbA+hL/EfqpHr/yTvhFR5w=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JVbWj-0002Fu-R9 for freebsd-security@freebsd.org; Sun, 02 Mar 2008 02:54:02 +0300 Resent-From: rea-fbsd@codelabs.ru Resent-Date: Sun, 2 Mar 2008 02:54:00 +0300 Resent-Message-ID: Resent-To: freebsd-security@freebsd.org Date: Sun, 2 Mar 2008 02:06:34 +0300 From: Eygene Ryabinkin To: sipherr@gmail.com Message-ID: References: <20080229163903.3680.qmail@securityfocus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20080229163903.3680.qmail@securityfocus.com> Resent-Sender: rea-fbsd@codelabs.ru Resent-Date: Sun, 02 Mar 2008 02:54:01 +0300 X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: freebsd-security@freebsd.org, vuln-dev@securityfocus.com Subject: Re: *BSD user-ppp local root (when conditions permit) 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, 01 Mar 2008 23:54:04 -0000 Good day. [Reposting this message to the freebsd-security from my subscribed address. Sorry for possible duplicates.] Fri, Feb 29, 2008 at 04:39:03PM -0000, sipherr@gmail.com wrote: > I just tested this on FreeBSD 6.3. This bug was discovered on NetBSD. It also works on OpenBSD (unconfirmed on 4.2) > > Steps to reproduce: > > 1. Run ppp > > 2. type the following (or atleat some variation of) > > ~/~/~/~/~/~/~/~/~/~/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > This will produce a segmentation violation (Core dumped). Yes, good catch: looks like stack-based buffer overflow. Also works on FreeBSD 7.0. Could you please test the following rough patch -- it seem to cure the situation. Although it is a bit late for today and I will recheck it more carefully tomorrow. diff --git a/usr.sbin/ppp/systems.c b/usr.sbin/ppp/systems.c index 77f06a1..0cf01d1 100644 --- a/usr.sbin/ppp/systems.c +++ b/usr.sbin/ppp/systems.c @@ -82,6 +82,10 @@ InterpretArg(const char *from, char *to) from++; while (*from != '\0') { + if (to >= endto) { + *endto = '\0'; + return from; + } switch (*from) { case '"': instring = !instring; @@ -97,6 +101,10 @@ InterpretArg(const char *from, char *to) *to++ = '\\'; /* Pass the escapes on, maybe skipping \# */ break; } + if (to >= endto) { + *endto = '\0'; + return from; + } *to++ = *from++; break; case '$': @@ -127,6 +135,10 @@ InterpretArg(const char *from, char *to) *ptr++ = *from; *ptr = '\0'; } + if (to >= endto) { + *endto = '\0'; + return from; + } if (*to == '\0') *to++ = '$'; else if ((env = getenv(to)) != NULL) { @@ -142,6 +154,10 @@ InterpretArg(const char *from, char *to) if (len == 0) pwd = getpwuid(ID0realuid()); else { + if (to + len >= endto) { + *to = '\0'; + return from; + } strncpy(to, from, len); to[len] = '\0'; pwd = getpwnam(to); Thank you! -- Eygene