Re: Non-stub setvbuf

[Markus Wichmann <nullplan@gmx.net>]

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