Control: reassign 835620 gnupg1 1.4.20-7
On Sat 2016-08-27 13:01:35 -0400, Valentin Lorentz wrote:
> Running gnupg from a process with setuid to a user different than root
> triggers a bug.
>
> Here is how to reproduce it:
>
> val@particle:/tmp $ cat foo.c
> #include <unistd.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> void main(int argc, char* argv[]) {
> printf("%u %u\n", getuid(), geteuid());
> system("gpg --help");
> }
> val@particle:/tmp $ sudo gcc foo.c && sudo chown dev-misc:dev-misc
> a.out && sudo chmod u+s a.out
> val@particle:/tmp $ LANG=C ./a.out
> 1000 1006
>
> gpg: Ohhhh jeeee: ... this is a bug (../../g10/gpg.c:2010:main)
> secmem usage: 0/0 bytes in 0/0 blocks of pool 0/65536
> Aborted
right, this code there looks like this:
0 dkg@alice:~/src/pkg-gnupg/gnupg1/g10$ cat -n gpg.c | head -n 2017 | tail
2008 maybe_setuid = 0;
2009 /* Okay, we are now working under our real uid */
2010
2011 #if defined(HAVE_GETUID) && defined(HAVE_GETEUID)
2012 /* There should be no way to get to this spot while still carrying
2013 setuid privs. Just in case, bomb out if we are. */
2014 if ( getuid () != geteuid () )
2015 BUG();
2016 #endif
2017
0 dkg@alice:~/src/pkg-gnupg/gnupg1/g10$
I believe upstream's goal is to have dropped all privileges here. But
for some reason that's not happening properly? Maybe someone from
upstream can comment on the logic here.
That said, i think that trying to run gpg from a setuid program is
probably not a great idea, in terms of opportunities for direct code
execution (as i mentioned over in #835629). Can you explain your use
case a little better?
Regards,
--dkg
signature.asc
Description: PGP signature
