From ac07daf66c83e9fc369f506208fe3e26f3f2ebad Mon Sep 17 00:00:00 2001 From: Offensive Security Date: Thu, 1 Feb 2018 05:01:48 +0000 Subject: [PATCH] DB: 2018-02-01 1 changes to exploits/shellcodes systemd (systemd-tmpfiles) < 236 - 'fs.protected_hardlinks=0' Local Privilege Escalation --- exploits/linux/local/43935.txt | 95 ++++++++++++++++++++++++++++++++++ files_exploits.csv | 1 + 2 files changed, 96 insertions(+) create mode 100644 exploits/linux/local/43935.txt diff --git a/exploits/linux/local/43935.txt b/exploits/linux/local/43935.txt new file mode 100644 index 000000000..213a24ec2 --- /dev/null +++ b/exploits/linux/local/43935.txt @@ -0,0 +1,95 @@ +Product: systemd (systemd-tmpfiles) +Versions-affected: 236 and earlier +Author: Michael Orlitzky +Fixed-in: commit 5579f85 , version 237 +Bug-report: https://github.com/systemd/systemd/issues/7736 +Acknowledgments: Lennart Poettering who, instead of calling me an idiot + for not realizing that systemd enables fs.protected_hardlinks by + default, went out of his way to harden the non-default configuration. + + +== Summary == + +Before version 237, the systemd-tmpfiles program will change the +permissions and ownership of hard links. If the administrator disables +the fs.protected_hardlinks sysctl, then an attacker can create hard +links to sensitive files and subvert systemd-tmpfiles, particularly +with "Z" type entries. + +Systemd as PID 1 with the default fs.protected_hardlinks=1 is safe. + + +== Details == + +When running as PID 1, systemd enables the fs.protected_hardlinks +sysctl by default; that prevents an attacker from creating hard links +to files that he can't write to. If, however, the administrator should +decide to disable that sysctl, then hard links may be created to any +file (on the same filesystem). + +Before version 237, the systemd-tmpfiles program will voluntarily +change the permissions and ownership of a hard link, and that is +exploitable in a few scenarios. The most problematic and easiest to +exploit is the "Z" type tmpfiles.d entry, which changes ownership and +permissions recursively. For an example, consider the following +tmpfiles.d entries, + + d /var/lib/systemd-exploit-recursive 0755 mjo mjo + Z /var/lib/systemd-exploit-recursive 0755 mjo mjo + +Whenever systemd-tmpfiles is run, those entries make mjo the owner of +everything under and including /var/lib/systemd-exploit-recursive. After +the first run, mjo can create a hard link inside that directory pointing +to /etc/passwd. The next run (after a reboot, for example) changes the +ownership of /etc/passwd. + +A proof-of-concept can be run from the systemd source tree, using +either two separate terminals or sudo: + + root # sysctl -w fs.protected_hardlinks=0 + root # sysctl -w kernel.grsecurity.linking_restrictions=0 + root # ./build/systemd-tmpfiles --create + mjo $ ln /etc/passwd /var/lib/systemd-exploit-recursive/x + root # ./build/systemd-tmpfiles --create + mjo $ /bin/ls -l /etc/passwd + -rwxr-xr-x 2 mjo mjo 1504 Dec 20 14:27 /etc/passwd + +More elaborate exploits are possible, and not only the "Z" type is +vulnerable. + + +== Resolution == + +The recursive change of ownership/permissions does not seem to be safely +doable without fs.protected_hardlinks enabled. + +In version 237 and later, systemd-tmpfiles calls fstatat() immediately +after obtaining a file descriptor from open(): + + fd = open(path, O_NOFOLLOW|O_CLOEXEC|O_PATH); + if (fd < 0) { + ... + } + if (fstatat(fd, "", &st, AT_EMPTY_PATH) < 0) + +The st->st_nlink field is then checked to determine whether or not fd +describes a hard link. If it does, the ownership/permissions are not +changed, and an error is displayed: + + if (hardlink_vulnerable(&st)) { + log_error("Refusing to set permissions on hardlink...", path); + return -EPERM; + } + +There is still a tiny window between open() and fstatat() where the +attacker can fool this countermeasure by removing an existing hard +link to, say, /etc/passwd. In that case, st->st_nlink will be 1, but +fd still references /etc/passwd. The attack succeeds, but is much +harder to do, and the window is as narrow as possible. More to the +point, it seems unavoidable when implementing the tmpfiles.d +specification. + + +== Mitigation == + +Leave the fs.protected_hardlinks sysctl enabled. \ No newline at end of file diff --git a/files_exploits.csv b/files_exploits.csv index 24f49be83..4d9eebde0 100644 --- a/files_exploits.csv +++ b/files_exploits.csv @@ -9304,6 +9304,7 @@ id,file,description,date,author,type,platform,port 43925,exploits/macos/local/43925.rb,"Arq 5.10 - Local Privilege Escalation (1)",2018-01-29,"Mark Wadham",local,macos, 43926,exploits/macos/local/43926.sh,"Arq 5.10 - Local Privilege Escalation (2)",2018-01-29,"Mark Wadham",local,macos, 43929,exploits/windows/local/43929.c,"System Shield 5.0.0.136 - Privilege Escalation",2018-01-30,"Parvez Anwar",local,windows, +43935,exploits/linux/local/43935.txt,"systemd (systemd-tmpfiles) < 236 - 'fs.protected_hardlinks=0' Local Privilege Escalation",2018-01-29,"Michael Orlitzky",local,linux, 41675,exploits/android/local/41675.rb,"Google Android 4.2 Browser and WebView - 'addJavascriptInterface' Code Execution (Metasploit)",2012-12-21,Metasploit,local,android, 41683,exploits/multiple/local/41683.rb,"Mozilla Firefox < 17.0.1 - Flash Privileged Code Injection (Metasploit)",2013-01-08,Metasploit,local,multiple, 41700,exploits/windows/local/41700.rb,"Sun Java Web Start Plugin - Command Line Argument Injection (Metasploit)",2010-04-09,Metasploit,local,windows,