Date: Sat, 12 Jul 2014 13:00:08 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Status towards next release (1.1.4) On Sat, Jul 12, 2014 at 06:29:44PM +0200, u-igbb@...ey.se wrote: > > Runtime configuration of the path is a big problem for many usage > > cases, possibly even if it's blocked for suid. The recent glibc > > CVE-2014-0475 has me concerned and wanting to avoid any dubious > > practices with how locales are searched out. This is potentially a > > I understand your concern about security but disallowing something at > the library level just to prevent a certain possible mode of failure of > a third party's flawed security model? This feels almost like designing > flats without windows [no pun] to prevent children from falling out. > > > much bigger issue than timezones, because for timezones, invalid data > > probably results in compromises no worse than a crash or information > > leak. With locales, invalid data can result in full code execution > > (via injection of %n into format strings, and possibly other ways). > > Allowing a user to set environment variables is giving her freedom to > control her applications iow a policy question. The low level library has > no proper knowledge to make policy decisions. > > Again, I feel you assume more responsibility for musl than is due. I partly agree with you here, and that's why I've raised a question on oss-security as to whether CVE-2014-0475 was even a valid vulnerability rather than just an ordinary non-security bug. However, format string vulnerabilities are also a sufficiently serious issue that extra precautions need to be taken to avoid introducing them in situations where it might be at all non-obvious that they could arise. This is why (see my other email in the thread spun off this one) I'm working on a design that avoids the format string issue entirely. I think we'll be able to work something out where locale path is configurable locally (per-process), or at least where absolute paths are allowed. Of course in suid processes both need to be forbidden; until we can be sure of what's safe, it might be necessary just to forbid all non-builtin locales for suid (libc.secure) programs. 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.