Chromium Blog
News and developments from the open source browser project
A Tale Of Two Pwnies (Part 2)
2012. június 11., hétfő
When we
wrapped up
our recent Pwnium event, we praised the creativity of the submissions and resolved to provide write-ups on how the two exploits worked. We already covered
Pinkie Pie’s submission
in a recent post, and this post will summarize the other winning Pwnium submission: an amazing multi-step exploit from frequent Chromium Security Reward winner Sergey Glazunov.
From the start, one thing that impressed us about this exploit was that it involved no memory corruption at all. It was based on a so-called “Universal Cross-Site Scripting” (or UXSS) bug. The UXSS bug in question (
117226
) was complicated and actually involved two distinct bugs: a state corruption and an inappropriate firing of events. Individually there was a possible use-after-free condition, but the exploit -- perhaps because of various memory corruption mitigations present in Chromium -- took the route of combining the two bugs to form a “High” severity UXSS bug. However, a
Pwnium
prize requires demonstrating something “Critical”: a persistent attack against the local user’s account. A UXSS bug alone cannot achieve that.
So how was this UXSS bug abused more creatively? To understand Sergey’s exploit, it’s important to know that Chromium implements some of its built-in functions using special HTML pages (called WebUI), hosted at origins such as
chrome://about
. These pages have access to privileged JavaScript APIs. Of course, a normal web page or web renderer process cannot just iframe or open a
chrome:// URL
due to strict separation between
http[s]://
and
chrome://
URLs. However, Sergey discovered that iframing an invalid
chrome-extension:// resource
would internally host an error page in the
chrome://chromewebdata
origin (
117230
). Furthermore, this error page was one of the few internal pages that did not have a
Content Security Policy
(CSP) applied. A CSP would have blocked the UXSS bug in this context.
At this point, multiple distinct issues had been abused, to gain JavaScript execution in the
chrome://chromewebdata
origin.
The exploit still had a long way to go, though, as there are plenty of additional barriers:
chrome://chromewebdata
does not have any sensitive APIs associated with it.
chrome://a
is not same-origin with
chrome://b
.
chrome://*
origins only have privileges when the backing process is tagged as privileged by the browser process, and this tagging only happens as a result of a top-level navigation to a
chrome://
URL.
The sensitive
chrome://*
pages generally have CSPs applied that prevent the UXSS bug in question.
The exploit became extremely creative at this point. To get around the defenses, the compromised
chrome://chromewebdata
origin opened a window to
chrome://net-internals
, which had an iframe in its structure. Another WebKit bug -- the ability to replace a cross-origin iframe (
117583
) -- was used to run script that navigated the popped-up window, simply “back” to
chrome://net-internals
(
117417
). This caused the browser to reassess the
chrome://net-internals
URL as a top-level navigation -- granting limited WebUI permissions to the backing process as a side-effect (
117418
).
The exploit was still far from done. It was now running JavaScript inside an iframe inside a process with limited WebUI permissions. It then popped up an about:blank window and abused another bug (
118467
) -- this time in the JavaScript bindings -- to confuse the top-level
chrome://net-internals
page into believing that the new blank window was a direct child. The blank window could then navigate its new “parent” without losing privileges (
113496
). The first navigation was to
chrome://downloads
, which gained access to additional privileged APIs. You probably get a sense of where the exploit was headed now. It finished off by abusing privileged JavaScript APIs to download an attack DLL. The same APIs were used to cleverly “download” and run
wordpad.exe
from the local disk (thus avoiding the system-level prompt for executing downloads from the internet zone). A design quirk of the Windows operating system caused the attack DLL to be loaded into the trusted executable.
As you can imagine, it took us some time to dissect all of this. Distilling the details into a blog post was a further challenge; we’ve glossed over the use of the UXSS bug to bypass pop-up window restrictions. The UXSS bug was actually used three separate times in the exploit. We also omitted details of various other lockdowns we applied in response to the exploit chain.
What’s clear is that Sergey certainly earned his $60k Pwnium reward. He chained together a whopping 14[*] bugs, quirks and missed hardening opportunities. Looking beyond the monetary prize, Sergey has helped make Chromium significantly safer. Besides fixing the array of bugs, we’ve landed hardening measures that will make it much tougher to abuse
chrome://
WebUI pages in the future.
Posted by Ken Buchanan, Chris Evans, Charlie Reis and Tom Sepez, Software Engineers
[*]14, or thereabouts. It’s easy to lose count.
Címkék
$200K
1
10th birthday
4
abusive ads
1
abusive notifications
2
accessibility
3
ad blockers
1
ad blocking
2
advanced capabilities
1
android
2
anti abuse
1
anti-deception
1
background periodic sync
1
badging
1
benchmarks
1
beta
83
better ads standards
1
billing
1
birthday
4
blink
2
browser
2
browser interoperability
1
bundles
1
capabilities
6
capable web
1
cds
1
cds18
2
cds2018
1
chrome
35
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
Chrome dev
1
chrome dev summit
1
chrome dev summit 2018
1
chrome dev summit 2019
1
chrome developer
1
Chrome Developer Center
1
chrome developer summit
1
chrome devtools
1
Chrome extension
1
chrome extensions
3
Chrome Frame
1
Chrome lite
1
Chrome on Android
2
chrome on ios
1
Chrome on Mac
1
Chrome OS
1
chrome privacy
4
chrome releases
1
chrome security
10
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
9
cloud print
1
coalition
1
coalition for better ads
1
contact picker
1
content indexing
1
cookies
1
core web vitals
2
cumulative layout shift
1
custom tabs
1
csrf
1
css
1
dart
8
dashboard
1
Data Saver
3
Data saver desktop extension
1
day 2
1
deceptive installation
1
declarative net request api
1
design
2
developer dashboard
1
Developer Program Policy
2
developer website
1
devtools
13
digital event
1
discoverability
1
DNS-over-HTTPS
4
DoH
4
emoji
1
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
Follow
1
fonts
1
form controls
1
frameworks
1
fugu
2
fund
1
funding
1
gdd
1
google earth
1
google event
1
google io 2019
1
google web developer
1
googlechrome
12
harmful ads
1
html5
11
HTTP/3
1
HTTPS
4
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
issue tracker
3
jank
1
javascript
5
lab data
1
labelling
1
largest contentful paint
1
launch
1
lazy-loading
1
lighthouse
2
linux
2
Lite Mode
2
Lite pages
1
loading interventions
1
loading optimizations
1
lock icon
1
long-tail
1
mac
1
manifest v3
2
metrics
2
microsoft edge
1
mixed forms
1
mobile
2
na
1
native client
8
native file system
1
New Features
5
notifications
1
octane
1
open web
4
origin trials
2
pagespeed insights
1
pagespeedinsights
1
passwords
1
payment handler
1
payment request
1
payments
2
performance
20
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
4
private prefetch proxy
1
profile guided optimization
1
progressive web apps
2
Project Strobe
1
protection
1
pwa
1
QUIC
1
quieter permissions
1
releases
3
removals
1
rlz
1
root program
1
safe browsing
2
Secure DNS
2
security
36
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
4
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
23
TLS
1
tools
1
tracing
1
transparency
1
trusted web activities
1
twa
2
user agent string
1
user data policy
1
v8
6
video
2
wasm
1
web
1
web apps
1
web assembly
2
web developers
1
web intents
1
web packaging
1
web payments
1
web platform
1
web request api
1
web vitals
1
web.dev
1
web.dev live
1
webapi
1
webassembly
1
webaudio
3
webgl
7
webkit
5
WebM
1
webmaster
1
webp
5
webrtc
6
websockets
5
webtiming
1
writable-files
1
yerba beuna center for the arts
1
Archive
2024
dec.
aug.
jún.
máj.
ápr.
márc.
febr.
2023
nov.
okt.
szept.
aug.
jún.
máj.
ápr.
febr.
2022
dec.
szept.
aug.
jún.
máj.
ápr.
márc.
febr.
jan.
2021
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2020
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2019
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2018
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2017
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2016
dec.
nov.
okt.
szept.
aug.
jún.
máj.
ápr.
márc.
febr.
jan.
2015
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2014
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2013
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2012
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2011
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2010
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2009
dec.
nov.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2008
dec.
nov.
okt.
szept.
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
