From owner-freebsd-security@FreeBSD.ORG Wed Jul 27 07:11:59 2011 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 83B8A106564A for ; Wed, 27 Jul 2011 07:11:59 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1008FC14 for ; Wed, 27 Jul 2011 07:11:59 +0000 (UTC) Received: by gxk28 with SMTP id 28so1058207gxk.13 for ; Wed, 27 Jul 2011 00:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ryO65P0McvShe+A6Ks0ds7RJHMTuztqFsOtVL+60FNw=; b=T+9bYkK6aOkZ+eaP3JkD7Uv4D3qYKCOAblGlHjavdfWXB33SdEAiGt2VNcCBUXxvjC mCYHIavpQsksN69UDCVQPSe4AK79YQDcrVdrMq+rWdjAKHm2tCDCPe6q21GCuWEiR8b6 pnoPUuOapzsrLutfcp0ZyLDPUCRZqYe9Js244= MIME-Version: 1.0 Received: by 10.142.169.4 with SMTP id r4mr4036957wfe.423.1311749388299; Tue, 26 Jul 2011 23:49:48 -0700 (PDT) Received: by 10.142.43.1 with HTTP; Tue, 26 Jul 2011 23:49:48 -0700 (PDT) Date: Wed, 27 Jul 2011 02:49:48 -0400 Message-ID: From: grarpamp To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 27 Jul 2011 12:04:45 +0000 Subject: Malloc -Z X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 07:11:59 -0000 Was reading malloc(3) while chasing corruption suspects. Does the presence of -Z imply that without it, programs can be allocated dirty (non-zeroed) memory? If so, it seems running with -Z would be prudent if one cares. Therefore, what is the rough percent performance impact of -Z compared to default malloc? Bonus: What would be needed to make the useful streams: /dev/one /dev/10 /dev/01 In addition to /dev/zero. From owner-freebsd-security@FreeBSD.ORG Wed Jul 27 13:03:01 2011 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 5D87F106566B for ; Wed, 27 Jul 2011 13:03:01 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from hosted.gothic.net.au (eth1539.vic.adsl.internode.on.net [150.101.217.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1B38FC15 for ; Wed, 27 Jul 2011 13:03:00 +0000 (UTC) Received: from hosted.gothic.net.au (localhost [127.0.0.1]) by hosted.gothic.net.au (Postfix) with ESMTP id 8EF4B8DF427; Wed, 27 Jul 2011 22:44:56 +1000 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from hosted.gothic.net.au ([127.0.0.1]) by hosted.gothic.net.au (hosted.gothic.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT5Ro1Ho1aGT; Wed, 27 Jul 2011 22:44:46 +1000 (EST) Received: from samael.gothic.net.au (eth1540.vic.adsl.internode.on.net [150.101.217.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sean@gothic.net.au) by hosted.gothic.net.au (Postfix) with ESMTPSA id A60ED8DF425; Wed, 27 Jul 2011 22:44:46 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Sean In-Reply-To: Date: Wed, 27 Jul 2011 22:44:45 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: grarpamp X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-security@freebsd.org Subject: Re: Malloc -Z X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:03:01 -0000 On 27/07/2011, at 4:49 PM, grarpamp wrote: > Was reading malloc(3) while chasing corruption suspects. > Does the presence of -Z imply that without it, programs > can be allocated dirty (non-zeroed) memory? > If so, it seems running with -Z would be prudent if one cares. > Therefore, what is the rough percent performance > impact of -Z compared to default malloc? >=20 malloc(3) has never provided zeroed memory. If you need zeroed memory in = C, you either need to zero it yourself using memset(3), or use = calloc(3). It's been part of the language standard for over 20 years now, and is = the same in that regard on every platform that provides malloc(3). What would be prudent as a developer (and is the default in CURRENT I = believe) is to use J - it enforces the "memory from malloc(3) is not = guaranteed to be zeroed." by specifically setting it to non-zero. > Bonus: > What would be needed to make the useful streams: > /dev/one > /dev/10 > /dev/01 > In addition to /dev/zero. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to = "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Wed Jul 27 13:32:32 2011 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 1E7CC106566B for ; Wed, 27 Jul 2011 13:32:32 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D684C8FC1B for ; Wed, 27 Jul 2011 13:32:31 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 7496A5E20; Wed, 27 Jul 2011 13:13:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p6RDDA2V011235; Wed, 27 Jul 2011 13:13:11 GMT (envelope-from phk@phk.freebsd.dk) To: Sean From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 27 Jul 2011 22:44:45 +1000." Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 27 Jul 2011 13:13:10 +0000 Message-ID: <11234.1311772390@critter.freebsd.dk> Cc: freebsd-security@freebsd.org, grarpamp Subject: Re: Malloc -Z X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:32:32 -0000 In message , Sean writes: >It's been part of the language standard for over 20 years now, [...] Much longer, it's specifically mentioned in the old testament. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Wed Jul 27 15:38:40 2011 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 223961065673 for ; Wed, 27 Jul 2011 15:38:40 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id D742F8FC1C for ; Wed, 27 Jul 2011 15:38:39 +0000 (UTC) Received: by pzk5 with SMTP id 5so8267147pzk.17 for ; Wed, 27 Jul 2011 08:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hdBPKTDLmpOAuQ8UskBai+cSDmpnltHesDwMbjT2+Bs=; b=CBn897r09dcxrDKgzCE7f6fkt1hURjfG7wZ5Xun8kOY55vpPwwc8Ct8RC4omil2D76 ulQKvjoiYwTCShEkw+9Swj4h6rnmYK5Nx0FL5t6S5Dx89qzj+qOBqpNyOxQr7prQ+W/9 B6bYuxWvC4hIpWNMNX77WW3gw5zY7koJghHjY= MIME-Version: 1.0 Received: by 10.68.0.131 with SMTP id 3mr266594pbe.147.1311779713674; Wed, 27 Jul 2011 08:15:13 -0700 (PDT) Received: by 10.68.46.199 with HTTP; Wed, 27 Jul 2011 08:15:13 -0700 (PDT) In-Reply-To: <11234.1311772390@critter.freebsd.dk> References: <11234.1311772390@critter.freebsd.dk> Date: Wed, 27 Jul 2011 11:15:13 -0400 Message-ID: From: "b. f." To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org, grarpamp Subject: Re: Malloc -Z X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:38:40 -0000 On 7/27/11, Poul-Henning Kamp wrote: > In message , Sean > writes: > >>It's been part of the language standard for over 20 years now, [...] > > Much longer, it's specifically mentioned in the old testament. > You are referring to this, perhaps?: Isaiah 26:14 They are dead, they shall not live; they are deceased, they shall not rise: therefore hast thou visited and destroyed them, and made all their memory to perish. Were you the one who chipped that into one of the tablets? b. From owner-freebsd-security@FreeBSD.ORG Wed Jul 27 17:17:00 2011 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 E52D0106566B for ; Wed, 27 Jul 2011 17:17:00 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 70FEC8FC13 for ; Wed, 27 Jul 2011 17:17:00 +0000 (UTC) Received: by yic13 with SMTP id 13so1550116yic.13 for ; Wed, 27 Jul 2011 10:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RFKz3Pmy087skDeCqUPAbKiKs5sImzVP66vYGJpl0tI=; b=P8y4Vb7IXGCZcVi1FCrzYq4ELejv98qCNS7isXaV8LfydVYTbSiV/JXtK48XYnyvJA IfkqfJBcoc+pUOUM1NcoELIAdVFGcFIEVgO4UeQ+d2oFg7FGSQNxKtRD3zopkJKUoY98 UHS9Rjld2mOMSjNHgwi3VVse481qLkhpV0Xak= MIME-Version: 1.0 Received: by 10.142.226.18 with SMTP id y18mr16741wfg.366.1311787019334; Wed, 27 Jul 2011 10:16:59 -0700 (PDT) Received: by 10.142.43.1 with HTTP; Wed, 27 Jul 2011 10:16:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jul 2011 13:16:59 -0400 Message-ID: From: grarpamp To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 27 Jul 2011 18:00:25 +0000 Subject: Re: Malloc -Z X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:17:01 -0000 > malloc(3) has never provided zeroed memory. If you need zeroed memory in C, > you either need to zero it yourself using memset(3), or use calloc(3). Or, in lieu, use -Z, presumably. > What would be prudent as a developer (and is the default in CURRENT I > believe) is to use J - it enforces the "memory from malloc(3) is not > guaranteed to be zeroed." by specifically setting it to non-zero. Hmm, well for debugging/fuzzing programs, Z or J could be useful. As would new R(random), 5(0x55), a(0xaa), and f(0xff) variations. But for security, it seems running with any of them set would be wise or flat out required. No? As in the case where users are untrusted (mischievous, but unable to gain root). Because while your own shiny new program may zero on free, all the other installed programs that handle 'sensitive' data may not. And without using say, Z... any user could scrape the box. Right? From owner-freebsd-security@FreeBSD.ORG Wed Jul 27 18:19:20 2011 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 CA6AD106566B for ; Wed, 27 Jul 2011 18:19:20 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 639F78FC13 for ; Wed, 27 Jul 2011 18:19:19 +0000 (UTC) Received: by wwg11 with SMTP id 11so3333480wwg.1 for ; Wed, 27 Jul 2011 11:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=yDYZaG3qISYjZFWwCp5QZatjmz2gBje2O67T0Lu2OYQ=; b=GbU3TgWgLLH6WAkCfzP3MMeif8P7bkdnzTLVV+wJfMsAWUjkjBSf5kdKZFGvgLPk9K 78kBAiCwZ7K2NP6oJJaofP6VxLncfYNSnHYmHphYDhagdDgniB3lHCeMO/OCYeeccNer nCHga+IgLFyDG/ESWkyfHrK4Oqs2Z89w49b3I= Received: by 10.227.7.80 with SMTP id c16mr83573wbc.40.1311788867593; Wed, 27 Jul 2011 10:47:47 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk [87.194.105.247]) by mx.google.com with ESMTPS id fc2sm95406wbb.18.2011.07.27.10.47.44 (version=SSLv3 cipher=OTHER); Wed, 27 Jul 2011 10:47:46 -0700 (PDT) Date: Wed, 27 Jul 2011 18:47:37 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20110727184737.137515b3@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Malloc -Z X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:19:20 -0000 On Wed, 27 Jul 2011 02:49:48 -0400 grarpamp wrote: > Was reading malloc(3) while chasing corruption suspects. > Does the presence of -Z imply that without it, programs > can be allocated dirty (non-zeroed) memory? Programs (in the sense of processes) are allocated zeroed-memory. Memory allocated by malloc will either be zeroed or contain pages written to by the same process. In general any security concerns about sensitive data should be handled by zeroing before freeing (or when the data is no longer needed) rather than zeroing on allocation. From owner-freebsd-security@FreeBSD.ORG Wed Jul 27 19:02:16 2011 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 0958F106566B for ; Wed, 27 Jul 2011 19:02:16 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8C0A08FC18 for ; Wed, 27 Jul 2011 19:02:15 +0000 (UTC) Received: by wwe6 with SMTP id 6so1697041wwe.31 for ; Wed, 27 Jul 2011 12:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=9YtAY1U8Pwv6rwY1mswPHHjOSqNIfmUmEkar/m129mA=; b=nvOSPz+Cfxj4sX6LLzMrQ0z5Y/YzPjb7blkZ2GX0LchWLDU6EkdTAn4HzF3GR4Lzt8 jAYQpRQGCHlJgGvMs/GDBem1NMR0kYVKyawcVx4lqBFeGkDYefzdfU6unh7Ow9GW5wiP 5UNWngN7JuMW/hIG4zXSQfQVow14lGbaOKML8= Received: by 10.227.39.134 with SMTP id g6mr3375989wbe.47.1311793334396; Wed, 27 Jul 2011 12:02:14 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk [87.194.105.247]) by mx.google.com with ESMTPS id fe4sm144123wbb.45.2011.07.27.12.02.10 (version=SSLv3 cipher=OTHER); Wed, 27 Jul 2011 12:02:13 -0700 (PDT) Date: Wed, 27 Jul 2011 20:02:06 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20110727200206.5ec12ce3@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Malloc -Z X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:02:16 -0000 On Wed, 27 Jul 2011 13:16:59 -0400 grarpamp wrote: > > malloc(3) has never provided zeroed memory. If you need zeroed > > memory in C, you either need to zero it yourself using memset(3), > > or use calloc(3). > > Or, in lieu, use -Z, presumably. > > > What would be prudent as a developer (and is the default in CURRENT > > I believe) is to use J - it enforces the "memory from malloc(3) is > > not guaranteed to be zeroed." by specifically setting it to > > non-zero. > > Hmm, well for debugging/fuzzing programs, Z or J could be useful. > As would new R(random), 5(0x55), a(0xaa), and f(0xff) variations. > > But for security, it seems running with any of them set would be > wise or flat out required. No? As in the case where users are > untrusted (mischievous, but unable to gain root). > > Because while your own shiny new program may zero on free, all > the other installed programs that handle 'sensitive' data may not. > And without using say, Z... any user could scrape the box. Right? No. It's only freed memory from the same process that can be read. Memory that's hung around in the heap long enough to to get reused. Memory released from other processes is zeroed by the kernel before it's mapped into the process's heap. From owner-freebsd-security@FreeBSD.ORG Wed Jul 27 19:19:56 2011 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 5E140106564A for ; Wed, 27 Jul 2011 19:19:56 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 475B58FC12 for ; Wed, 27 Jul 2011 19:19:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LP0003DN8960490@asmtp028.mac.com> for freebsd-security@freebsd.org; Wed, 27 Jul 2011 11:19:55 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-27_05:2011-07-27, 2011-07-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107270157 From: Chuck Swiger In-reply-to: Date: Wed, 27 Jul 2011 11:19:54 -0700 Message-id: <1E191B01-7DAA-48F3-8544-332D0282DA45@mac.com> References: To: grarpamp X-Mailer: Apple Mail (2.1084) Cc: freebsd-security@freebsd.org Subject: Re: Malloc -Z X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:19:56 -0000 On Jul 27, 2011, at 10:16 AM, grarpamp wrote: >> malloc(3) has never provided zeroed memory. If you need zeroed memory in C, >> you either need to zero it yourself using memset(3), or use calloc(3). > > Or, in lieu, use -Z, presumably. No developer should ever assume that malloc(3) returns zeroed memory. If they want that, they need to use calloc(3), exactly as Sean said. >> What would be prudent as a developer (and is the default in CURRENT I >> believe) is to use J - it enforces the "memory from malloc(3) is not >> guaranteed to be zeroed." by specifically setting it to non-zero. > > Hmm, well for debugging/fuzzing programs, Z or J could be useful. > As would new R(random), 5(0x55), a(0xaa), and f(0xff) variations. Most of those letters are already used for other aspects of malloc's behavior. > But for security, it seems running with any of them set would be > wise or flat out required. No? As in the case where users are > untrusted (mischievous, but unable to gain root). No. If the software is only secure because of platform-specific flags which change the default malloc behavior, then the software isn't secure. > Because while your own shiny new program may zero on free, all > the other installed programs that handle 'sensitive' data may not. > And without using say, Z... any user could scrape the box. Right? The kernel keeps a pool of prezero'ed pages available which it provides to processes when they need them. There shouldn't be a disclosure of information from one process to another, even if the first process never zeros memory. However, this being said, it is recommended that processes using getpass() and similar with OpenSSL keys ought to zero out the password or private key buffers as soon as possible to avoid leaving plain-text passwords in memory. Anything which provides direct DMA access, such as eSATA or firewire controllers, etc, can be used to scan memory for plaintext passwords, even if the operating system otherwise maintains good security between processes. Regards, -- -Chuck From owner-freebsd-security@FreeBSD.ORG Wed Jul 27 19:21:43 2011 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 26BBF106564A for ; Wed, 27 Jul 2011 19:21:43 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 0BFF68FC14 for ; Wed, 27 Jul 2011 19:21:43 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id A7AD114F38; Wed, 27 Jul 2011 12:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1311794502; bh=m86R8GS+EzAWHD3Hq9bnQlVvjeHGvps+cYX4uWQrCdg=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=yRKc/xALMMZyaHEOTsk+kiRXGxI5Heg7dP//k8qx1+eGj5Vct9Xol6sovesrgw89l b0gOUQNrNMiGpYtmxD56ZWm0KAJUo2X7126RhRU6c5wMVFHnAIRDpDnP3RpgI0mUCW LQa+JxZBU2cE7pXuP8ztDLV+QGoMZFsYcu0ildkc= Message-ID: <4E306545.6060008@delphij.net> Date: Wed, 27 Jul 2011 12:21:41 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-security@freebsd.org References: In-Reply-To: OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Malloc -Z X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:21:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/27/11 10:16, grarpamp wrote: >> malloc(3) has never provided zeroed memory. If you need zeroed >> memory in C, you either need to zero it yourself using memset(3), >> or use calloc(3). > > Or, in lieu, use -Z, presumably. > >> What would be prudent as a developer (and is the default in CURRENT >> I believe) is to use J - it enforces the "memory from malloc(3) is >> not guaranteed to be zeroed." by specifically setting it to >> non-zero. > > Hmm, well for debugging/fuzzing programs, Z or J could be useful. As > would new R(random), 5(0x55), a(0xaa), and f(0xff) variations. > > But for security, it seems running with any of them set would be wise > or flat out required. No? As in the case where users are untrusted > (mischievous, but unable to gain root). We usually want programs to "crash early" when there comes a bug, as if there is one uncovered bug, there is likely to be more bug undiscovered. My personal experience is that most C programs crashes when the buffer is not initialized properly rather than misbehaving and Z makes them "work" rather than break. Zero'ing memory usually gives consistent behavior (not to crash) rather than else. That's exactly why the - -CURRENT branch uses J and not Z by default. > Because while your own shiny new program may zero on free, all the > other installed programs that handle 'sensitive' data may not. And > without using say, Z... any user could scrape the box. Right? Programs that handles sensitive data should hold the sensitive data in memory as short as possible. Zeroing the memory ensures that "they are not there", as free(3) is not guaranteed to give the memory back to the kernel, which in turn WILL zero the page before handing it to another process. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJOMGVFAAoJEATO+BI/yjfB/vIIAKT1X/tF5gJ3waFzdPCG9T7h fKjSXqmxDzcV1cjn6BBc2GVhXOsCdGQE7P2Kc+t6xefZfBFXedDpMVRcPI+l506X uvy2OOxNowT/WkBaeJP1LqIfBBD9nQqrczFg+YjEhuvLGK3Q6K1BGlxXJtZjTvfH KgUiVZ1fog5Av2oXcCcx5qsDyltL8z/cy+JCjD7UQdt7TqZj9KGPLVHk5+tx0W71 UVWrxPU5V4MaAUqXjNott5Gzyh5uO6aemQkEKCH2jV7HUe15H9okX29I5/FJjK+Q MRqRLbMN3tamsRCjjfZY5jQhEZNFzDFmK7qfUQeqMc3p5oTOdlEZFTxiRTabSMA= =fqoZ -----END PGP SIGNATURE-----