I WANT THESE * BUGSOFF MY * INTERNET

Dan KaminskyChief Scientist

White Ops

So, Defcon, Again

• Been coming here for ~15 years• No, really, I do talk about a lot more things than just DNS• Heh, thanks for coming despite a particular lack of details

• Why am I here?

I Like Hacking

• The primary thing hackers break are assumptions• We’re the people who manipulate how systems really work, not

(merely) how they’re supposed to work• That doesn’t always mean we know how they work, though that helps• Not knowing how things work tends to cause them to fail…we just redefined

failure as a success condition…

• There is an advantage to actually knowing how things work• We can fix things nobody else cares to• If we care to

I Like The Web

• HTML was the first complex document format that wasn’t accidentally fuzzable• Whatever you put into it, it was going to render something• No user ever wants a crash• Not like if you’re slightly off hammering a nail, it will turn into a fish…• Great learning curve!

• “Surfing the web”• Ever consider how weird a phrase that is? You don’t surf spider webs!• Just being able to go places and do things and not sit around waiting for installations was

so completely compelling – and still is

• Always up to date• Barely cached, generally updated, possible because the format is relatively small• Download one program (the browser), visit all the sites

That Is Not How Mobile Works

• Not to say Mobile is “bad”• It’s optimized for using a much smaller set of services• Must accept installation• Must wait for download• Must have on “Home Screen”• Mobile has a lot of friction

• Apps get stale – old binaries, too big to redownload on demand• Apps either require centralized permission (Apple) or probably should

require centralized permission (Android) :/• Binary powers are mighty

An Amazing Security Model (Really)

• The Browser represents a “Neutral Broker” that implements 2 ideas• 1) Same Origin Policy

• One user, one program, accessing both CNN and Gmail – CNN can’t read the user’s Gmail• Concept is that there are mutually distrusting entities that may be presenting information

to the user – in different tabs, or even in the same page – and they don’t get to “intersect” except within the user’s experience

• “Iframes” – you could embed a piece of Paypal, in your page, and Paypal couldn’t read your page and you couldn’t click “send all the money” inside the Paypal Frame• There have been other issues…

• 2) It’s Safe To Surf Anywhere• Corollary of the Same Origin Policy• The web requires users to download and execute unaudited code and execute it blindly• Users thus require the web to make sure anything executed is heavily constrained

• Been forced to drop arbitrary plugins (ActiveX, NPAPI), Java, possibly someday Flash to meet this constraint

The “Malvertising” Trap

• “Everybody should run ad blockers, because advertisements might contain dangerous content”• This is true. Not just exclusively.• Question: Do you think ad networks are more secure than your average

clickbait/listicle site?• Who makes more money?• Who can have a larger security budget?

• If it’s actually not safe to surf the web because of malvertising, really what we need is a whitelist of a few hopefully secured sites, with everywhere else deemed too dangerous• Is that still the web? No.

THAT BEING SAID

• “Everybody should run ad blockers, because advertisements are annoying and make the web slow”• Totally different story.• Disclosure: I started a company (White Ops) trying to clean up the ad space• Why are some ads causing performance problems?

The Same Origin Policy can be a problem• This is a surprising finding, even to me• Goal: Protect the user’s interests• We want mutually distrusting entities to be unable to harm one another• But what if a “child” entity is abusing the user, but SOP is preventing the

parent from noticing?• Concept: This shouldn’t be possible, since the parent can control how much of the

child is visible (even if it can’t see what the child is doing in that space)• Reality: The child could be doing a ton of things that are making the entire web

browser slow (or consuming piles of bandwidth)• You can’t manage what you can’t measure• Same Origin Policy means the parent SHOULD NOT be able to measure cross domain

iframes

Yeah, we’re hackers, this is a web page CPU monitor, and that’s an IETF SHOULD NOT

By comparison…

How it works

