Date: Sun, 17 Jan 2016 12:03:34 +0100 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: Non-stub setvbuf 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.