Fine-grained policy enforcement for untrusted software
19
FINE-GRAINED POLICY ENFORCEMENT FOR UNTRUSTED SOFTWARE Phu H. Phung University of Gothenburg, Sweden, and University of Illinois at Chicago, USA IEEE Senior member June 13 2014 The Chicago Marriott O’Hare, Chicago, IL USA 2014 IEEE Technology Management Conference
description
Panel discussion on ``Balancing Security and Usability'' at the IEEE ITMC'2014, June 13, 2014, Chicago, USA.
Transcript of Fine-grained policy enforcement for untrusted software
FINE-GRAINED POLICY ENFORCEMENT FOR UNTRUSTED SOFTWAREPhu H. Phung
University of Gothenburg, Sweden, and
University of Illinois at Chicago, USA
IEEE Senior member
June 13 2014 The Chicago Marriott O’Hare, Chicago, IL USA
2014 IEEE Technology Management Conference
Untrusted software• Freeware downloaded over Internet
• Computer• Smartphone• Vehicle
• Third-party JavaScript in the Web
2
Untrusted software might not run at system level but run on a container, e.g. web browser, virtual machine
92% of all websites use JavaScript[w3techs.com]
“88.45% of the Alexa top 10,000 web sites included at least one remote
JavaScript library” CCS’12
Conventional security mechanisms• Firewall• Cryptography • Access control• System calls/
privileged mode
Treat programs as black box,cannot address vuneralbilities inside a program
Attack examples on smartphones
4
5
A real attack example in vehicle system
http://www.wired.com/threatlevel/2010/03/hacker-bricks-cars/
6
Samy attack on Myspace• MySpace tries to filter out JavaScript code in user data
• BUT: The malicious code was injected in a “strange” way that escapes the filter<div id=mycode style="BACKGROUND: url('java
script:eval(document.all.mycode.expr)')" expr="var B=String.fromCharCode(34);………">
</div>
Another attack
• Million Browser Botnet
(July 2013)• Leverage Advertising
Networks using JavaScript to launch Application-Level DDoS
• Paid on 2 ad networks for displaying treacherous advertisements on pages visited by hundreds of thousands of people
(Malicious code run automatically without user knowledge)
Jeremiah Grossman & Matt JohansenWhiteHat SECURITY
7
Usability vs. Security
• Modern software tends to be open and extensible• Needs for fine-grained security enforcement,
• i.e. not only allow or disallow an action, but enforce application-specific security policies
• Needs for runtime monitoring• Control bad behaviors
9
Motivations for fined-grained policy enforcement at runtime• Third-party service needs to
use sensitive resources, e.g. GPS location,SMS sending to function
• Potential security risks: e.g. leaking GPS info, send too many SMS messages causing high costNeed for fined-grained security policy enforcement at runtime
Policy: allow SMS sending but restricted to a specific recipient address, limit on the number of messages sent per
day, depending on the vehicle's location
Language-based security
• Looking inside a program to enforce security• Before execution
• analyze the code to ensure it is safe• rewrite the code to avoid potential harm
• During execution• monitor security-relevant events and stop the event violating security
• audit the code and take policing action if it did harm
Inlin
ed R
eference M
on
itors
Inlined Reference Monitors
• A language-based approach, combining of• Rewriting • Monitoring• Auditing
Overview of our contributions
The Lightweight Enforcement
Approach
Vehicle Application
Domain
Web application security at browsers
The lightweight enforcement approach to the vehicle domain
Third-party vehicle application
(in Java source or bytecode)
Security policies
(in AspectJ)
Rewriting tool
(AspectJ weaver)
. . . .
The modified (secured) application
with embedded policies
Embedded security policies will prevent bad behaviours
at runtime
The deployment model
In-vehicle system Control center Third party
Request a third-party appRequest the app
the app
Install and run the app
Normal processTransforming process
Modify the app to embed security policies
Install and run the app
This process is the standard in the GST project for the future vehicle system
Overview of our contributions
The Lightweight Enforcement
Approach
Vehicle Application
Domain
Web application security at browsers
The lightweight self-protecting JavaScript approach• “inline” the policy into the JavaScript code so that the code becomes self-protecting
• The policy enforcement is implemented in a lightweight manner • does not require browser modification• non invasive: the original code (and any
dynamically generated code) is not syntactically modified
• its implementation is a small and simple adaptation of an aspect-oriented programming library
17
Deployment illustration<html> <head> <script src=“selfprotectingJS.js"></script> <title>Self-protecting JavaScript </title> <meta content=…> <style>…</style> <script>…</script> <!-- more heading setting --> </head> <body> <script type="text/javascript"> (function() {..})(); </script> <!-- the content of page --> </body></html>
Policy code and
enforcement code defined in a text file
The enforcement code can be
deployed anywhere: server side, proxy or browser plug-in, i.e.
no need for a modified browser
The orgininal code is not
syntactically modified
6.33
66.03
0
10
20
30
40
50
60
70
Self-Protecting BrowserShield
Slo
wd
ow
n (t
imes
)
Runtime overhead
Our contributions in web security
Lightweight Self-Protecting JavaScript
ASIACCS’09
A Two-tier Sandbox Architecture for Untrusted
JavaScript
JSTools’12Safe Wrappers and Sane Policies for
Self-Protecting JavaScriptAppSec Research ’10
JSand: complete client-side sandboxing of third-party
JavaScript without browser modifications
ACSAC’11SAFESCRIPT: JavaScript Transformation for Policy Enforcement
Nordsec ’13
Summary• Fine-grained security policy enforcement remains a topic of research for all open systems• Smartphone• Vehicle• The Web
• The proposed lightweight IRM approach has benefits in providing a complete and robust tool for: • Java bytecode for open telematics systems• JavaScript running on a web browser.
