Issue metadata
Sign in to add a comment
|
CVE-2017-5123: Chrome Sandbox escape through linux kernel vulnerability introduced in 4.13 in waitid
Reported by
chrissal...@gmail.com,
Oct 9 2017
|
|||||||||||||||||||||||
Issue descriptionA linux kernel vulnerability introduced in 4.13 can be used to escape the chrome sandbox. 4.13 is a stable release and is included in Ubuntu 17.10 which is set to be released on October 19th. Vulnerability Details: In the linux kernel, inside the waitid syscall, unsafe_put_user is used to copy the results to usermode. However, access_ok is not checked on the pointer, allowing a kernel address to be given, and overwrite arbitrary kernel memory. https://github.com/torvalds/linux/blob/master/kernel/exit.c#L1614 Exploit: It is quite easy to exploit the bug without SMAP. Simply write over the upper bytes of a structure pointer, such as the cgroup structures to point it at userland and control function pointers. Then rop to gain privileges and escape the sandbox. I've included 2 different exploits. One is reliable and does not bypass SMAP. One is very unreliable, but includes a working SMAP bypass. As it is a sandbox bypass and not a full RCE exploit they need to start with code execution inside the sandbox. To test these proof of concepts, I modified the v8 code to compile in my sandbox escape and trigger it with javascript from the renderer. These exploits are tested and working on ubuntu-17.10-beta2. This is the right version: md5sum ubuntu-17.10-beta2-desktop-amd64.iso is e47df00b078b5f9daed0871f0e90d33f http://releases.ubuntu.com/17.10/ubuntu-17.10-beta2-desktop-amd64.iso I've also included 2 standalone pocs which exploit the bug with and without SMAP by emulating the chrome sandbox. The files include notes describing the exploit at the top. Files included: exploit_no_smap.c - reliable exploit from chrome assuming no smap exploit_smap_bypass.c - unreliable exploit from chrome, bypassing smap standalone_poc_no_smap.c - reliable standalone poc, which emulates the chrome sandbox and does not bypass smap standalone_poc_smap_bypass.c - unreliable standalone poc, which emulates the chrome sandbox and bypasses smap chrome_seccomp_filter - seccomp filter installed in standalone proof of concepts
,
Oct 9 2017
Thanks for the report. Has this been reported upstream? groeck, could you please take a look to see if this affects ChromeOS?
,
Oct 9 2017
It doesn't immediately affect ChromeOS since we don't ship anything above chromeos-4.4 at this time. Our latest development version is chromeos-4.12 which is not affected either. It _will_ affect chromeos-4.14 unless fixed. However, unless I am really missing something, the bug is absolutely valid, critical, and does affect v4.13 and later kernels. I set severity and impact fields accordingly. Kees, are you aware of this problem ? Do you know if it is already being worked on, and if there is a CVE ? [ I assigned the bug to myself, primarily for tracking. Strictly speaking this would be a WontFix, since it doesn't apply to existing ChromeOS versions, but it is too critical to ignore. ]
,
Oct 9 2017
This is the first I've seen the issue. Introduced upstream in commit 4c48abe91be03d191d0c20cc755877da2cb35622. Assigned as CVE-2017-5123.
,
Oct 9 2017
,
Oct 9 2017
Thanks for investigating. Removing Security-Impact-None since users using Linux would be impacted too. Severity-High for sandbox escape, since Critical is reserved for full chain exploits. I think ExternalDependency is the right status here since there's nothing actionable for us right now.
,
Oct 9 2017
,
Oct 10 2017
,
Oct 10 2017
Thanks for the quick response. Has this been reported upstream or to someone who will fix it? Or is that something I need to do?
,
Oct 10 2017
Fix should be straightforward and a two-liner. I'll be happy to do it unless someone else wants to pick it up. Kees - is it ok to submit a patch upstream ? If so, anything to watch out for ?
,
Oct 10 2017
... and if I submit a patch, can/should I add the submitter of this bug as Reported-by: ?
,
Oct 10 2017
Of course I'd like to be acknowledged in the "reported by" field if possible :)
,
Oct 10 2017
I've reported this upstream (with credit to Chris), it should be publish on the 12th. (Technically a 4 line change, since it's needed in two places, but yes.) :)
,
Oct 10 2017
#13: I assume that means that someone else (Al Viro ?) will submit a patch ?
,
Oct 10 2017
I submitted the patch already, but tried to open discussion about just doing a revert. I think they're going to just go with the patch instead.
,
Oct 10 2017
Great, thanks!
,
Oct 17 2017
Fixed upstream with commit 96ca579a1ecc ("waitid(): Add missing access_ok() checks"). Fixed in v4.13.7 with commit sha 3da54587cf4c. Marking as WontFix (not applicable to any chromeos kernels, and fixed in all affected upstream kernels).
,
Oct 17 2017
Doesn't this qualify for the Vulnerability Rewards Program?
,
Oct 17 2017
,
Oct 18 2017
,
Oct 26 2017
*** Boilerplate reminders! *** Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing. *********************************
,
Oct 26 2017
Congratulations chrissalls5@! The VRP panel decided to award $15,000 for this bug! A member of our finance team will be in touch to arrange for payment.
,
Oct 26 2017
,
Oct 26 2017
Wow. Thank you very much!!
,
Jan 24 2018
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 |
||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Oct 9 2017