Date: Thu, 17 Jul 2014 11:53:18 -0400 From: Rich Felker <dalias@...c.org> To: libc-alpha@...rceware.org Cc: musl@...ts.openwall.com Subject: Re: issetugid? On Thu, Jul 17, 2014 at 09:50:42AM +0200, Florian Weimer wrote: > On 07/16/2014 07:53 PM, Rich Felker wrote: > >This is a very good point. The LibreSSL folks are claiming that > >getauxval(AT_SECURE) is not safe due to the lack of any way to detect > >bug #15846 at runtime (and trying to use a strverscmp against the > >glibc version string as a way to know if the bug is present...). > >However, I think they're wrong because AT_SECURE is always included in > >the aux vector for all kernels glibc supports; ENOENT cannot happen. > > Yes, this is a bit like complaining that getpid has no error return value. Yes and no. If the code is only going to be used with glibc, then it's reasonable to assume that it does not return an error for AT_SECURE. On the other hand if it's only assuming a more abstract getauxval API, perhaps it's reasonable to consider failure. For example if running on a 2.4 kernel with musl, getauxval(AT_SECURE) would return 0 (and set errno). Having realized this, it's making me think we should probably provide a fallback value in this case since applications written to the glibc getauxval API may be assuming it does not fail for AT_SECURE. > >And if there were a way to suppress AT_SECURE, it would affect > >LD_PRELOAD etc. anyway and thus already be a vulnerability independent > >of getauxval's reporting of errors. > > > >I don't think prctl(PR_GET_DUMPABLE) is relevant or useful for this > >since it would have to be tested at startup before any application > >code runs in order to reflect the AT_SECURE status. > > See below; this is related to the issetugid differences. > > >>What's worse, the Solaris and FreeBSD versions of issetugid are > >>different, so we'd have to pick one behavior and be incompatible > >>with the other. > > > >Could you explain how they differ? I'm reading the Solaris > >documentation here: > > > >http://docs.oracle.com/cd/E23823_01/html/816-5167/issetugid-2.html > > > >and it appears to match the semantics that were proposed for addition > >to musl. > > FreeBSD's issetugid returns true if the process has altered any of > the UIDs/GIDs after it has been created ("if it has changed any of > its real, effective or saved user or group ID's since it began > execution"). In contrast, the Solaris manpage is unaffected by ID > changes ("The result of a call to issetugid() is unaffected by calls > to setuid(), setgid(), or other such calls."). > > So FreeBSD issetugid is like prctl(PR_GET_DUMPABLE), and Solaris > issetugid is like getauxval(AT_SECURE). Indeed, it seems the FreeBSD version is really weird, at least according to the manual: http://www.freebsd.org/cgi/man.cgi?query=issetugid&sektion=2 However they document that it first appeared in OpenBSD, which has the correct semantics like Solaris and the proposed addition to musl, according to the OpenBSD man page: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/issetugid.2 which includes the text: "The status of issetugid() is only affected by execve()." So I have no idea why FreeBSD botched the semantics when copying it. In any case, as far as I can tell, using the FreeBSD version while expecting the original OpenBSD semantics should only result in false positives (being overly safe but under-featured due to disallowing options from the environment) and never false negatives (failing to identify that the environment needs to be handled securely). On the other hand it _might_ be a problem to use the OpenBSD version when expecting the FreeBSD version, but the circumstances under which it makes a difference are not common. And since all systems which have this interface, except for FreeBSD, seem to implement it with the OpenBSD semantics, a cross-platform program assuming FreeBSD semantics would be rather broken anyway, no? 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.