[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 16 Jan 2016 20:43:50 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Non-stub setvbuf
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.
The logic I have in mind is something like:
- Ignore application-provided buffers smaller than UNGET (8) bytes,
possibly plus some reasonable epsilon, and either turn off buffering
or keep the internal buffer in this case.
- If the application-provided buffer is larger than something
threshold M (maybe 16k) and the file mode admits reading, only use
the first M bytes of the buffer. Otherwise repeated fseek+getc is
very slow (uselessly refilling a large buffer each time).
Alternatively the logic to limit read buffer size could go in
__stdio_read.
Does this sound reasonable?
I also reviewed the lack of locking in setvbuf, which looks like it
risks data races accessing f->flags, but it actually seems fine since
the only code that could run concurrently with it without invoking UB
is __stdio_exit (or perhaps fflush(NULL)) which just checks f->rpos,
f->wpos, etc. Perhaps some comments should be added to this effect,
though.
Rich
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.
