oss-sec mailing list archives
Re: Re: hwclock(8) SUID privilege escalation
From: up201407890 () alunos dcc fc up pt
Date: Tue, 26 May 2015 17:30:40 +0200
2015-05-26 14:59:46 +0100, stephane.chazelas () il com:
2015-05-26 12:47:47 +0200, up201407890 () nos dcc fc up pt: [...]Please note that this is possible on Debian-derived (and therefore Ubuntu), because /bin/sh is provided by dash which does NOT make use of privmode (does not drop privileges if ruid != euid, unlike bash), which is a very stupid idea. privmode is surprisingly effective at mitigating some common vulnerability classes and misconfigurations, and it has been around since mid 90's. Indeed, Chet Ramey (bash author and maintainer) explains that the purpose of this is to prevent "bogus system(3)/popen(3) calls in setuid executables"[...] No, bash does NOT drop privileges if ruid != euid when called as sh either . If it were, it would break those commands that use system()/popen() from suid/sgid executables (which arguably they shouldn't be doing) and expect the euid/egid to be preserved.
$ ls -ln env sh -rwsr-x--- 1 0 1000 27232 Nov 27 12:00 env* lrwxrwxrwx 1 1000 1000 9 May 26 14:51 sh -> /bin/bash* $ ./env bash -c 'id -u' 1000 $ ./env ./sh -c 'id -u' It does however a mode in which the environment is not trusted as much (for instance exported functions, PS4... are ignored). PATH is still trusted and it's the responsibility of the caller to sanitise it. That's what the "privmode" is: when bash is priviledged, it's more careful. That's not specific to bash, that's in most shells. The difference with bash is that when not called as sh, you have to call bash with -p for that priviledged mode to be enabled (otherwise, bash drops privileges (and the privileged mode is not enabled since you're no longer privileged)).
I'm talking about this: # gcc -xc - -otest <<< 'main(int argc, char *argv[]){system(argv[1]);}' # chmod +s test # exit $ ls -l ./test /bin/sh lrwxrwxrwx. 1 root root 9 May 24 11:58 /bin/sh -> /bin/bash -rwsrwsr-x. 1 root root 8497 May 26 15:36 test $ ./test /bin/sh $ whoami saken $ su Password: # ln -sf /bin/dash /bin/sh # exit $ ./test /bin/sh # whoami root
No, bash does NOT drop privileges if ruid != euid when called as sh either . If it were, it would break those commands that use system()/popen() from suid/sgid executables (which arguably they shouldn't be doing) and expect the euid/egid to be preserved.
I believe that's what setuid()/seteuid()/setreuid() are for if you really want to execute stuff as another user.
Setting setuid(0) before the system() call on my test and executing /bin/sh (which is linked to bash) would drop me into a root shell. This doesn't happen if there is no setuid(0) call. The same doesn't happen when /bin/sh is linked to dash, there is no need for setuid(0), it will drop me instantly into a root shell.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Current thread:
- hwclock(8) SUID privilege escalation up201407890 (May 26)
- Re: hwclock(8) SUID privilege escalation Larry W. Cashdollar (May 26)
- Re: hwclock(8) SUID privilege escalation Stephane Chazelas (May 26)
- Re: Re: hwclock(8) SUID privilege escalation Tavis Ormandy (May 26)
- <Possible follow-ups>
- Re: Re: hwclock(8) SUID privilege escalation up201407890 (May 26)
- Re: Re: hwclock(8) SUID privilege escalation Stephane Chazelas (May 26)