• nice.js (simplified)• setInterval(

function(){ var now = Date.now(); console.log(now-window.prev-250); window.prev=now; }, 250 )

• “Try to do something every 250ms. Then tell me how much we miss that mark.”• [0,1,1,0] == Idle• [20,30,20,20] == Somewhat busy

[1000,2000,1000,5000] == Oh dear• (Can also implement with setTimeout, requestAnimationFrame, and setImmediate,

yielding slightly different results)

How useful is nice.js?

• A slow web is a dead web• I like the web• Nice.js lets scripts easily delay their execution until the browser is idle

• Have a timing attack against subframes that yields some cross domain visibility• Easily shows that something somewhere on the page is causing poor user

experience (this benefits the user)• Has a small chance of showing that something somewhere on the page is

doing a particular thing on a child page, that the user would not want the parent page to know (this could harm the user)

Could nice.js be “fixed”?

• Difficult to fix• The stuff that’s being blocked here is fundamentally single threaded• Chrome is eventually making iframes run in their own processes, but

something competing on the same CPU ultimately causes visible delays (lots of timing attacks against shared-system crypto)

• Not necessarily desirable to fix• Slow processes, even in an iframe, still burn battery life, harm user experience

• Possible to let parents profile children (at least know “this frame is making the browser slow” at low frequency) yielding both more actionable data (this subresource needs to be cut) and safer data (“this frame caused this much jank” rather than 60hz updates)

Let’s step back for a second

• What did I just calculate?• “Given this hack, what should browser developers do?”

• Turns out, that’s a complicated question to answer, even if you constrain it to, “What’s best for the user?”• Measuring harms against one another (a theoretical risk of cross-domain inspection

vs. an active crisis of embedded content overwhelming the user experience)• How difficult is the fix? (Would we have to completely redesign the entire

browser?)• How useful would a proper implementation be? (Maybe we double down on the

functionality, and mitigate theoretical harms while we’re at it)

• “Making things better” requires judgment calls, that even extend outside of security.

Another thing SOP-Induced blindness has allowed…• 1) Buy ad space on a popular site• 2) ???• 3) Profit• Anyone here know what step two is?

Ad Stuffing Gnomes

• 1) Buy ad space on a popular site• 2) Put ten other ads inside/underneath your ad• Top Frame: Some site you’ve heard of• Mid Frame: Stuffer• Subframe 1-10: Stuff Stuff Stuff Stuff…

• 3) Profit• No limit to how much they can stuff, no limit to how much they can

degrade the user experience• “It’s invisible!”

So, Viewability

• Same Origin Policy means nobody can tell stuffing is happening• Ads can’t tell they’re invisible• Publisher can’t tell there’s invisible ads• Middleman makes out like a bandit

• We can sort of see this happening with nice.js (CPU impact)• There’s a body of hacks that try to see if the stuffed ads are actually

visible via the browser• They…sometimes work, and they’re sometimes efficient• Should this be a hack at all?

“Viewability” is just Clickjacking w/o the Click

• Attacks against viewability occur when just the loading of content is enough to cause harm

• But content is not just displayed to users – it’s also presented for interaction• Dialog on the left controls Camera and

Microphone in Flash (on IE/FF)• Click==Spy

• If the content is not fully viewable, the interaction cannot be trusted

• We call these Clickjacking attacks. We defend against them by making the web suck.

Off-site navigation is a terrible design(But Paypal can only guarantee no malice on eBay)

“In Context” on eBay – just hit PayHave to navigate offsite, hope the user comes back

Popups are terrible design.(But Twitter is afraid of clickjacked retweets)

Some bugs need to be judged by the crap they create in their wake• We tend to “fix” clickjacking by making it impossible to embed content

• X-Frame-Options disables/controls iframes

• But content embedding is actually one of the unique values of the web• Single Sign On could really use this working too

• People are using other approaches to compensate, and they’re awful• Nav to a safe domain• Popups• Script Includes – “Good” JS and “Bad” JS fighting without a security boundary between

