From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9140 Path: news.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Non-stub setvbuf Date: Sun, 17 Jan 2016 12:03:34 +0100 Message-ID: <20160117110334.GK2016@debian> References: <20160117014350.GA31121@brightrain.aerifal.cx> <1453021192.29168.1.camel@inria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1453028638 1142 80.91.229.3 (17 Jan 2016 11:03:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Jan 2016 11:03:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9153-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 17 12:03:54 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aKl7h-00051g-8h for gllmg-musl@m.gmane.org; Sun, 17 Jan 2016 12:03:53 +0100 Original-Received: (qmail 29894 invoked by uid 550); 17 Jan 2016 11:03:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 29873 invoked from network); 17 Jan 2016 11:03:49 -0000 Content-Disposition: inline In-Reply-To: <1453021192.29168.1.camel@inria.fr> User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:QcD+gDEBANCtRXh0pEQ1yTO1GRC2C7i4eupxOTnYDpLWAE6Vx28 OfAguZhHG3zBtymjmkJRQuICxSDvDSB4BL4nKLRCGMAG+Ejta8OwxQDlSOkTCtDhX/tlnJs SOZbb3n8nw1AF9v5UWQTyK/YFx+6kmFxzFRAXH41sPDCCmcOnYLzlN0fkWBZKWI0W9mFMfe YN8+hA1Zqa5djgNxbT9Qw== X-UI-Out-Filterresults: notjunk:1;V01:K0:+TQ7SDBkPrE=:JKQyPY2yKSyvSF1iw+o22l //KJfm/435dQJbbI9AGK8WPz4Yh1RL/xYafP7NRfqBw8Ac6IcOBU93JNeh8kQBSt3rwRNfwtE R0LyEJ7IYKpP1lfnGZfBiu9F96SsQcn7r8LhCSnYn8jEy4dLxmqakFKQjR+G9CN4WPV04CC8W 6UbZmAp/3tLqmRap2FfgEtRXPoSjk7x4dtkyU9MPLHM1WnltTyOEaOi1vdzubn3BgzezjlUt6 bBQAY0Hdu6uLbLs7I3eqzdkFmQZ/YySjruzRbJGvjCnkkgs0kO6afyjLbrAdEW2DzMIwi3oWk 9OQXtytIgSlZ1R9nvDh24In5hA/CEiFKkwn1iqsp1at95PXIEYExwLVUUMdvowP2TgnX46m5E BNQsbXAxcEbhgp/nfk3/psSJfPkfr4HcZZY4HQpPUrnMOdbTV59JmrjdcZbb9W9MySCClW/f7 +imOlAerZ6O677XH5kZW1dHppRCflC1jlynDkcRzc3S4D/jgcTHCOwvlVk7IdlE/wz2f1M2/3 UJQEPeL/q/Xn/eDZj8cmNzfWUtH+L6aLh1U1oSODCNHOBNnREp7wfn6Z9Py8Vz0IdKNpCHV9A olYE9uq5zEjBMIy6ZLzxYfCAafqoWzSHGUC8zlqjLhqrEzQbxofFl4nVEBMI2AYULyt1XA3tC 225VEtBNIBiQtPi/zBZ3fwmAufIZ406IZykO5+hI07OuZjCraJUPYRKwSc+vJsZ6QFFAP1eGW 0zV2ac2IJMUrcR2LbyzREyrPkesurmzsZGfKFf6MVw//67xE1/yrl33Do/SSlKJXGpjM3gZw Xref: news.gmane.org gmane.linux.lib.musl.general:9140 Archived-At: On Sun, Jan 17, 2016 at 09:59:52AM +0100, Jens Gustedt wrote: > Am Samstag, den 16.01.2016, 20:43 -0500 schrieb Rich Felker: > > Right now, musl's stdio setvbuf function does nothing but set the > > buffering mode; it does not honor the buffer provided by the caller. > > This is perfectly conforming (whether or how the buffer is used is > > unspecified), but I realized from the recent thread about OpenSSH's > > CVE-2016-0777 on oss-security that a non-stub setvbuf admits a nice > > type of hardening: > > > > http://www.openwall.com/lists/oss-security/2016/01/15/15 > > > > In short, the application has no way to scrub implementation-internal > > stdio buffers that might contain sensitive data read from or written > > to files, but it can scrub buffers it provides via setvbuf. So, I'd > > like to start actually using the latter, so that apps that attempt > > this hardening measure can benefit from it on musl like they would on > > other implementations. > > How about just using setvbuf as an indication that the user wants the > buffer to be scrubbed? And so just zero it? > > I wouldn't expect setvbuf to be used in places that are performance > critical, so an additional memset shouldn't do much harm, I think. > That isn't the use everyone has for it. I routinely set stdout and stdin to line buffered in my programs, because glibc sets the buffering mode for these streams based on file type, and I want to be consistent in all cases. And those applications can be performance critical. But then, I provide no buffer to these calls, so maybe differentiate on that? OTOH, full control over buffering is only possible on the syscall level anyway, so maybe FILEs are inherently insecure for these purposes? Ciao, Markus