Race Conditions and Security

News o’ the day•Java security flaws

•3 bugs in Sun’s JRE

•Elevation of privilege, execution of arbitrary code, read/write local files from remote program

•Time to update your Java config...

Administrivia•Happy December!

•tick, tock...

Administrivia•Happy December!

•tick, tock...

•Happy new moon!

Administrivia•Happy December!

•tick, tock...

•Happy new moon!

•Reminder: Final exam

•Dec 13, 12:30 PM, usual room

Time rolls on...•Last time:

•Design principle: early vs. late commitment

•Timer threads

•(Race conditions)

•This time:

•Client-side communications

•Race conditions & security (for sure!)

Client-side communications•Issue:

•Data enters client through network listener thread

•GUI being processed on Swing/AWT event queue

•Need to transfer data between them

•Need to handle synchronization...

Classic MVC designNetworkListenerthread

Model(GridWorld2d

+ stuff)

GUI datastructures

(JLabel, etc.)data

(server update) set(x,y,data)notify(x,y)

get(x,y)

Classic MVC designNetworkListenerthread

Model(GridWorld2d

+ stuff)

GUI datastructures

(JLabel, etc.)data

(server update) set(x,y,data)notify(x,y)

get(x,y)

SWING/AWTevent proc

threadGUI

event(click, etc.)

Danger Will

Robinson!

Multiple access!

Data corruption!

Here beMonsters!

What you wantNetworkListenerthread

Model(GridWorld2d

+ stuff)

GUI datastructures

(JLabel, etc.)data

(server update)

set(x,y,data)

notify(x,y)

get(x,y)

SWING/AWTevent proc

thread

A miracleoccurs

GUIevent

(click, etc.)Deferre

d!

WTF?

How to get there...

•Need some way for listener thread to:

•Store the incoming data temporarily

•Notify the event thread: “Hey! There’s some new data! Come deal with it!”

•Requires:

•Synchronized access to temp data store

•Rapid turnaround in listener thread

How to get there...

•Clever, clever SWING designers thought of this...

•javax.swing.SwingUtilities.invokeLater()

•Takes a Runnable

•Event thread executes Runnable.run() “when it’s convenient”

•After rest of outstanding AWT events have cleared

How to get there...

•Clever, clever SWING designers thought of this...

•javax.swing.SwingUtilities.invokeLater()

•Immediately returns control to calling thread (network listener)

•Executes Runnable.run() once

•Does not create a new thread

Network listener codepublic void listenToNetwork(Socket s) {

while (!toStop) {Message data= // read from networksynchronizedBuffer.add(data);SwingUtilities.invokeLater(new _msgHandler());

}}

Network listener codepublic void listenToNetwork(Socket s) {

while (!toStop) {Message data= // read from networksynchronizedBuffer.add(data);SwingUtilities.invokeLater(new _msgHandler());

}}

private static class _msgHandlerimplements Runnable {

public void run() {Message m=synchronizedBuffer.remove();while (m!=null) {

m.execute(model);m=synchronizedBuffer.remove();

}} } }

Alternately...public void listenToNetwork(Socket s) {

while (!toStop) {Message data= // read from networkSwingUtilities.invokeLater(new _msgHandler(data));

}}

private static class _msgHandlerimplements Runnable {

public _msgHandler(Message m) { _data=m; }public void run() {

m.execute(model);}private final Message _data;

}}

A final note•The example chat client you have does not do this

•May be a bug...

•... Or the author may know something I don’t

•This is my best understanding from SWING docs

•Caveat emptor!

Race Conditions & Security

Race Cond. & Security•Atomicity failures can sometimes be exploited to break security on multiprocessing systems

•One of the top 10 classes of exploits since... mid-1980’s, at least

•100’s (or more) of reported vulnerabilities

•Independent of language: Java will not save you!

•Hostile program grabs a shared resource (e.g., file) before it is secured

•Beware when writing privileged code!

•N.b.: Sometimes your never-intended-to-be- secure code will be run in privileged context!

Basic Race Cond. Exploitpriv proc

Basic Race Cond. Exploitpriv proc

file/tmp/foo

write()

read()

close()

unlink()

open(“/tmp/foo”, O_RDWR | O_CREAT);

Basic Race Cond. Exploitpriv proc

open(“/tmp/foo”, O_RDWR | O_CREAT);

file/tmp/foo

write()

read()

close()

unlink()

hostile proc

open(...)

read()

Basic Race Cond. Exploitpriv proc

open(“/tmp/foo”, O_RDWR | O_CREAT);

file/tmp/foo

write()

read()

close()

unlink()

hostile proc

chmod()

Basic Race Cond. Exploitpriv proc

open(“/tmp/foo”, O_RDWR | O_CREAT);

file/tmp/foo

write()

read()

close()

unlink()

hostile proc

chmod()

open(...)

Basic Race Cond. Exploitpriv proc

open(“/tmp/foo”, O_RDWR | O_CREAT);

file/tmp/foo

write()

read()

close()

unlink()

hostile procumask()

Basic Race Cond. Exploitpriv proc

open(“/tmp/foo”, O_RDWR | O_CREAT);

file/tmp/foo

write()

read()

close()

unlink()

hostile procumask() open(...)

read()

Basic Race Cond. Exploitpriv proc

open(“/tmp/foo”, O_RDWR | O_CREAT);

file/tmp/foo

write()

read()

close()

unlink()

hostile procumask()

symlink(“/tmp/foo”, “/etc/passwd”)

Basic Race Cond. Exploitpriv proc

stat(“/tmp/foo”);if (!exists) {

open(“/tmp/foo”, O_RDWR | O_CREAT);} else { error(); }

file/tmp/foo

write()

read()

close()

unlink()

hostile procumask()

Basic Race Cond. Exploitpriv proc

stat(“/tmp/foo”);if (!exists) {

open(“/tmp/foo”, O_RDWR | O_CREAT);} else { error(); }

file/tmp/foo

write()

read()

close()

unlink()

hostile procumask()

symlink(“/tmp/foo”, “/etc/passwd”)

Preventing FS Race Conds•Could create “foo” in dir owned/writable only by owner of proc

•Can be hard to ensure this

•Still have to watch out for filename collisions

•Could make file names hard to predict (e.g., picked randomly)

•Exploit still possible; hard to make fnames really random

•Ultimate answer: use OS atomicity facilities

•open(“/tmp/foo”, O_RDWR | O_CREAT | O_EXCL)

•Always be on guard!