Lecture 36




Reminder: No class on Friday. CS Senior
Project presentations 1:30-2:40pm in KC-267
Posted: Homework 8, due Friday, April 20.
Case study final reports in PDF format due one
day before presentation. Presentations due
electronically day after presentation.
Questions?
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
1
Outline

Program threats

System and network threats

Current events article

Reis, Barth, and Pizano, "Browser Security:
Lessons from Google Chrome", Communications of
the ACM, August 2009.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
2
Program Threats

Trojan Horse: program that misuses the
environment it is in. Get an authorized user to
run a program that does something other than
what is expected.



Relative path is vulnerable, especially if '.' is in path.
Could end up running a different program.
Login screen emulators sniff passwords.
Spyware uses covert channels to communicate
surreptitiously, usually from victim machine.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
3
Program Threats


Trapdoor: special input recognized by a
program to circumvent security. Often used for
debugging, but then left open. Can be added
by the compiler, so not visible in source code.
Viruses: fragments of code embedded into
programs by "infecting" them. Generally very
malicious, e.g., deleting files, crashing systems,
etc.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
4
Program Threats


Stack & buffer overflow: overwrite the return
address to return to rogue program. Many
programs use fixed-size buffers in the stack to
store user data without guarding against
overflow.
While setting up an overflow attack takes
considerable knowledge, the exploit can be
scripted so that just about anyone (aka script
kiddie) can launch an attack.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
5
System and Network Threats

Worms: stand alone programs that propagate
through service vulnerabilities.


Morris worm (1988): exploited rsh, finger, and
sendmail. rsh uses .rhosts file to allow remote log in
without a password. finger was a buffer overflow on
the username argument. sendmail was a debug
backdoor that executed provided code.
Took down much of the precursor to the Internet.
Resulted in 3 years probation, 400 hours
community service, $10K fine. Legal costs >$100K
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
6
System and Network Threats


W32.Sobig.F@mm (2003): original worm was
hidden in a photo uploaded to a porn newgroup
using a stolen credit card number. Used its own
SMTP engine to email itself as an attachment to
every address found on the infected system. Was
the fastest spreading worm at the time the text was
written.
Port scanning: not an attack in and of itself,
but often used to test and detect system vulnerabilities in advance of an attack. Often done
from infected machines.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
7
System and Network Threats

Denial of Service (DoS): often easier than
trying to break in.



Java applet that eats CPU time or infinitely pops up
windows
TCP/IP SYN attack. Needs to be stopped at the
network level until the OS can catch up
Accidental DoS. E.g., CS courses using fork( ) or
new operator in loops.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
8
System and Network Threats

Generally not possible to stop DoS, especially
distributed attacks. Note that excessive
network connections may be the normal
consequence of something like a successful ad
campaign.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
9
What to do about security?

Cryptography and encryption (CS 415)

Frequent updates and anti-virus scans

Firewalls

Intrusion detection systems
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
10
Current Events Article




Reis, Barth, and Pizano, "Browser Security:
Lessons from Google Chrome",
Communications of the ACM, August 2009.
Authors are Google software engineers. Barth
was a postdoc at UC-Berkeley at time of article.
Example of a technical paper for a general
technical audience.
Summary: This paper discusses three key
problems for web browser security and how
Google Chrome addresses them.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
11
Web Browser Security


Web browsers are an appealing target for
attacks. Practically every computer has at least
one user that uses a web browser to connect
over a network to obtain content, services, and
applications. The user trusts that the browser
"does the right thing".
By their nature, web browsers invite outside
code to be executed on a user's computer.
Historically, every browser has had a bug that
allowed breaches of security.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
12
Web Browser Security


Also, even after security bugs are patched,
many users continue to run older, vulnerable
versions.
Authors identify three factors that contribute to
the security danger

Severity of vulnerabilities

Window of vulnerability

Frequency of exposure
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
13
Severity of Vulnerabilities