them?!?! We abandoned SOP because of SOP?

• None of these options are available to Adobe, who really needs “in-context” security (for IE/FF when not in Chrome Sandbox)• But they get native code execution…

Adobe destroyed Clickjacking(For Camera and Microphone)(+ means can click, - means cannot click)

Works through Iframes just fine(Same filters, but on outer iframe vs plain inside)

Moving objects (that are, say, following the mouse) must stay in place for a few seconds in view of user for input to be accepted

they make photoshop they can tell by the pixels(Adobe is semi-fuzzily comparing expected vs. actual rendered output to the user)

So…

• I guess Flash can do what HTML5 can’t…again?• Uh, no• You never want to read pixels back from the GPU

• GPU == 10 lane freeway with 9 lanes going out and 1 lane coming in• You also never want to parse video• In this one context, when the security requirement is absolutely

overwhelming, and the use is precisely fixed to an inflexible and temporary dialog, pixel scraping’s perf impact is trumped

We Too Can Fix Things

• It’s not like we can’t patch browsers like Adobe can patch Flash• HTML5 has been working on fixing viewability/clickjacking, via W3C’s

UI Security Group• Good spec• Recommends pixel scraping as a generic implementation strategy• That can’t happen. Can something happen?

I’m becoming an W3C invited expert, because…

I WANT THESE * CLICKJACKING BUGSOFF MY * WEBAsk me how

Layers of Abstraction

• Browsers can’t efficiently know what pixels are being presented to the user (because the GPU is figuring all that out)• It’s not like the browser isn’t controlling what’s being sent to the GPU• Web pages are composed of layers – it’s like we’re looking down on a

stack of transparencies, with objects on top obscuring and altering whatever happens to be beneath

What you see

What your computer sees (Firefox 3D view)

Maybe your computer could see something else• Pixel Scraping is an attempt at auditing

• So many ways to draw pixels in HTML5 – HTML/JS/CSS/WebGL/SVG/Canvas• Let’s just see if the final pixels resemble the correct pixels

• IronFrame is an attempt at correctness by design• We just take the layer on the bottom, and we put it on the top

• It’s like Jenga• Hopefully without the falling over

• We make sure we don’t put too much on the top – iframes are like keyholes, we just respect those sizes and positions

• The only thing that could be rendered, is the thing that should be rendered

• First, just let me show you IronFrame working (under Chrome/Blink)….

Then let me explain why you never use the word “just” when it comes to browsers, or anything that might be hard.Browsersamirite

Here’s a tweet (inside a bunch of hidden iframes being nasty). If you click it, it fires a popup.

That tweet, with a stock browser, in various possibly unfriendly environments

Same Tweet, Under IronFrame (screen not recently scrolled). Red=Not 100% Visible

Now, we scroll the top window.Yellow==“My size or position changed recently”Red or Yellow == Interaction is blocked

The iframe follows the mouse? No problem!Yellow (and input blocking) in motionClear (and interactive) once settled in

Handling Changing States:Events, not Fixed Policies• That’s the other half of IronFrame• Instead of applying fixed policy, we send events to the promoted

frame• Where the viewport is• Where your content is on that viewport• How much of your content is on that viewport• When this was all true, whenever these values change• With this input, JS can decide policy (allow Paypal/Retweet/Like/Impression)

We have a God layerWhat if there are two Gods?• What if two layers both try to promote into the same space?• No problem, one of them wins, don’t care which. As long as the loser

(partial or complete) finds out it lost• “RequestVisibility” is my present API name. It’s not “DemandVisibility”• Might also allow frames to block RequestVisibility, at the cost that children

will know they’re being blocked• This does alter designs, I’ll be talking about that later

Just to show off a bit…Opacity tricks? No problem.

Drop shadows from a faraway Element?CSS filter blur? Done and done.

Complex clip paths? NopeZoom? Catch that too

