From owner-freebsd-security@FreeBSD.ORG Sun Jun 18 08:27:23 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9E7B16A479 for ; Sun, 18 Jun 2006 08:27:23 +0000 (UTC) (envelope-from neiro21@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 817CC43D45 for ; Sun, 18 Jun 2006 08:27:23 +0000 (GMT) (envelope-from neiro21@gmail.com) Received: by py-out-1112.google.com with SMTP id i75so1009466pye for ; Sun, 18 Jun 2006 01:27:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=k6R6qeLNax9X+U6I0vfobxKnq5+QskCf/O+J16gkF3bfH5HdgLzHpJldaX59pKDqIuC8EaVlvsaRbBEoNPJvzCB8r40uJwT1kPTVRcWBGPTamTlrQ2YL7odkD50j88kKR6vvqpLBYsqOeF1snCmgrLInEj34iDAg20hgZkqcWVc= Received: by 10.35.82.15 with SMTP id j15mr6824889pyl; Sun, 18 Jun 2006 01:27:22 -0700 (PDT) Received: by 10.35.125.6 with HTTP; Sun, 18 Jun 2006 01:27:22 -0700 (PDT) Message-ID: <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> Date: Sun, 18 Jun 2006 12:27:22 +0400 From: "Nick Borisov" To: freebsd-security@freebsd.org In-Reply-To: <3bcb4e3f0606180056o63424cc0g5c121443e45fa333@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bcb4e3f0606180056o63424cc0g5c121443e45fa333@mail.gmail.com> Subject: memory pages nulling when releasing 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, 18 Jun 2006 08:27:24 -0000 Hello everyone! Could you tell me if FreeBSD supports memory page nulling when releasing it to prevent unauthorized access to data left in the page after it's allocated again. If it does, what sys calls etc provide that? IMHO this is an important issue when operating data with different sensivity levels. Thanks in advance. Nick From owner-freebsd-security@FreeBSD.ORG Sun Jun 18 09:25:23 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3087C16A47D for ; Sun, 18 Jun 2006 09:25:23 +0000 (UTC) (envelope-from nick@nickwithers.com) Received: from mail.nickwithers.com (mail.manrags.com [203.219.206.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E7CE43D46 for ; Sun, 18 Jun 2006 09:25:22 +0000 (GMT) (envelope-from nick@nickwithers.com) Received: from localhost (shmick.shmon.net [10.0.0.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nickwithers.com (Postfix) with ESMTP id C5DBD3A9C5; Sun, 18 Jun 2006 19:25:12 +1000 (EST) Date: Sun, 18 Jun 2006 19:25:12 +1000 From: Nick Withers To: "Nick Borisov" Message-Id: <20060618192512.dffbd7f3.nick@nickwithers.com> In-Reply-To: <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> References: <3bcb4e3f0606180056o63424cc0g5c121443e45fa333@mail.gmail.com> <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> Organization: nickwithers.com X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.19; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-nickwithers-MailScanner: Found to be clean X-nickwithers-MailScanner-From: nick@nickwithers.com Cc: freebsd-security@freebsd.org Subject: Re: memory pages nulling when releasing 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, 18 Jun 2006 09:25:23 -0000 On Sun, 18 Jun 2006 12:27:22 +0400 "Nick Borisov" wrote: > Hello everyone! > > Could you tell me if FreeBSD supports memory page nulling when > releasing it to prevent unauthorized access to data left in the page > after it's allocated again. I'm certainly not as expert in this area, but I thought I'd offer the following suggestions anyway (I'm assuming you're coding in C, here): - You might want to look at _malloc_options / MALLOC_OPTIONS (for example, '_malloc_options = "J";'), though this might be an expensive way to achieve the goal. See man 2 free for more information - You could zero a memory range explicitly before free()ing it, using bzero(3) or memset(3), for instance, or even just by assignment in some cases. This has the notable advantage that you can hand-pick which data you're zeroing based on individual merit > If it does, what sys calls etc provide that? > IMHO this is an important issue when operating data with different > sensivity levels. > > Thanks in advance. > > Nick Hope that helps! -- Nick Withers email: nick@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 From owner-freebsd-security@FreeBSD.ORG Sun Jun 18 10:09:20 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD86216A506 for ; Sun, 18 Jun 2006 10:09:20 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30303.mail.mud.yahoo.com (web30303.mail.mud.yahoo.com [68.142.200.96]) by mx1.FreeBSD.org (Postfix) with SMTP id 5A4C343D45 for ; Sun, 18 Jun 2006 10:09:20 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 95687 invoked by uid 60001); 18 Jun 2006 10:09:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nTAoVk2Q/0LIOPzsE23TVWwakqdil0xwNcD9v9t3t5mF/e3ldwxtLAbkXTDVCjqmX6eIdnZA41BrfidKtpmzvAv6xvTP2SUU0YiBZiitjbfeoKsonSPRnTFcNmEysf2q8F91fevf2vSg0yHhA7GlIYwqSuNAEcm0IUPaUkXVn2o= ; Message-ID: <20060618100919.95685.qmail@web30303.mail.mud.yahoo.com> Received: from [213.54.64.243] by web30303.mail.mud.yahoo.com via HTTP; Sun, 18 Jun 2006 03:09:19 PDT Date: Sun, 18 Jun 2006 03:09:19 -0700 (PDT) From: "R. B. Riddick" To: Nick Borisov , freebsd-security@freebsd.org In-Reply-To: <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: memory pages nulling when releasing 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, 18 Jun 2006 10:09:20 -0000 --- Nick Borisov wrote: > Could you tell me if FreeBSD supports memory page nulling when > releasing it to prevent unauthorized access to data left in the page > after it's allocated again. > If it does, what sys calls etc provide that? > IMHO this is an important issue when operating data with different > sensivity levels. > It is important, that no user process can look at non-shared (mmap(2) / MAP_SHARED) pages in main memory that were used by another process before. I think FreeBSD does it as follows (but I am not sure): 1. If a page is allocated for a process it is either overwritten with zeroes (0x00) (e. g. in case of a page for the stack segment of a process) or it is overwritten with the bytes of an executable or another file or so... 2. For maximum performance the system keeps a bunch of "pre-zero-ed" pages, so that the OS is quite fast, when a process wants pages for data (malloc(3)) or for stack. Here is my "proof": :-) % vmstat -s | grep zero 3840247 zero fill pages zeroed 844738 zero fill pages prezeroed -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Sun Jun 18 12:52:24 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC3BA16A474 for ; Sun, 18 Jun 2006 12:52:24 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E79C43D48 for ; Sun, 18 Jun 2006 12:52:24 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 7C86F5F53; Sun, 18 Jun 2006 08:52:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCeUVgU8Pd57; Sun, 18 Jun 2006 08:52:22 -0400 (EDT) Received: from [192.168.1.251] (pool-68-160-201-170.ny325.east.verizon.net [68.160.201.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 9692B5CFF; Sun, 18 Jun 2006 08:52:22 -0400 (EDT) Message-ID: <44954C82.4060709@mac.com> Date: Sun, 18 Jun 2006 08:52:18 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Nick Borisov References: <3bcb4e3f0606180056o63424cc0g5c121443e45fa333@mail.gmail.com> <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> In-Reply-To: <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org Subject: Re: memory pages nulling when releasing 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, 18 Jun 2006 12:52:24 -0000 Nick Borisov wrote: > Could you tell me if FreeBSD supports memory page nulling when > releasing it to prevent unauthorized access to data left in the page > after it's allocated again. Yes, FreeBSD has a mechanism for "zero-filling" used pages before they are allocated to another process, although this is normally deferred for a while to promote reuse of the page if the original process needs to use it again. > If it does, what sys calls etc provide that? > IMHO this is an important issue when operating data with different > sensivity levels. You can set some malloc() tunables to control some of this, although if you are trying to do secure programming of sensitive data, look towards mlock() to keep the data resident and unpageable to keep it out of the VM system and potentially the swapfile. Look at the source for GnuPG, for example, or OPIE... -- -Chuck From owner-freebsd-security@FreeBSD.ORG Sun Jun 18 17:33:26 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D623A16A47B for ; Sun, 18 Jun 2006 17:33:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2E9243D6A for ; Sun, 18 Jun 2006 17:33:22 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id B782F208F; Sun, 18 Jun 2006 19:33:16 +0200 (CEST) X-Spam-Tests: MAILTO_TO_SPAM_ADDR X-Spam-Learn: disabled X-Spam-Score: 0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id AAF3B208D; Sun, 18 Jun 2006 19:33:16 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 83AAB33C8D; Sun, 18 Jun 2006 19:33:16 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Nick Borisov" References: <3bcb4e3f0606180056o63424cc0g5c121443e45fa333@mail.gmail.com> <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> Date: Sun, 18 Jun 2006 19:33:16 +0200 In-Reply-To: <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> (Nick Borisov's message of "Sun, 18 Jun 2006 12:27:22 +0400") Message-ID: <86odwqs71f.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: memory pages nulling when releasing 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, 18 Jun 2006 17:33:26 -0000 "Nick Borisov" writes: > Could you tell me if FreeBSD supports memory page nulling when > releasing it to prevent unauthorized access to data left in the page > after it's allocated again. Processes always get zeroed pages from the kernel. This is the case for all Unices, and has been for decades. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sun Jun 18 20:10:08 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C486416A47F for ; Sun, 18 Jun 2006 20:10:08 +0000 (UTC) (envelope-from neiro21@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB3D643D6B for ; Sun, 18 Jun 2006 20:09:59 +0000 (GMT) (envelope-from neiro21@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so1105465pya for ; Sun, 18 Jun 2006 13:09:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HWdiBRWWt614MHqOTEgtcY5BOH6zbl27P+iIvOXWJc8qDdooUVBuUE+ZLZLQo55uApTFOPISNZGqDW0ztZExBT4UlE1UbBRU4t6mRjKsZs1yo+v/AHDVeT9pFbRRQp/eKK4DQfRmb0WoAGkgKmDgf5qKym0KY72ezZJa9ZPm104= Received: by 10.35.14.1 with SMTP id r1mr7424712pyi; Sun, 18 Jun 2006 13:09:57 -0700 (PDT) Received: by 10.35.125.6 with HTTP; Sun, 18 Jun 2006 13:09:57 -0700 (PDT) Message-ID: <3bcb4e3f0606181309h70c08dc6l691bbb6e5b48615a@mail.gmail.com> Date: Mon, 19 Jun 2006 00:09:57 +0400 From: "Nick Borisov" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" , freebsd-security@freebsd.org In-Reply-To: <86odwqs71f.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3bcb4e3f0606180056o63424cc0g5c121443e45fa333@mail.gmail.com> <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> <86odwqs71f.fsf@xps.des.no> Cc: Subject: Re: memory pages nulling when releasing 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, 18 Jun 2006 20:10:08 -0000 2006/6/18, Dag-Erling Sm=F8rgrav : > "Nick Borisov" writes: > > Could you tell me if FreeBSD supports memory page nulling when > > releasing it to prevent unauthorized access to data left in the page > > after it's allocated again. > > Processes always get zeroed pages from the kernel. This is the case > for all Unices, and has been for decades. Well, providing zeroed pages to processes is not quite similar to explicit cleaning of pages after use as some security standards demand. That's why I'm asking. The "Z" malloc option seems to be suitable but it's actually for debugging. From owner-freebsd-security@FreeBSD.ORG Sun Jun 18 20:39:06 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 206C216A47F for ; Sun, 18 Jun 2006 20:39:06 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30306.mail.mud.yahoo.com (web30306.mail.mud.yahoo.com [68.142.200.99]) by mx1.FreeBSD.org (Postfix) with SMTP id D5F1143D49 for ; Sun, 18 Jun 2006 20:39:04 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 31163 invoked by uid 60001); 18 Jun 2006 20:39:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PtqHyMDbv/gwyiAcqCYFravQeaIQ3dTr2zqDxF9PW/yuwJPPLgHe739k5IDtovzBZgV0E3vhLuMMu0Zoj2305nDW5i/2e4cK5DL8+n3SLOznCz/7Dt+e1vzE77XgD6UicWOZrL9CbBzBekPF2glhbGZ5vfzyOIb+qfm4g2n052Q= ; Message-ID: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> Received: from [213.54.84.110] by web30306.mail.mud.yahoo.com via HTTP; Sun, 18 Jun 2006 13:39:03 PDT Date: Sun, 18 Jun 2006 13:39:03 -0700 (PDT) From: "R. B. Riddick" To: Nick Borisov , freebsd-security@freebsd.org In-Reply-To: <3bcb4e3f0606181309h70c08dc6l691bbb6e5b48615a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: memory pages nulling when releasing 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, 18 Jun 2006 20:39:06 -0000 --- Nick Borisov wrote: > Well, providing zeroed pages to processes is not quite similar to > explicit cleaning of pages after use as some security standards > demand. That's why I'm asking. The "Z" malloc option seems to be > suitable but it's actually for debugging. > Since you would need (aa) root access (for reading /dev/mem (or what would it be?)) and/or (bb) physical access (for reading the content of powered off RAM) to the system to read the content of used pages, it would not help, if those pages are zero-ed after their use, because: (AA) User root has access to every or about every page in physical memory (e. g. while the process uses it; or after kernel-modification). and (BB) The one who has physical access has root access (e.g. by altering the content of the harddisc). Conclusion: Instead of zero'ing pages immediately after the process does not need them anymore, it would be much better, to keep the system safe (especially: security relevant software patches; and (even more) physical safety) Or maybe I missed something... :-) -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Sun Jun 18 20:41:30 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E8D716A47A for ; Sun, 18 Jun 2006 20:41:30 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DDD243D60 for ; Sun, 18 Jun 2006 20:41:16 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 6BC2E2089; Sun, 18 Jun 2006 22:41:11 +0200 (CEST) X-Spam-Tests: MAILTO_TO_SPAM_ADDR X-Spam-Learn: disabled X-Spam-Score: 0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id E832A2082; Sun, 18 Jun 2006 22:41:10 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id C7C1A33C8D; Sun, 18 Jun 2006 22:41:10 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "Nick Borisov" References: <3bcb4e3f0606180056o63424cc0g5c121443e45fa333@mail.gmail.com> <3bcb4e3f0606180127m3c4fdb13n2b42deb881b7bdc6@mail.gmail.com> <86odwqs71f.fsf@xps.des.no> <3bcb4e3f0606181309h70c08dc6l691bbb6e5b48615a@mail.gmail.com> Date: Sun, 18 Jun 2006 22:41:10 +0200 In-Reply-To: <3bcb4e3f0606181309h70c08dc6l691bbb6e5b48615a@mail.gmail.com> (Nick Borisov's message of "Mon, 19 Jun 2006 00:09:57 +0400") Message-ID: <86k67eryc9.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: memory pages nulling when releasing 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, 18 Jun 2006 20:41:30 -0000 "Nick Borisov" writes: > Well, providing zeroed pages to processes is not quite similar to > explicit cleaning of pages after use as some security standards > demand. That's why I'm asking. The "Z" malloc option seems to be > suitable but it's actually for debugging. Which security standard requires that one part of a process protect itself from another part of the same process? malloc() operates entirely in userland and is entirely replacable; there are plenty of malloc() implementations available both in ports and other places. If you're worried about authentication tokens and the like, our PAM library and modules zero memory used to store authentication data when it is released. So does OpenSSH. If this does not satisfy you, you're going to have to quote the relevant security standards, because it is not clear to me what you want, and I get the feeling that you don't quite know yourself. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 08:43:54 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFC9A16A504 for ; Mon, 19 Jun 2006 08:43:54 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B34AA43D48 for ; Mon, 19 Jun 2006 08:43:53 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail12.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k5J8hoOG032431 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 19 Jun 2006 18:43:50 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k5J8hnbN001270; Mon, 19 Jun 2006 18:43:49 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k5J8hnnA001269; Mon, 19 Jun 2006 18:43:49 +1000 (EST) (envelope-from peter) Date: Mon, 19 Jun 2006 18:43:49 +1000 From: Peter Jeremy To: "R. B. Riddick" Message-ID: <20060619084349.GA966@turion.vk2pj.dyndns.org> References: <3bcb4e3f0606181309h70c08dc6l691bbb6e5b48615a@mail.gmail.com> <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-security@freebsd.org Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 08:43:55 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 2006-Jun-18 13:39:03 -0700, R. B. Riddick wrote: Instead of >zero'ing pages immediately after the process does not need them >anymore, it would be much better, to keep the system safe >(especially: security relevant software patches; and (even more) >physical safety) The Unix model provides security as long as you don't bypass the access controls by (eg) reading /dev/mem. The OS only needs to explicitly zero a page if it is handing it back to a process without otherwise initialising it. There's no need to zero a page if it's going to be used to satisfy a pagein request. FreeBSD tries to reduce the effective overhead of page zeroing by zeroing them in the idle loop and keeping a cache of pre-zeroed pages for handing out to processes. --=20 Peter Jeremy --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFElmPF/opHv/APuIcRAr5/AJ0WHP5ubWmzXfcZXjNxKVb6XtNnlACfVLup TfjBJSpkNjCnQXOplaTo0Dw= =xxZa -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 09:04:03 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B963A16A474 for ; Mon, 19 Jun 2006 09:04:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 482DE43D46 for ; Mon, 19 Jun 2006 09:04:03 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id A28E32087; Mon, 19 Jun 2006 11:03:56 +0200 (CEST) X-Spam-Tests: none X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 95DB72085; Mon, 19 Jun 2006 11:03:56 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 75D8933C8D; Mon, 19 Jun 2006 11:03:56 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "R. B. Riddick" References: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> Date: Mon, 19 Jun 2006 11:03:55 +0200 In-Reply-To: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> (R. B. Riddick's message of "Sun, 18 Jun 2006 13:39:03 -0700 (PDT)") Message-ID: <86odwpwm84.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Nick Borisov Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 09:04:03 -0000 "R. B. Riddick" writes: > (bb) physical access (for reading the content of powered off RAM) You cannot read the content of powered-off DRAM. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 10:11:38 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E53816A474 for ; Mon, 19 Jun 2006 10:11:38 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30307.mail.mud.yahoo.com (web30307.mail.mud.yahoo.com [68.142.200.100]) by mx1.FreeBSD.org (Postfix) with SMTP id 2E67443D7E for ; Mon, 19 Jun 2006 10:11:34 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 31662 invoked by uid 60001); 19 Jun 2006 10:11:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tp0p92lVWQsECTYQ4r2caSCHc3Z18bKj7Py8bAyIb11LXGqTRHLNOZEDHyIo68I+y0MGavrXsAvFPNYWkHwg3HXu0Bnhl8Rj7uqckK6l+42Tqz3Qd1EwdCsCxSBqTOS62mNJS2lLputHuetzOtzAORjz57Q0iUEfkNBKhpWqRME= ; Message-ID: <20060619101133.31660.qmail@web30307.mail.mud.yahoo.com> Received: from [213.54.84.110] by web30307.mail.mud.yahoo.com via HTTP; Mon, 19 Jun 2006 03:11:33 PDT Date: Mon, 19 Jun 2006 03:11:33 -0700 (PDT) From: "R. B. Riddick" To: Dag-Erling "Smørgrav" In-Reply-To: <86odwpwm84.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, Nick Borisov Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 10:11:38 -0000 --- Dag-Erling Smørgrav wrote: > "R. B. Riddick" writes: > > (bb) physical access (for reading the content of powered off RAM) > > You cannot read the content of powered-off DRAM. > Yes, that it is true. _I_ cannot read powered-off DRAM... But my feathered friends beyond the seven mountains with bird-like heads and big muscled chests and arms and legs and a super-duper-computer (abbr.: CIA) could possibly do that... At least I saw that in TV (CSI Wanne-Eickel or so), how they read from a overwritten hard disc shreddered with a "laser"... -Arne --- Arne likes Keanu Reeves and Dr.Evil and CSI... __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 10:12:05 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D20E16A47C for ; Mon, 19 Jun 2006 10:12:05 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [195.113.24.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4339D43D9C for ; Mon, 19 Jun 2006 10:11:49 +0000 (GMT) (envelope-from dan@obluda.cz) X-Envelope-From: dan@obluda.cz Received: from [10.20.0.26] (openvpn.ms.mff.cuni.cz [195.113.20.87]) by smtp1.kolej.mff.cuni.cz (8.13.1/8.13.1) with ESMTP id k5JAC4Zv028017 for ; Mon, 19 Jun 2006 12:12:05 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <44967861.6070509@obluda.cz> Date: Mon, 19 Jun 2006 12:11:45 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.4) Gecko/20060605 SeaMonkey/1.0.2 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> In-Reply-To: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 10:12:05 -0000 R. B. Riddick napsal/wrote, On 06/18/06 22:39: >> Well, providing zeroed pages to processes is not quite similar to >> explicit cleaning of pages after use as some security standards >> demand. > (aa) root access (for reading /dev/mem (or what would it be?)) > and/or > Instead of zero'ing pages immediately after the process does not need them > anymore, it would be much better, to keep the system safe (especially: security > relevant software patches; and (even more) physical safety) > > Or maybe I missed something... :-) Yes, you missed, I think. You are true - you need physical security, you need "no root access for intruders". It's absolutely vital base measures. But "is necessary for" is not the same as "is sufficient for" nor "there is no reason to do more". No wall is unbreakable, so you may decide to build other "supporting walls" Despite of all your safety measures, someone may gain root access. When someone gain root then he has access to all memory. But even if he has access to all memory, he has no access to information that aren't within memory. Thus, keeping sensitive informations within memory for short time only MAY reduce the risk level. The intruder need wait for information to appear in memory again - but it cost time. It increase possibility the intrusion will be detected and intruder eliminated before they can grab any sensitive information. I don't tell we must clear all memory on free for generic safety - i tell that your "zero'ing pages immediately after the process does not need them anymore" is not true in general. There are situation that zeroing may reduce the risk, so the request for it may be eligible. --------------- To Nick: OS doesn't zero on free. For better security of your sensitive data you need zero the memory by self. For inspiration I recommend to see the CRYPT_malloc/CRYPT_free implementation in OpenSSL. Don't forget the edge situations also (when your program can prematurely exits, you need the clean the key memory on "atexit" or so). You may need to avoid swapping of memory with sensitive data also - see man mlock. But security knows no simple measures. You need think carefully about your specific situation then decide what measures are appropriate. More security measures may not cause more real security - it can have opposite effect also. Dan -- Dan Lukes SISAL MFF UK AKA: dan@obluda.cz, dan@freebsd.cz,dan@kolej.mff.cuni.cz From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 10:43:04 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77E7016A47B for ; Mon, 19 Jun 2006 10:43:04 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30312.mail.mud.yahoo.com (web30312.mail.mud.yahoo.com [68.142.201.230]) by mx1.FreeBSD.org (Postfix) with SMTP id A4BCD43D67 for ; Mon, 19 Jun 2006 10:42:58 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 66214 invoked by uid 60001); 19 Jun 2006 10:42:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gGGRdVed3Kiv/bsdLuYcQcqj8IK2XKLtNplnejsMdDPSU8fF8Ua05KYfb7rmkFu1YyPjFWCP588Q74FzzDgzlIF7RWmsGwhTw5ZN9pwTds11UpOiVVH/taI40Pj7JvywKlo7DttghvbSyUi4HKAS5JTLB5C+p+NqLLb3LKV/zzI= ; Message-ID: <20060619104258.66212.qmail@web30312.mail.mud.yahoo.com> Received: from [213.54.84.110] by web30312.mail.mud.yahoo.com via HTTP; Mon, 19 Jun 2006 03:42:58 PDT Date: Mon, 19 Jun 2006 03:42:58 -0700 (PDT) From: "R. B. Riddick" To: Dan Lukes , freebsd-security@freebsd.org In-Reply-To: <44967861.6070509@obluda.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 10:43:04 -0000 --- Dan Lukes wrote: > [...] Thus, keeping sensitive informations within memory for short > time only MAY reduce the risk level. The intruder need wait for > information to appear in memory again - but it cost time. [...] > That is true - it costs time... But if a bad guy has already root access it does not really matter, (aa) if he has to wait for some minutes or hours, or (bb) if he has just a small time window or (cc) if he can immediately start with scanning for secrets in /dev/mem. I say, in that case there is no security (it might be even possible to present the old state of the system to the outside via a modified kernel, that has "very strange ideas" about the correct results of certain syscalls, and that gets activated after a spontaneous reboot due to non-further specified reasons (maybe due to a power failure or a failure in the old UPS-device or a mobile phone that somebody possibly used inside the fully air-conditioned centre?; does somebody know, what "dd if=/dev/zero of=/dev/mem" does?)...)... As far as I understood the answers so far, OpenSSH and such tools are aware of that slightly increased risk, so that they zero the memory areas that contained sensitive data as soon as they are not needed anymore... So everything is fine and alright... ;-)) :-)) -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 11:49:24 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72B6F16A474 for ; Mon, 19 Jun 2006 11:49:24 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 019E143D68 for ; Mon, 19 Jun 2006 11:49:23 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 4CD052086; Mon, 19 Jun 2006 13:49:19 +0200 (CEST) X-Spam-Tests: none X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 3EDC82082; Mon, 19 Jun 2006 13:49:19 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 1E54C33C8D; Mon, 19 Jun 2006 13:49:19 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "R. B. Riddick" References: <20060619101133.31660.qmail@web30307.mail.mud.yahoo.com> Date: Mon, 19 Jun 2006 13:49:19 +0200 In-Reply-To: <20060619101133.31660.qmail@web30307.mail.mud.yahoo.com> (R. B. Riddick's message of "Mon, 19 Jun 2006 03:11:33 -0700 (PDT)") Message-ID: <86veqxv000.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Nick Borisov Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 11:49:24 -0000 "R. B. Riddick" writes: > Dag-Erling Sm=F8rgrav writes: > > You cannot read the content of powered-off DRAM. > Yes, that it is true. _I_ cannot read powered-off DRAM... But my > feathered friends beyond the seven mountains with bird-like heads > and big muscled chests and arms and legs and a super-duper-computer > (abbr.: CIA) could possibly do that... I very much doubt it. DRAM needs to be continuously refreshed, and loses its state within milliseconds of losing power. > At least I saw that in TV (CSI Wanne-Eickel or so), how they read from a > overwritten hard disc shreddered with a "laser"... Umm, first, CSI is fiction; second, unlike DRAM, a hard disk is designed to retain information when power is switched off. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 12:35:47 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6246116A474 for ; Mon, 19 Jun 2006 12:35:47 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [195.113.24.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADE3543D6D for ; Mon, 19 Jun 2006 12:35:45 +0000 (GMT) (envelope-from dan@obluda.cz) X-Envelope-From: dan@obluda.cz Received: from [10.20.0.26] (openvpn.ms.mff.cuni.cz [195.113.20.87]) by smtp1.kolej.mff.cuni.cz (8.13.1/8.13.1) with ESMTP id k5JCa1aO032551 for ; Mon, 19 Jun 2006 14:36:02 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <44969A1E.2070803@obluda.cz> Date: Mon, 19 Jun 2006 14:35:42 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.4) Gecko/20060605 SeaMonkey/1.0.2 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <20060619101133.31660.qmail@web30307.mail.mud.yahoo.com> <86veqxv000.fsf@xps.des.no> In-Reply-To: <86veqxv000.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 12:35:47 -0000 Dag-Erling Sm=F8rgrav napsal/wrote, On 06/19/06 13:49: > I very much doubt it. DRAM needs to be continuously refreshed, and > loses its state within milliseconds of losing power. >=20 >> At least I saw that in TV (CSI Wanne-Eickel or so), how they read from= a >> overwritten hard disc shreddered with a "laser"... >=20 > Umm, first, CSI is fiction; second, unlike DRAM, a hard disk is > designed to retain information when power is switched off. Well, we should not accept fiction serials as serious source of=20 information. On the other side, we know nothing about secret services=20 secrets. Sometime, the more safe side is count that they MAY be able to=20 do it (despite of exact meaning of "they" and "it"). I know something about not so secret secrets. You need no physical=20 access to computer nor active remote access. You need no steal the DRAM. = The computer is big transmitter of electromagnetic waves which can be=20 received from distant place. Analysis of it can not so unimportant part=20 of the computers work. As distant passive method it's almost undetectable= =2E Counter-measures against this kind of spying is very expensive - you=20 need special isolated server room and large controlled area with=20 restricted access around it (even the best isolated room can't shield=20 the transmission completely). I don't dispute about probability that someone asking this kind of=20 question in this kind of discussion list has sensitive data of high=20 value for a secret service (and obtainable by know technique of=20 receiving elmg. noise or unknown technique of reading of upowered DRAM). On the one side, price of counter measures should be comparable with=20 risk value. Zeroing some memory containing selected sensitive data as=20 part of free on application level is very cheap solution. It's eligible=20 even in the case the value of eliminated risk is very low, so we should=20 not deny it as technique with no real value ... Dan --=20 Dan Lukes SISAL MFF UK AKA: dan@obluda.cz, dan@freebsd.cz,dan@kolej.mff.cuni.cz From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 14:29:59 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DD3816A47C for ; Mon, 19 Jun 2006 14:29:59 +0000 (UTC) (envelope-from neiro21@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id D081343D48 for ; Mon, 19 Jun 2006 14:29:58 +0000 (GMT) (envelope-from neiro21@gmail.com) Received: by py-out-1112.google.com with SMTP id i75so1277618pye for ; Mon, 19 Jun 2006 07:29:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=udumRtkgY3dKd25gdrDlS6/NyyKxeN2JigkMbhNIItlaeuN4SmuYS7YIHIP33d2nf8kWsC9VL8cCF61BsHNWSq/rrq4ZC6q6HkuAL7xLbcxyLC8G+X0UO3r8tXJ8AomJWngKDcMeNvgS+g2yIZjcG31dC6k2FuODmnMF/ZWzRdM= Received: by 10.35.126.7 with SMTP id d7mr8353071pyn; Mon, 19 Jun 2006 07:29:58 -0700 (PDT) Received: by 10.35.125.6 with HTTP; Mon, 19 Jun 2006 07:29:57 -0700 (PDT) Message-ID: <3bcb4e3f0606190729ned52dbah2ab2477461cc6596@mail.gmail.com> Date: Mon, 19 Jun 2006 18:29:57 +0400 From: "Nick Borisov" To: freebsd-security@freebsd.org In-Reply-To: <3bcb4e3f0606190728m29b67270mda8088eab2ff0ba1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44967861.6070509@obluda.cz> <20060619104258.66212.qmail@web30312.mail.mud.yahoo.com> <3bcb4e3f0606190728m29b67270mda8088eab2ff0ba1@mail.gmail.com> Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 14:29:59 -0000 2006/6/19, R. B. Riddick : > But if a bad guy has already root access it does not really matter, > (aa) if he has to wait for some minutes or hours, > or > (bb) if he has just a small time window > or > (cc) if he can immediately start with scanning for secrets in /dev/mem. I would argue about this. Allowing an intrunder to deal with your system even one extra minute may lead to tremendous losses depending on what kind of data your system operates with. As Dan mentioned, the cost of data defines means of security you should use to protect it. As for standards, they are Russian national governmental ones appliyng to computer systems that operate confidential, secret and more sensitive data. From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 15:17:00 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A40D16A4DE for ; Mon, 19 Jun 2006 15:17:00 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30301.mail.mud.yahoo.com (web30301.mail.mud.yahoo.com [68.142.200.94]) by mx1.FreeBSD.org (Postfix) with SMTP id 0471C43DEF for ; Mon, 19 Jun 2006 15:16:36 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 10433 invoked by uid 60001); 19 Jun 2006 15:16:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oTs54LalpxBwSE0DP3/tw10njGXiJ5F+AyyU0Q6BgRDXDwUNWvp9+Aw6cicLk7+D2AOZeYcWPcwwlmNRMYYCeLYJyIF5e22gFuKOrrs2CoxNNsdHSmHyRgSSOBmzecrIVdMPRwJxAxZ9S8LpI/5z6uN7RQwFK/Ca3ISzcZXRDfI= ; Message-ID: <20060619151636.10431.qmail@web30301.mail.mud.yahoo.com> Received: from [213.54.84.110] by web30301.mail.mud.yahoo.com via HTTP; Mon, 19 Jun 2006 08:16:36 PDT Date: Mon, 19 Jun 2006 08:16:36 -0700 (PDT) From: "R. B. Riddick" To: Nick Borisov , freebsd-security@freebsd.org In-Reply-To: <3bcb4e3f0606190728m29b67270mda8088eab2ff0ba1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 15:17:00 -0000 --- Nick Borisov wrote: > [...] Allowing an intrunder to deal with your > system even one extra minute may lead to tremendous losses depending > [...] > :-) OK.. Let's see, if I understood this right: 1 minute <-could be-> 1 tremendous loss 50 minutes <-could be-> 50 tremendous losses But what if a system just contains 5 tremendous chunks of secrets? Then it would not matter if we catch the attacker after 50 minutes or after 51 minutes... Even if we had a preparation time (before the loss starts) of 10 minutes (e. g. to install an evil kernel)... According to my experience attackers are not caught so quickly (and how should one do it? if the software is bad, than every connection could be evil; and of course even unusal connections (e. g. IP was never seen before or very high traffic to a single IP) could be good). I know personally of a case where somebody (mis(?))configured a NFS service (maybe it was a honey-pot, or so?), so that everyone had read/write access as _root_. It was possible to transfer about 20MB of data over about one hour from a single IP, that was never seen there before... The carrier of the system was a research centre (that works for several departments of the federal GERM government) with its own specially trained network/security administrators and a little nuclear power plant... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 16:51:03 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82ADD16A47D for ; Mon, 19 Jun 2006 16:51:03 +0000 (UTC) (envelope-from neiro21@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1533343D45 for ; Mon, 19 Jun 2006 16:51:02 +0000 (GMT) (envelope-from neiro21@gmail.com) Received: by py-out-1112.google.com with SMTP id i75so1314550pye for ; Mon, 19 Jun 2006 09:51:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qmowtmswvYk29AOdyOyt8YaKyKP65PJEGo2Wo11PUOg9HgAEsN31IO2DozOTV5V9Te6KWylVdYWw1iueeQ9FpTXgQ4vGblx6sgqIb9HIvRf3LPlMWZTNNHnmcf3lAHpXUD64Bjw5Geb5CLeDn/CelLBc1wa6dctSkQn3YNKlNTY= Received: by 10.35.76.5 with SMTP id d5mr8518153pyl; Mon, 19 Jun 2006 09:51:02 -0700 (PDT) Received: by 10.35.125.6 with HTTP; Mon, 19 Jun 2006 09:51:01 -0700 (PDT) Message-ID: <3bcb4e3f0606190951xef1495dr3c608c8da038a6f5@mail.gmail.com> Date: Mon, 19 Jun 2006 20:51:01 +0400 From: "Nick Borisov" To: freebsd-security@freebsd.org In-Reply-To: <3bcb4e3f0606190950w2c992b21y78f2235304c2f31a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bcb4e3f0606190728m29b67270mda8088eab2ff0ba1@mail.gmail.com> <20060619151636.10431.qmail@web30301.mail.mud.yahoo.com> <3bcb4e3f0606190950w2c992b21y78f2235304c2f31a@mail.gmail.com> Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 16:51:03 -0000 2006/6/19, R. B. Riddick : > I know personally of a case where > somebody (mis(?))configured a NFS service (maybe it was a honey-pot, or so?), > so that everyone had read/write access as _root_. It was possible to transfer > about 20MB of data over about one hour from a single IP, that was never seen > there before... Well, you are not goin' to say that was a great achievement of those administrators, are you? =) From owner-freebsd-security@FreeBSD.ORG Mon Jun 19 17:24:00 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB82316A474 for ; Mon, 19 Jun 2006 17:24:00 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30304.mail.mud.yahoo.com (web30304.mail.mud.yahoo.com [68.142.200.97]) by mx1.FreeBSD.org (Postfix) with SMTP id CFE3B43D45 for ; Mon, 19 Jun 2006 17:23:59 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 53574 invoked by uid 60001); 19 Jun 2006 17:23:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=o+kmpyvCOVooYYTq9wluJxLkzK72QFJJ+n2/cfE3W3y6Gajsae0V7LeD868kJA2EbUBe3z+SgpsYVq4bd6wNs/LYHHoxFDl9qbnReWzYostv3EGqSHRpAOr3pvnc7jly5oirokTWU/HHk22k7eB5IbYj13MA0auBZf2F8tHcyOs= ; Message-ID: <20060619172359.53572.qmail@web30304.mail.mud.yahoo.com> Received: from [213.54.84.110] by web30304.mail.mud.yahoo.com via HTTP; Mon, 19 Jun 2006 10:23:59 PDT Date: Mon, 19 Jun 2006 10:23:59 -0700 (PDT) From: "R. B. Riddick" To: Nick Borisov , freebsd-security@freebsd.org In-Reply-To: <3bcb4e3f0606190951xef1495dr3c608c8da038a6f5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: memory pages nulling when releasing 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, 19 Jun 2006 17:24:01 -0000 --- Nick Borisov wrote: > 2006/6/19, R. B. Riddick : > > It was possible to transfer about 20MB of data over about > > one hour from a single IP, that was never seen there before... > > Well, you are not goin' to say that was a great achievement of those > administrators, are you? =) > No, I will not say or write, that they did a good job (especially because it was possible to prove the "attack" after a few seconds (technically - since IPs dont lie!?) and after a few minutes (administratively - since it was about noon, so that the local administrators were present)). There is even a cinema movie and a book about them (somehow there was some loophole before...). Its is called "23", I think... Some people will never learn... http://german.imdb.com/title/tt0126765/ -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-security@FreeBSD.ORG Tue Jun 20 02:54:00 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CC4716A479 for ; Tue, 20 Jun 2006 02:54:00 +0000 (UTC) (envelope-from nick@nickwithers.com) Received: from mail.nickwithers.com (mail.manrags.com [203.219.206.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F79C43D46 for ; Tue, 20 Jun 2006 02:53:59 +0000 (GMT) (envelope-from nick@nickwithers.com) Received: from localhost (shmick.shmon.net [10.0.0.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nickwithers.com (Postfix) with ESMTP id C95EA3A37A; Tue, 20 Jun 2006 12:53:50 +1000 (EST) Date: Tue, 20 Jun 2006 12:53:50 +1000 From: Nick Withers To: Dan Lukes Message-Id: <20060620125350.10d0c9ef.nick@nickwithers.com> In-Reply-To: <44967861.6070509@obluda.cz> References: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> <44967861.6070509@obluda.cz> Organization: nickwithers.com X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.19; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-nickwithers-MailScanner: Found to be clean X-nickwithers-MailScanner-From: nick@nickwithers.com Cc: freebsd-security@freebsd.org Subject: Re: memory pages nulling when releasing 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, 20 Jun 2006 02:54:00 -0000 On Mon, 19 Jun 2006 12:11:45 +0200 Dan Lukes wrote: (snip) > To Nick: OS doesn't zero on free. FreeBSD does*, if the "J" flag is set in _malloc_options / MALLOC_OPTIONS, as per my original message (or at least, I believe this is the case, going by malloc(3)'s man page - please correct me if I'm wrong). * Alright, it doesn't zero, as such, but will (again, unless I've misunderstood the malloc(3) man page) initialise each byte to 0xd0 > For better security of your sensitive data you need zero the memory by > self. For inspiration I recommend to see the CRYPT_malloc/CRYPT_free > implementation in OpenSSL. Don't forget the edge situations also (when > your program can prematurely exits, you need the clean the key memory > on "atexit" or so). Good point, I hadn't thought of that! > You may need to avoid swapping of memory with sensitive data also - see > man mlock. > > But security knows no simple measures. You need think carefully about > your specific situation then decide what measures are appropriate. More > security measures may not cause more real security - it can have > opposite effect also. > > Dan > > > -- > Dan Lukes SISAL MFF UK > AKA: dan@obluda.cz, dan@freebsd.cz,dan@kolej.mff.cuni.cz -- Nick Withers email: nick@nickwithers.com Web: http://www.nickwithers.com Mobile: +61 414 397 446 From owner-freebsd-security@FreeBSD.ORG Tue Jun 20 04:16:55 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7738716A47A for ; Tue, 20 Jun 2006 04:16:55 +0000 (UTC) (envelope-from neiro21@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08BD543D48 for ; Tue, 20 Jun 2006 04:16:52 +0000 (GMT) (envelope-from neiro21@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so1463791pya for ; Mon, 19 Jun 2006 21:16:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r9LKf1nERDIzqrEJA5ZIvywp6mPNP6bnPDLBH84AgUl6NhGVEk7RJF4vZdGrmzaa3hxSyPBQ2pzNOfN//fsQK0NAcfE/NZyLnERgufQyjF84kDZYj3claO5SUAhUPjV2+jqAEQIRNQlWIQurLBmhMc7HM8hgIIbVeQfvEfwWbh8= Received: by 10.35.101.9 with SMTP id d9mr6430175pym; Mon, 19 Jun 2006 21:16:52 -0700 (PDT) Received: by 10.35.125.6 with HTTP; Mon, 19 Jun 2006 21:16:52 -0700 (PDT) Message-ID: <3bcb4e3f0606192116t58fda53ci55dd1d596b8f5842@mail.gmail.com> Date: Tue, 20 Jun 2006 08:16:52 +0400 From: "Nick Borisov" To: "Nick Withers" , freebsd-security@freebsd.org In-Reply-To: <20060620125350.10d0c9ef.nick@nickwithers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> <44967861.6070509@obluda.cz> <20060620125350.10d0c9ef.nick@nickwithers.com> Cc: Subject: Re: memory pages nulling when releasing 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, 20 Jun 2006 04:16:55 -0000 2006/6/20, Nick Withers : > * Alright, it doesn't zero, as such, but will (again, unless > I've misunderstood the malloc(3) man page) initialise each byte > to 0xd0 There's "Z" malloc option that's used to initialise page with zeros instead of 0xd0 From owner-freebsd-security@FreeBSD.ORG Tue Jun 20 12:19:27 2006 Return-Path: X-Original-To: freebsd-security@FreeBSD.ORG Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A58B16A47B for ; Tue, 20 Jun 2006 12:19:27 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88F4143D6B for ; Tue, 20 Jun 2006 12:19:24 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (hevuhu@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k5KCJHTu067326 for ; Tue, 20 Jun 2006 14:19:22 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k5KCJHlS067325; Tue, 20 Jun 2006 14:19:17 +0200 (CEST) (envelope-from olli) Date: Tue, 20 Jun 2006 14:19:17 +0200 (CEST) Message-Id: <200606201219.k5KCJHlS067325@lurza.secnetix.de> From: Oliver Fromme To: freebsd-security@FreeBSD.ORG In-Reply-To: <3bcb4e3f0606181309h70c08dc6l691bbb6e5b48615a@mail.gmail.com> X-Newsgroups: list.freebsd-security User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 20 Jun 2006 14:19:22 +0200 (CEST) X-Mailman-Approved-At: Tue, 20 Jun 2006 14:41:13 +0000 Cc: Subject: Re: memory pages nulling when releasing X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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, 20 Jun 2006 12:19:27 -0000 Nick Borisov wrote: > Dag-Erling Smørgrav wrote: > > "Nick Borisov" wrote: > > > Could you tell me if FreeBSD supports memory page nulling when > > > releasing it to prevent unauthorized access to data left in the page > > > after it's allocated again. > > > > Processes always get zeroed pages from the kernel. This is the case > > for all Unices, and has been for decades. > > Well, providing zeroed pages to processes is not quite similar to > explicit cleaning of pages after use as some security standards > demand. If that's what you mean, then why not simply use memset() after use? (And of course use mlock().) If that's not what you mean, then please explain _exactly_ what you mean. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From owner-freebsd-security@FreeBSD.ORG Tue Jun 20 15:05:53 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAE4616A47B for ; Tue, 20 Jun 2006 15:05:53 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [195.113.24.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BD1043D6E for ; Tue, 20 Jun 2006 15:05:52 +0000 (GMT) (envelope-from dan@obluda.cz) X-Envelope-From: dan@obluda.cz Received: from [10.20.0.26] (openvpn.ms.mff.cuni.cz [195.113.20.87]) by smtp1.kolej.mff.cuni.cz (8.13.1/8.13.1) with ESMTP id k5KF6A31084595 for ; Tue, 20 Jun 2006 17:06:12 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <44980ECC.5000607@obluda.cz> Date: Tue, 20 Jun 2006 17:05:48 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.4) Gecko/20060605 SeaMonkey/1.0.2 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> <44967861.6070509@obluda.cz> <20060620125350.10d0c9ef.nick@nickwithers.com> In-Reply-To: <20060620125350.10d0c9ef.nick@nickwithers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: memory pages nulling when releasing 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, 20 Jun 2006 15:05:54 -0000 Nick Withers napsal/wrote, On 06/20/06 04:53: >> To Nick: OS doesn't zero on free. > > FreeBSD does*, if the "J" flag is set in _malloc_options / You speak what the libc does, not about OS itself. I can wrote program using brk/sbrk (another libc functions) to manage it's memory. It set the "end margin" of program's data segment. I think it doesn't zero the end of data segment before shrinking. But I need no libc to wrote a program at all ... Well, if we want to speak about OS memory management we need to clarify what the memory we speak of and what exactly we thing saying "free of a memory". > * Alright, it doesn't zero, as such, but will (again, unless > I've misunderstood the malloc(3) man page) initialise each byte > to 0xd0 2006/6/20, Nick Withers : > There's "Z" malloc option that's used to initialise page with zeros > instead of 0xd0 Difference betwen Z and J isn't the fill value only. Z apply for allocations of new memory (when imalloc() called); J apply on changes in allocated block size (e.g. realloc) and free. So 'Z' doesn't "zero on free" but "zero on alloc". Well, things aren't simple as Z implies J ... BTW, Z nor J doesn't imply 'R' despite of text of manual page. Dan -- Dan Lukes SISAL MFF UK AKA: dan@obluda.cz, dan@freebsd.cz,dan@kolej.mff.cuni.cz From owner-freebsd-security@FreeBSD.ORG Tue Jun 20 19:19:06 2006 Return-Path: X-Original-To: freebsd-security@FreeBSD.org Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D448616A479; Tue, 20 Jun 2006 19:19:06 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [195.113.24.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AB0243D48; Tue, 20 Jun 2006 19:19:05 +0000 (GMT) (envelope-from dan@obluda.cz) X-Envelope-From: dan@obluda.cz Received: from [10.20.0.26] (openvpn.ms.mff.cuni.cz [195.113.20.87]) by smtp1.kolej.mff.cuni.cz (8.13.1/8.13.1) with ESMTP id k5KJJO7H095699; Tue, 20 Jun 2006 21:19:26 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <44984A25.8060001@obluda.cz> Date: Tue, 20 Jun 2006 21:19:01 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.4) Gecko/20060605 SeaMonkey/1.0.2 MIME-Version: 1.0 To: Jason Evans References: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> <44967861.6070509@obluda.cz> <20060620125350.10d0c9ef.nick@nickwithers.com> <44980ECC.5000607@obluda.cz> <20060620170353.GB90842@gothmog.pc> <449833DD.70904@FreeBSD.org> In-Reply-To: <449833DD.70904@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, Giorgos Keramidas Subject: Re: memory pages nulling when releasing 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, 20 Jun 2006 19:19:06 -0000 Jason Evans napsal/wrote, On 06/20/06 19:43: >>> BTW, Z nor J doesn't imply 'R' despite of text of manual page. > The man page looks accurate to me. What aspect of the descriptions of > 'J' and 'Z' do you think is incorrect? From manual page: ======================= J ... This options also sets the ``R'' option. ... Z This option implicitly sets the ``J'' and ``R'' options, ======================= From libc/stdlib/malloc.c (the lines containing malloc_realloc + some lines around) ======================= static int malloc_realloc; ... case 'r': malloc_realloc = 0; break; case 'R': malloc_realloc = 1; break; case 'j': malloc_junk = 0; break; ... if (!malloc_realloc && /* Unless we have to, */ size <= osize && /* .. or are too small, ... if (!malloc_realloc && /* Unless we have to, */ size <= osize && /* ..or are too small, */ ======================= The malloc_realloc seems to be set on one place only - when R/r present. Then it is used only. I see no dependency to J nor Z I send no PR because I have submitted several more important PR's which are untouched for months. I don't want to overload committers nor PR database. Dan -- Dan Lukes SISAL MFF UK AKA: dan@obluda.cz, dan@freebsd.cz,dan@kolej.mff.cuni.cz From owner-freebsd-security@FreeBSD.ORG Tue Jun 20 17:04:13 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C48F16A49E; Tue, 20 Jun 2006 17:04:13 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 147A443D46; Tue, 20 Jun 2006 17:04:11 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.7/8.13.7/Debian-1) with ESMTP id k5KH3x9T022957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 20:04:01 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k5KH3rDx091106; Tue, 20 Jun 2006 20:03:53 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k5KH3ra4091105; Tue, 20 Jun 2006 20:03:53 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Tue, 20 Jun 2006 20:03:53 +0300 From: Giorgos Keramidas To: Dan Lukes , Jason Evans Message-ID: <20060620170353.GB90842@gothmog.pc> References: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> <44967861.6070509@obluda.cz> <20060620125350.10d0c9ef.nick@nickwithers.com> <44980ECC.5000607@obluda.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44980ECC.5000607@obluda.cz> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.214, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.18, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No X-Mailman-Approved-At: Wed, 21 Jun 2006 02:00:27 +0000 Cc: freebsd-security@freebsd.org Subject: Re: memory pages nulling when releasing 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, 20 Jun 2006 17:04:13 -0000 On 2006-06-20 17:05, Dan Lukes wrote: >> There's "Z" malloc option that's used to initialise page with zeros >> instead of 0xd0 > > Difference betwen Z and J isn't the fill value only. Z apply > for allocations of new memory (when imalloc() called); J apply > on changes in allocated block size (e.g. realloc) and free. So > 'Z' doesn't "zero on free" but "zero on alloc". Well, things > aren't simple as Z implies J ... > > BTW, Z nor J doesn't imply 'R' despite of text of manual page. Are you sure? Then we should fix the manpage. Cc'ing Jason Evans, who may be interested too. From owner-freebsd-security@FreeBSD.ORG Tue Jun 20 17:44:01 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8461D16A474; Tue, 20 Jun 2006 17:44:01 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A9BA43D46; Tue, 20 Jun 2006 17:44:01 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id 00C095E4919; Tue, 20 Jun 2006 10:44:00 -0700 (PDT) Received: from [192.168.168.201] (70-37-200-108.losaca.adelphia.net [70.37.200.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 9042C5E4912; Tue, 20 Jun 2006 10:43:59 -0700 (PDT) Message-ID: <449833DD.70904@FreeBSD.org> Date: Tue, 20 Jun 2006 10:43:57 -0700 From: Jason Evans User-Agent: Mozilla Thunderbird 1.0.8-1.4.1 (X11/20060420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> <44967861.6070509@obluda.cz> <20060620125350.10d0c9ef.nick@nickwithers.com> <44980ECC.5000607@obluda.cz> <20060620170353.GB90842@gothmog.pc> In-Reply-To: <20060620170353.GB90842@gothmog.pc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on lh.synack.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.6 X-Mailman-Approved-At: Wed, 21 Jun 2006 02:00:55 +0000 Cc: Dan Lukes , freebsd-security@freebsd.org Subject: Re: memory pages nulling when releasing 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, 20 Jun 2006 17:44:01 -0000 Giorgos Keramidas wrote: > On 2006-06-20 17:05, Dan Lukes wrote: > >>>There's "Z" malloc option that's used to initialise page with zeros >>>instead of 0xd0 >> >>Difference betwen Z and J isn't the fill value only. Z apply >>for allocations of new memory (when imalloc() called); J apply >>on changes in allocated block size (e.g. realloc) and free. So >>'Z' doesn't "zero on free" but "zero on alloc". Well, things >>aren't simple as Z implies J ... >> >>BTW, Z nor J doesn't imply 'R' despite of text of manual page. > > > Are you sure? Then we should fix the manpage. > Cc'ing Jason Evans, who may be interested too. The man page looks accurate to me. What aspect of the descriptions of 'J' and 'Z' do you think is incorrect? Thanks, Jason From owner-freebsd-security@FreeBSD.ORG Tue Jun 20 19:44:44 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F86F16A479; Tue, 20 Jun 2006 19:44:44 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1440143D48; Tue, 20 Jun 2006 19:44:44 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id ED5455E4919; Tue, 20 Jun 2006 12:44:43 -0700 (PDT) Received: from [192.168.168.201] (70-37-200-108.losaca.adelphia.net [70.37.200.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 852675E4912; Tue, 20 Jun 2006 12:44:42 -0700 (PDT) Message-ID: <44985028.6020901@FreeBSD.org> Date: Tue, 20 Jun 2006 12:44:40 -0700 From: Jason Evans User-Agent: Mozilla Thunderbird 1.0.8-1.4.1 (X11/20060420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Lukes References: <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> <44967861.6070509@obluda.cz> <20060620125350.10d0c9ef.nick@nickwithers.com> <44980ECC.5000607@obluda.cz> <20060620170353.GB90842@gothmog.pc> <449833DD.70904@FreeBSD.org> <44984A25.8060001@obluda.cz> In-Reply-To: <44984A25.8060001@obluda.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on lh.synack.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.6 X-Mailman-Approved-At: Wed, 21 Jun 2006 02:01:10 +0000 Cc: freebsd-security@freebsd.org, Giorgos Keramidas Subject: Re: memory pages nulling when releasing 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, 20 Jun 2006 19:44:44 -0000 Dan Lukes wrote: > Jason Evans napsal/wrote, On 06/20/06 19:43: > >>>> BTW, Z nor J doesn't imply 'R' despite of text of manual page. > >> The man page looks accurate to me. What aspect of the descriptions of >> 'J' and 'Z' do you think is incorrect? > > From manual page: > ======================= > J ... > This options also sets the ``R'' option. > ... > Z This option implicitly sets the ``J'' and ``R'' options, > ======================= > > From libc/stdlib/malloc.c (the lines containing malloc_realloc + > some lines around) > ======================= > static int malloc_realloc; > ... > case 'r': malloc_realloc = 0; break; > case 'R': malloc_realloc = 1; break; > case 'j': malloc_junk = 0; break; > ... > if (!malloc_realloc && /* Unless we have to, */ > size <= osize && /* .. or are too small, ... > if (!malloc_realloc && /* Unless we have to, */ > size <= osize && /* ..or are too small, */ > ======================= > > The malloc_realloc seems to be set on one place only - when R/r > present. Then it is used only. I see no dependency to J nor Z > > I send no PR because I have submitted several more important PR's > which are untouched for months. I don't want to overload committers nor > PR database. Ah, this is for RELENG_6. I had assumed you were talking about -current. I agree with you that the man page is inaccurate for RELENG_6. I don't currently use RELENG_6 for development though, so I'd recommend submitting a PR with a patch assigned to the docs folks if you want it fixed. In my experience they are very responsive where man page accuracy is concerned. Jason From owner-freebsd-security@FreeBSD.ORG Tue Jun 20 20:24:45 2006 Return-Path: X-Original-To: freebsd-security@FreeBSD.org Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFE1516A474; Tue, 20 Jun 2006 20:24:44 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 164E543D45; Tue, 20 Jun 2006 20:24:43 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.7/8.13.7/Debian-1) with ESMTP id k5KKOVoR003486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 23:24:32 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k5KKOO6G011576; Tue, 20 Jun 2006 23:24:24 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k5KKOOl9011575; Tue, 20 Jun 2006 23:24:24 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Tue, 20 Jun 2006 23:24:24 +0300 From: Giorgos Keramidas To: Jason Evans , Dan Lukes Message-ID: <20060620202424.GB11347@gothmog.pc> References: <44980ECC.5000607@obluda.cz> <20060620170353.GB90842@gothmog.pc> <449833DD.70904@FreeBSD.org> <44984A25.8060001@obluda.cz> <20060618203903.31161.qmail@web30306.mail.mud.yahoo.com> <44967861.6070509@obluda.cz> <20060620125350.10d0c9ef.nick@nickwithers.com> <44980ECC.5000607@obluda.cz> <20060620170353.GB90842@gothmog.pc> <449833DD.70904@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44985028.6020901@FreeBSD.org> <44984A25.8060001@obluda.cz> <449833DD.70904@FreeBSD.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.235, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.16, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No X-Mailman-Approved-At: Wed, 21 Jun 2006 02:01:20 +0000 Cc: freebsd-security@FreeBSD.org Subject: Re: memory pages nulling when releasing 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, 20 Jun 2006 20:24:45 -0000 On 2006-06-20 10:43, Jason Evans wrote: >Giorgos Keramidas wrote: >>On 2006-06-20 17:05, Dan Lukes wrote: >>>BTW, Z nor J doesn't imply 'R' despite of text of manual page. >> >> Are you sure? Then we should fix the manpage. >> Cc'ing Jason Evans, who may be interested too. > > The man page looks accurate to me. What aspect of the descriptions of > 'J' and 'Z' do you think is incorrect? On 2006-06-20 21:19, Dan Lukes wrote: > From manual page: > ======================= > J ... > This options also sets the ``R'' option. > ... > Z This option implicitly sets the ``J'' and ``R'' options, > ======================= > > > From libc/stdlib/malloc.c (the lines containing malloc_realloc + > some lines around) > ======================= > static int malloc_realloc; > ... > case 'r': malloc_realloc = 0; break; > case 'R': malloc_realloc = 1; break; > case 'j': malloc_junk = 0; break; > ... > if (!malloc_realloc && /* Unless we have > to, */ > size <= osize && /* .. or are too small, ... > if (!malloc_realloc && /* Unless we have to, */ > size <= osize && /* ..or are too small, */ > ======================= > > The malloc_realloc seems to be set on one place only - when R/r > present. Then it is used only. I see no dependency to J nor Z > > I send no PR because I have submitted several more important PR's > which are untouched for months. I don't want to overload committers > nor PR database. No, that's ok. It's better to send what you have found so it won't be missed forever :-) On 2006-06-20 12:44, Jason Evans wrote: > Ah, this is for RELENG_6. I had assumed you were talking about > -current. I agree with you that the man page is inaccurate for > RELENG_6. I don't currently use RELENG_6 for development though, so > I'd recommend submitting a PR with a patch assigned to the docs folks > if you want it fixed. In my experience they are very responsive where > man page accuracy is concerned. Sure! Dan, if you submit a PR, then feel free to include my own address at the Cc: line of send-pr's report. Then I'll grab the PR and work through the necessary changes for RELENG_6 with you. Thanks for bringing this manpage bug to our attention :) - Giorgos