The Most Dangerous Code in the Browser Stefan Heule, Devon Rifkin, - - PowerPoint PPT Presentation

▶
the most dangerous code in the browser
SMART_READER_LITE
LIVE PREVIEW

The Most Dangerous Code in the Browser Stefan Heule, Devon Rifkin, - - PowerPoint PPT Presentation

Jan 06, 2023 175 likes •592 views

The Most Dangerous Code in the Browser Stefan Heule, Devon Rifkin, Alejandro Russo, Deian Stefan Modern web experience Modern web experience Modern web experience Web apps Extensions AdBlock NYTimes Chase Evernote Core browser Web

slide-1
SLIDE 1

The Most Dangerous Code in the Browser

Stefan Heule, Devon Rifkin, Alejandro Russo, Deian Stefan
slide-2
SLIDE 2

Modern web experience

slide-3
SLIDE 3

Modern web experience

slide-4
SLIDE 4

Modern web experience

…

Core browser

Evernote AdBlock NYTimes Chase

Web apps Extensions

slide-5
SLIDE 5

Web app security

  • Trust model: malicious code
  • Apps are isolated according to same-origin policy
  • Apps are constrained to Web APIs (e.g., DOM)
➤ They cannot access arbitrary files, devices, etc.

Core browser

NYTimes Chase Web APIs

❌

slide-6
SLIDE 6

Extension security?

  • Extensions need direct access to app DOMs
➤ They modify app style, content, behavior, …
  • Extensions need privileged APIs
➤ To fetch/store cross-origin content, to read/modify

history and bookmarks, to create new tabs, etc.

NYTimes AdBlock

Core browser

Privileged APIs
slide-7
SLIDE 7
  • Trust model: extensions are benign-but-buggy
  • Privilege separate extension: core and content
➤ Protects vulnerable extension from malicious apps
  • Run extensions with least privilege
➤ Limits damage due to exploits

Chrome extension security model

NYTimes AdBlock
slide-8
SLIDE 8