RotateY(90deg?) Sure, nope.

Scale3D literally flipping it and reversing it and NOPE NOPE NOPE

Visibility Hidden?Visibility Restored.

Securitay by design is a thing

Not saying perfect. But all those were fixed without special cases.No popups necessary

Let’s talk gory details. Starting with what does it actually mean to “move a layer”.• We’re going to focus on Blink here, but as with nice.js, this stuff is

basically very similar across the browsers• Former head of IE: “This is the anti-hack – you’re working with the graphical

subsystem to build a security policy”• Yup

What do we have to do

• Satisfy three requirements• 1) Promote content to the top layer• 2) Shrink that content so it’s no bigger than it should be• 3) Report back how much you promoted

What do we have to work with…

• Node• Element• Document• DOMWindow• LocalDOMWindow• Page• ChromeClient• FrameTree• FrameView• LayoutView• LayoutFrame• LayoutTreeBuilder

• LayoutObject• LayoutPart• LayoutBlock• LayoutBox• LayoutBoxModelObject• DeprecatedPaintLayer• DeprecatedPaintLayerPainter• DeprecatedPaintLayerCompositor• GraphicsLayer• GraphicsLayerTreeBuilder• WebLayer• WebLayerClient

OK, we can simplify

• Three layers contain almost all of what we need• Document• LayoutTree of LayoutObjects• LayerTree of DeprecatedPaintLayers or GraphicsLayers

• Don’t see this as a final feature implementation• I’m working towards viability, not perfection

Document: Just the DOM

• It’s the Document Object Model, what did you expect?• You can of course access it from C+

+• Anything you change here, will be

visible to an attacker• Moving Elements here is not

recommended, especially not cross domain!

• But everything “convenient” for the JS dev, is available to you in C++ (and then some)

LayoutObject: A fast OM that still knows what sort of elements it containsinternals.elementLayoutTreeAsText(imgdoc.documentElement)• layer at (0,0) size 784x762• LayoutBlockFlow {HTML} at

(0,0) size 784x762• LayoutBlockFlow {BODY} at

(8,8) size 768x746• LayoutImage {IMG} at (0,0)

size 0x0

internals.elementLayoutTreeAsText(iframedoc.documentElement)• layer at (0,0) size 784x762• LayoutBlockFlow {HTML} at (0,0) size 784x762• LayoutBlockFlow {BODY} at (8,8) size 768x746

• layer at (8,8) size 304x154• LayoutIFrame {IFRAME} at (0,0) size

304x154 [border: (2px inset #EEEEEE)]

• layer at (0,0) size 300x150• LayoutView at (0,0) size 300x150• layer at (0,0) size 300x150• LayoutBlockFlow {HTML} at (0,0) size 300x150• LayoutBlockFlow {BODY} at (8,8) size 284x134

Anyone here pixel scrape for web regression tests? Because LayoutTree dumping is better.

DeprecatedPaintLayer / GraphicsLayer:An OM that only knows surfaces to paint/clip/scroll

internals.layerTreeAsText(document)• {• "bounds": [784, 762],• "children": [• {• "bounds": [784, 762],• "contentsOpaque": true,• "drawsContent": true• }• ]• }

Some notes• Many LayoutObjects can share

the same GraphicsLayer• An object in the DOM can be

configured to ultimately require a dedicated GraphicsLayer• document.documentElement.st

yle.transform = “translatez(0)”• Well known optimization that

sometimes does good things

Layer Tree After style.transform = “translatez(0)”

Looks like a lot…• Most of these surfaces don’t

have drawsContent set• They’re just surface modifiers,

handling scrolling and clipping

• There are more layers on the way to the GPU, that (I believe) turn these surfaces into draw commands instead of bitmaps

What I’ve found

• Everything in IronFrame could be implemented at Document, LayoutObject, or GraphicsLayer• For various degrees of security, difficulty, and stability• It’s sort of a fight between absorbing the browser’s existing knowledge of

corner cases and suffering the browser’s implicit assumptions

• Actually migrating content to a top layer works really well at GraphicsLayer• Figuring out what to migrate should use GraphicsLayer, but it’s tricky• For now, Document Elements have a method boundsInViewportSpace(), that

works quite well

IronFrame in English: Find Your DocumentElement• 1) Start with the documentElement inside an iframe’s Document

object• Why inside an iframe? Because otherwise you can have all the clever

graphical security you want and an attacker can just turn it off with a bit of clever JavaScript• Same Origin Policy does have its uses!

• Why the documentElement? Because there’s lots and lots of weird stuff in HTML and I want to limit the number of things that can go wrong• If the documentElement doesn’t already have its own layer, add translatez(0)

to it (or find the magic bit to flip)

IronFrame in English: Raise your GraphicsLayer• 2) Find the GraphicsLayers for both the content to be promoted, and

