[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Jul 2014 00:31:20 -0400
From: Rich Felker <dalias@...c.org>
To: Isaac Dunham <ibid.ag@...il.com>
Cc: Brent Cook <bcook@...nbsd.org>, musl@...ts.openwall.com,
beck@...nbsd.org, Brent Cook <brent@...ndary.com>
Subject: Re: [PATCH] implement issetugid(2)
On Mon, Jul 14, 2014 at 07:40:31PM -0700, Isaac Dunham wrote:
> On Sat, Jul 12, 2014 at 05:54:51PM -0600, Brent Cook wrote:
> > From: Brent Cook <brent@...ndary.com>
> >
> > From OpenBSD 2.0 and later, NetBSD, FreeBSD, OS X and Solaris
> > http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2
> <snip>
> > The fix is to implement the BSD issetugid(2) interface so that a
> > portable library can use its presence to determine if the underlying C
> > library has a reliable way of determining the value of AT_SECURE, and by
> > extension if the library is running with elevated privileges. If the
> > call fails, it assumes secure mode rather than falling back to an
> > insecure result.
>
> My previous response to your last email didn't get sent to you, for which
> I apologize. But to summarize:
> -auxval is initialized at ELF load time, so a setuid/setgid binary will
> always show up if privileges were gained.
> -AT_SECURE was added before filesystem capabilities (prior to kernel 2.6.0,
> I believe), so any system where checking AT_SECURE fails and auxval is properly
> initialized cannot obtain privileges except by setuid/setgid*
> -If auxval is not properly initialized (I'm not aware of any such cases),
> it cannot be detected if getauxval() is broken, but looking up AT_E?[UG]ID
> will also fail.
>
> In other words, for the fallback used to set libc.secure to "fail open",
> you would have to have a 2.4 kernel, the 2.6.x filesystem code
> (including filesystem capabilities), AND no backport of AT_SECURE.
In that case you're already screwed since you can LD_PRELOAD anything
you want. (And even for static linking, there are some issues like
processing of arbitrary zoneinfo and soon arbitrary locale files.) So
there's no point in worrying about whether issetugid() has false
negatives on such a broken system.
> [*] Unless we start talking about rootkits; I suspect detecting rootkits
> to avoid privilege escalation attacks on the rootkit via environmental
> variables doesn't make that much sense. ;)
Agreed.
> See below for further comments.
>
> > ---
> > include/unistd.h | 3 +++
> > src/unistd/issetugid.c | 10 ++++++++++
> > 2 files changed, 13 insertions(+)
> > create mode 100644 src/unistd/issetugid.c
> >
> > diff --git a/include/unistd.h b/include/unistd.h
> > index bb19cd8..3990c1e 100644
> > --- a/include/unistd.h
> > +++ b/include/unistd.h
> > @@ -109,6 +109,9 @@ uid_t geteuid(void);
> > gid_t getgid(void);
> > gid_t getegid(void);
> > int getgroups(int, gid_t []);
> > +#if defined(_BSD_SOURCE)
> > +int issetugid(void);
> > +#endif
> > int setuid(uid_t);
> > int setreuid(uid_t, uid_t);
> > int seteuid(uid_t);
>
> As a point of style, #ifdef sections stand in separate blocks, after all the
> non-ifdef stuff.
Yes, and it's preferable not to add new ones when such a block already exists.
> > diff --git a/src/unistd/issetugid.c b/src/unistd/issetugid.c
> > new file mode 100644
> > index 0000000..f538626
> > --- /dev/null
> > +++ b/src/unistd/issetugid.c
> > @@ -0,0 +1,10 @@
> > +#include <sys/auxv.h>
> > +#include "libc.h"
> > +
> > +int issetugid(void)
> > +{
> > + size_t *auxv = libc.auxv;
> > + for (; *auxv; auxv+=2)
> > + if (*auxv==AT_SECURE) return auxv[1] != 0;
> > + return 1;
> > +}
>
> This can be "return libc.secure;" unless you're concerned about the possibility
> that someone backported filesystem capabilities to a 2.4.x kernel without
> bothering to add AT_SECURE to auxval.
And it should be. We don't want false positives for issetugid on 2.4
kernels. libc.secure already has to be correct or it's game over at a
much earlier/deeper level.
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.