Least privilege via permission system

  • Extensions declare necessary permissions





  • Users must grant permissions at install time
{ "name": “AdBlock Plus", "version": "2.1.10", ... "permissions": [ "http://*/*", "https://*/*", "contextMenus" ], ...
slide-9
SLIDE 9

What does mean?

  • Can read and modify data on any site,

regardless of what site you are visiting

  • AdBlock must be a special case, right?
➤ 71.6% of top 500 extensions need this privilege! NYTimes AdBlock chase.com
slide-10
SLIDE 10

What does mean?

  • Can read and modify data on any site,

regardless of what site you are visiting

  • AdBlock must be a special case, right?
➤ 71.6% of top 500 extensions need this privilege! NYTimes AdBlock chase.com
slide-11
SLIDE 11

It gets worse with popularity

10 100 1000 10000 100000 1000000 10000000 0.2 0.4 0.6 0.8 1 1.2 1 51 101 151 201 251 301 351 401 451 Top n extensions Number of users (few days later) Fraction that can read and change …
slide-12
SLIDE 12

It gets worse with popularity

10 100 1000 10000 100000 1000000 10000000 0.2 0.4 0.6 0.8 1 1.2 1 51 101 151 201 251 301 351 401 451 % of n that can read and change all your data… Top n extensions Number of users (few days later) Fraction that can read and change …
slide-13
SLIDE 13

It gets worse with popularity

10 100 1000 10000 100000 1000000 10000000 0.2 0.4 0.6 0.8 1 1.2 1 51 101 151 201 251 301 351 401 451 # of users % of n that can read and change all your data… Top n extensions Number of users (few days later) Fraction that can read and change …
slide-14
SLIDE 14

It gets worse with popularity

10 100 1000 10000 100000 1000000 10000000 0.2 0.4 0.6 0.8 1 1.2 1 51 101 151 201 251 301 351 401 451 # of users % of n that can read and change all your data… Top n extensions Number of users (few days later) Fraction that can read and change … Removed from Chrome Web Store
slide-15
SLIDE 15

Problem with Chrome’s model

  • Permission requests are meaningless
➤ Descriptions are broad and context-independent
  • Model encourages principle of most privilege
➤ Extensions don’t auto-update if they need more privs
  • Threat model is not realistic
➤ Chrome Web Store listed many malicious extensions ➤ Roughly 5% of Google users run malicious extensions
slide-16
SLIDE 16

Problem with Chrome’s model

  • Permission requests are meaningless
➤ Descriptions are broad and context-independent
  • Model encourages principle of most privilege
➤ Extensions don’t auto-update if they need more privs
  • Threat model is not realistic
➤ Chrome Web Store listed many malicious extensions ➤ Roughly 5% of Google users run malicious extensions
slide-17
SLIDE 17

Problem with Chrome’s model

  • Permission requests are meaningless
➤ Descriptions are broad and context-independent
  • Model encourages principle of most privilege
➤ Extensions don’t auto-update if they need more privs
  • Threat model is not realistic
➤ Chrome Web Store listed many malicious extensions ➤ Roughly 5% of Google users run malicious extensions
slide-18
SLIDE 18

New extension-system goals

  • Meaningful permission system
➤ Safe behavior should not require permission ➤ Permissions requests should be content-specific
  • Model should encourage least privilege
➤ Permissions should be fine-grained ➤ Incentivize safe extensions
  • Threat model: extensions may be malicious
➤ Need to also protect user app data from extensions
slide-19
SLIDE 19

New extension-system goals

  • Meaningful permission system
➤ Safe behavior should not require permission ➤ Permissions requests should be content-specific
  • Model should encourage least privilege
➤ Permissions should be fine-grained ➤ Incentivize safe extensions
  • Threat model: extensions may be malicious
➤ Need to also protect user app data from extensions
slide-20
SLIDE 20

New extension-system goals

  • Meaningful permission system
➤ Safe behavior should not require permission ➤ Permissions requests should be content-specific
  • Model should encourage least privilege
➤ Permissions should be fine-grained ➤ Incentivize safe extensions
  • Threat model: extensions may be malicious
➤ Need to also protect user app data from extensions
slide-21
SLIDE 21

How can we do this?

Insight: it is safe for extension to read user data if it can’t arbitrarily disseminate it

➤ E.g., Google Mail Checker



 
 


➤ Taint extensions according to what it reads ➤ Confine code to protect user’s privacy Checker gmail.com
slide-22
SLIDE 22

How can we do this?

Insight: it is safe for extension to read user data if it can’t arbitrarily disseminate it

➤ E.g., Google Mail Checker



 
 


➤ Taint extensions according to what it reads ➤ Confine code to protect user’s privacy

✗

Checker gmail.com
slide-23
SLIDE 23

How can we do this?

Insight: it is safe for extension to read user data if it can’t arbitrarily disseminate it

➤ E.g., Google Mail Checker



 
 


➤ Taint extensions according to what it reads ➤ Confine code to protect user’s privacy

✗

Checker gmail.com
slide-24
SLIDE 24

How can we do this?

Insight: it is safe for extension to read user data if it can’t arbitrarily disseminate it

➤ E.g., Google Mail Checker



 
 


➤ Taint extensions according to what it reads ➤ Confine code to protect user’s privacy

✗

Checker gmail.com
slide-25
SLIDE 25

How can we do this?

Insight: it is safe for extension to read user data if it can’t arbitrarily disseminate it

➤ E.g., Google Mail Checker



 
 


➤ Taint extensions according to what it reads ➤ Confine code to protect user’s privacy

✗

Checker gmail.com
slide-26
SLIDE 26

How can we do this?

Insight: it is safe for extension to read user data if it can’t arbitrarily disseminate it

➤ E.g., Google Mail Checker



 
 


➤ Taint extensions according to what it reads ➤ Confine code to protect user’s privacy

✗

Checker evil.gov

❌

gmail.com
slide-27
SLIDE 27

Safely read and modify pages?

slide-28
SLIDE 28

Safely read and modify pages?

✗

slide-29
SLIDE 29

Safely read and modify pages?

  • Idea: tie extension script with app page
➤ Impose at least same-origin policy on extension



 


  • Challenge: read data from page and leak it by

injecting content into page’s DOM

  • Solution: taint extension, write to isolated DOM
➤ Loads due to extension restricted: confined! NYTimes AdBlock chase.com

❌

slide-30
SLIDE 30

Safely read and modify pages?

  • Idea: tie extension script with app page
➤ Impose at least same-origin policy on extension



 


  • Challenge: read data from page and leak it by

injecting content into page’s DOM

  • Solution: taint extension, write to isolated DOM
➤ Loads due to extension restricted: confined! NYTimes AdBlock chase.com

❌

slide-31
SLIDE 31

Confinement: safe, too restricting

  • Challenge: extensions need to “leak” data
➤ E.g., Evernote is used to save URL, page, etc. ➤ Reading DOM taints extension:
  • Solution: declassification via sharing menu API
NYTimes Evernote evernote.com

❌

NYTimes
slide-32
SLIDE 32

Confinement: safe, too restricting

  • Challenge: extensions need to “leak” data
➤ E.g., Evernote is used to save URL, page, etc. ➤ Reading DOM taints extension:
  • Solution: declassification via sharing menu API
NYTimes Evernote evernote.com

❌

NYTimes
slide-33
SLIDE 33

Confinement: safe, too restricting

  • Challenge: extensions need to “leak” data
➤ E.g., Evernote is used to save URL, page, etc. ➤ Reading DOM taints extension:
  • Solution: declassification via sharing menu API
NYTimes Evernote evernote.com

❌

NYTimes
slide-34
SLIDE 34

Confinement: safe, too restricting

  • Challenge: extensions need to “leak” data
➤ E.g., Evernote is used to save URL, page, etc. ➤ Reading DOM taints extension:
  • Solution: declassification via sharing menu API
NYTimes Evernote evernote.com

❌

NYTimes
slide-35
SLIDE 35

Confinement: safe, too restricting

  • Challenge: extensions need to “leak” data
➤ E.g., Evernote is used to save URL, page, etc. ➤ Reading DOM taints extension:
  • Solution: declassification via sharing menu API
NYTimes Evernote evernote.com

❌

NYTimes Evernote
slide-36
SLIDE 36

Confinement: safe, too restricting

  • Challenge: extensions need to “leak” data
➤ E.g., Evernote is used to save URL, page, etc. ➤ Reading DOM taints extension:
  • Solution: declassification via sharing menu API
NYTimes Evernote evernote.com

❌

NYTimes Evernote evernote.com
slide-37
SLIDE 37

Usable confinement via APIs

  • Crypto API
➤ Convert tainted values to encrypted blobs (LastPass)
  • Declarative CSS API
➤ Taint-oblivious styling changes
  • Network filtering API
➤ Allow/deny network requests given regex (AdBlock)
  • …
slide-38
SLIDE 38

How can permissions be more meaningful?

  • Many extensions can 


be safe by default

➤ Confinement protects 


user privacy

➤ Incentivize developers by making warnings rare
  • To capture remaining models: need permissions
➤ Use declassification as guide for informing

messages: what data is being “leaked”?

  • E.g., URLS, page location, whole page, etc.
slide-39
SLIDE 39

How can permissions be more meaningful?

  • Many extensions can 


be safe by default

➤ Confinement protects 


user privacy

➤ Incentivize developers by making warnings rare
  • To capture remaining models: need permissions
➤ Use declassification as guide for informing

messages: what data is being “leaked”?

  • E.g., URLS, page location, whole page, etc.
slide-40
SLIDE 40

Summary

  • Extensions: most dangerous code in the browser
➤ Third-party, unaudited, highly-privileged JavaScript
  • Rethink extension security systems
➤ Need to protect user privacy from extensions ➤ Make user permissions requests rare and clear
  • One direction: confinement + new APIs
➤ Captures many extensions as “safe”

, makes permission requests rare