Ideally, all software is bug-free and lack
exploitable vulnerabilities. Reality is that we
can only hope to reduce the severity of
vulnerabilities.
Do this by isolating browser components and
reducing privileges to the minimum needed to
accomplish task to reduce the amount of
damage that can be done.
Google Chrome uses separate processes and
sandboxing along with various OS facilities.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
14
Security Architecture

Google Chrome consists of two types of
processes


Browser kernel: high-privilege process that
interfaces with user and runs under the user's
authority. Responsible for drawing the UI, store
cookies and history, network access.
Rendering engine: low-privilege processes that
acts on behalf of the Web content providers. They
are not trusted to interact with user file system.
Responsible for parsing HTML, executing
JavaScript, decode images to paint an off-screen
buffer, etc.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
15
Security Architecture
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
16
Security Architecture


Sandboxing is a generic term used to mean
that a process is run in an environment that
restricts its access to system resources.
Google Chrome uses two types of sandboxes
around the rendering engine


JavaScript sandbox that immediately surrounds the
process. This is a virtual machine that prevents
interaction between Web pages.
An OS sandbox that prevents any interaction with
other processes or the OS itself.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
17
Security Architecture


The only communication allowed by the
rendering engine is via an IPC channel to the
browser kernel with a restricted, simple
message interface. This includes HTTP
protocol traffic, rendered pages, and user input
events.
Implemented using OS facilities. In Windows,
uses a restricted security token. Mac OS X has
built-in sandbox facility. Linux has third-party
options.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
18
Exploitation Mitigation

Google Chrome uses various OS barriers to
make it more difficult for attackers to jump to
malicious code. From the Windows
implementation:


DEP (data execution prevention): mark memory
pages as non-executable, e.g., the stack
GS (stack overrun detection): places canary with
each stack call between current top of stack and
return address. Compiler inserts check for correct
canary value. Helps prevent stack overrun exploits.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
19
Exploitation Mitigation


ASLR (address space layout randomization):
randomizes the location of common system
components.
These mitigations can be used by any program
and do not require major changes to program
structure.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
20
Compatibility Challenges


Browsers must maintain compatibility with
emerging Web content, but plug-ins are not
designed to run in a sandbox.
At the time of the article, Google Chrome ran
plug-ins outside of the sandbox relying on thirdparties to provide adequate security. Since
then, they have started integrating plug-ins like
a PDF reader that do run inside the sandbox.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
21
Window of Vulnerability


Any exploit can cause harm. Want to minimize
the length of time users run unpatched
versions.
Two areas of activity

Automated quality testing

Convenient auto-updating for users
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
22
Automated Testing

When a vulnerability is discovered, Google
applies a three-step process to produce a
security patch.



Triage the severity of the the vulnerability and
assign an engineer to resolve the issue
Diagnose root cause and write a patch. Could be
as simple as adding a bounds check, or as complex
as replacing a data structure.
Test patch to make sure is both fixes the problem
and does not break any functionality
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
23
Automated Testing

Third step takes the longest. Want to automate
it. Google Chrome testing consists of:


Thousands of regression tests run after every
change to browser source code.
Tests on one million Web sites in a VM farm that
monitors rendering for memory errors, crashes, and
hangs. Often exposes race conditions and other
low-probability events.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
24
Security Updates



Auto-updating should be convenient and nondisruptive to user. Google Chrome uses a
system called Omaha that checks every 5
hours for updates.
When an update occurs, the download happens
in a parallel directory, then when the browser is
launched again, the new version takes over.
Updates happen shortly after they are available
and the user never has to wait.
Also, have added Flash Player to distribution.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
25
Frequency of Exposure


Google Chrome warns users if they try to visit a
site that has been reported as malicious, e.g.,
distributing malware or is a phishing attempt.
Issues include


Privacy: do not want to have every URL visited
reported to a central service. Solution is for
browser to download URL hashes periodically.
Minimizing false positives: provide tools help
publishers remove their URLS from blacklist when
they have been cleaned up.
Wednesday, April 11
CS 470 Operating Systems - Lecture 36
26