the root graphics layer• GraphicsLayer *iframeGraphicsLayer = document->documentElement()-

>layoutObject()->enclosingLayer()->graphicsLayerBacking();• GraphicsLayer* rootGraphicsLayer = this->domWindow()->top()->document()-

>body()->layoutObject()->enclosingLayer()->root()->graphicsLayerBacking();• Iframes create false roots – need to get the root relative specifically to the top document’s

enclosingLayer!

• 3) Make the iframeGraphicsLayer the last child of the rootGraphicsLayer (meaning it trumps)• rootGraphicsLayer->addChild(iframeGraphicsLayer)

IronFrame in English: Your GraphicsLayer is too big! Measure how bad it is.• 4) Figure out how big that documentElement is, and where it might be on the

top viewport• IntRect bounds = document->documentElement()->boundsInViewportSpace()• Say that’s a 1000x1000 rectangle at a position of (400,400)

• 5) Figure out how much your parent iframe(s) clip you• We have to implement clipping, because we’re escaping natural clipping so we can

escape all the other stuff things on top of us can do• Just because your content is 1000x1000 doesn’t mean that survives all the way up• IntRect frameBounds = document->domWindow()->frameElement()-

>boundsInViewportSpace() // could be a tiny 200x200 keyhole at 100x100• bounds.intersect(framebounds)• Repeat until there aren’t any more iframes that could clip you (keep running document-

>domWindow->parent() and checking for frameElement()

IronFrame in English: Don’t forget the Viewport! • 6) Figure how much the viewport clips you• Just because we’re somewhere on the top frame, doesn’t mean we’re

scrolled into view. Maybe we’re 4000 pixels down and the page isn’t looking at us!• LayoutRect viewport = this->page()->deprecatedLocalMainFrame()->view()-

>layoutView()->viewRect(); // Probably a better way to do this• Convert the LayoutRect to an IntRect and intersect bounds with this

IronFrame in English: Shrink your GraphicsLayer• 7) Apply Bounds

• boundsInViewportSpace() takes all scrolling into account except scrolling on the topWindow, so add that back

iframeGraphicsLayer->setPosition(FloatPoint(bounds.x()+topWindow->scrollX(), bounds.y()+topWindow->scrollY()));

iframeGraphicsLayer->setSize(FloatSize(bounds.size().width(), bounds.size().height()));

iframeGraphicsLayer->setMasksToBounds(true);

• 8) Correct for intermediate scrolling• It’s not just the top frame that can scroll – so can subframes. Handle that by measuring

how much the iframes changed x and y, and applying that to the layer.• IntSize offset = IntSize(bounds.x()-origBounds.x(),bounds.y()-origBounds.y());• iframeGraphicsLayer->setOffsetFromLayoutObject(offset,

GraphicsLayer::ShouldSetNeedsDisplay::SetNeedsDisplay);

IronFrame in English: Report back!

• 9) Report back the Viewport and Visible Portion• I happen to send this back over an onError, to be picked up as text in e-

