Re: issetugid?

[Florian Weimer <fweimer at redhat dot com>]

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.

> 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).

--
Florian Weimer / Red Hat Product Security