>message• This also needs scrollX() and scrollY() added to the bounds

It’s so easy!

That’s why you never say “just”.I said just

You can’t spell just without js

Some Issues

• Need to actually get this into the compositing pipeline• Presently a JS call (requestVisibility) rather than an attribute or CSS property• Other things can cause a layout event to occur• Those things reset our manipulated tree• There’s a polling wrapper right now, making Tim Berners-Lee cry

• Need to actually be stable in the compositing pipeline• Blink wants certain things to happen at certain times• Makes it interesting to schedule those things to occur

• “Do this soon”• Enums that literally refer to solving chicken and egg problems

• Right now, we just abort if either the source iframe or the destination top frame isn’t completely outside of compositing (lifecycle state 14)

• Some mouse issues (hit testing gets weird)

Biggest Issue: Do we really want to be forcing things to be drawn on top?• Fail Closed• Whatever we report, that’s actually what is being presented to the user

• Alternative is Fail Open• We try to read the tea leaves across the various layers, and report our best

guess• As you can imagine I’m not a fan of that approach• The browser guys think they can do this (Minimum Unmodified Rectangle, as

Mozilla called it). I just want a security boundary that requires fixing.

• My original thinking was that position and size was good enough, and there’s no legitimate reason for other people to be drawing on top of your frame

Well, drop shadows are a thing(thanks, Jesse Ruderman)

Could I just promote the part of the layer I think that’s on top?

• Even if I deeply analyze GraphicsLayer to separate the area with the Drop Shadow overhang vs the area that’s clean, I can’t promote just the clean area• Layers can’t be “split” AFAIK• Would probably use HitTest on layers

• Blink does have ReplicaLayers – might be able to “clone” just the part I want• Painting twice is OK, it’s using that 10

lane freeway on outbound instead of inbound

• Probably need compositor support

One more thing

• Thus far, somebody can still draw a fake Twitter• They’re just pixels• Who cares, their fake doesn’t have your credentials

• But what if we wanted to use IronFrame for Single Sign On• This is the dialog that gets your credentials…

A New Freedom

• Iframes have always had input exclusivity• Keyboard and mouse to a frame, only goes to that frame

• Iframes are now getting output exclusivity• However much they’re visible, they know they’re visible

• Well, if we have input, and we have output…

We can update the address bar when the user is interacting with a secured frame.(That’s not photoshopped.)

So

• We can kill clickjacking without breaking what makes the web special• We can do crazy things as hackers – it’s not just about making things

fail. We can defend the vision of the open web.• We can realize when we try these hard things, it’s not going to work

perfectly the first or second or tenth time, and we’re going to be OK with that• We can tell the ad stuffers that are making the web slow, to go stuff

themselves

Couple final tips (if there’s time)

• 1) Even (especially) if you’re a White Hat, you don’t need to play all secretive when fixing longstanding public bugs• Just join the forums• Everybody knows clickjacking exists• Parisa Tabriz told me to do this and it would have saved me so much time

• 2) Use decent tools• You want to be able to quickly jump around a codebase – I use Source Insight

which is not free, but you know, neither is IDA Pro• Source Insight designed to search codebases it doesn’t know how to build• Getting Chrome to compile is hard enough, getting it to compile in Eclipse is…

• Apparently the only good way to debug Chrome is WinDBG, “the only reasonable multithreaded debugger on the planet”

Look for the debugging tools

• You’re not the only one who’s tried to change something here• Internals.cpp is as close as you’ll find to “stuff other people wrote to

make this work”• Compile content_shell and use --enable-internals-for-testing• Hundreds of useful methods to both execute (from JS) and copy for your own

uses• nodesFromRect, boundsInViewportSpace, layerTreeAsText, elementLayoutTreeAsText,

viewportAsText, absoluteCaratBounds, treeScopeRootNode…• Those aren’t methods for people building web pages, those are methods for

people fixing web browsers•