Oh what a tangled web we weave…

… when first to thread we do conceive

Lecture 24, Dec 08

Dictionary confusions

Most people’s definition of “delay”:

de· lay |diˈlā| (n): A period of time by which something is late or postponed

CS351

8:00 9:00 10:00 11:00 12:00 1:00 2:00 3:00

CS351

8:00

9:00

10:00

11:00

12:00

1:00

2:00

3:00

Dictionary confusions

UNM’s definition of “delay”:

de· lay |diˈlā| (n): Cancel some stuff, but make no other changes.

CS351

8:00 9:00 10:00 11:00 12:00 1:00 2:00 3:00

CS351

???

8:00

9:00

10:00

11:00

12:00

1:00

2:00

3:00

Administrivia•Final exam reminder

•Tue, Dec 15, 12:30-2:30 PM; normal room

•Rollout/end of semester party

•Fri, Dec 18 noon

•FEC309 lab

•Show off swank software, see each other’s projects, kick back, celebrate the end of CS351

•If you RSVP, Prof Lane will spring for lunch

Whence and Whither•Last time

•Memory diagrams

•… ad nauseum

•Today

•More memory diagrams! Yay!

•Specifically, threading model + memory

•Threading, race conditions, security, and you...

(Yet) Mo’ Memory

The setup...public class DataBlob { public DataBlob() { _data=new HashMap<String, Object>(); }

public void addThing(String id, Object thing) { _data.put(id,thing); } public Object getThing(String id) { return _data.get(id); }

private final Map<String,Object> _data;}

The setup...public class ClientListener implements Runnable { public ClientListener(Socket s, DataBlob b) { assert s!=null; assert b!=null; _boredNow=false; _dataPort=s; _store=b; _in=new ObjectInputStream(s.getInputStream()); } public void run() { while (!_boredNow) { Object o=_in.readObject(); _store.addThing(o.toString(),o); } } private final ObjectInputStream _in; private final Socket _dataPort; private final DataBlob _store; private boolean _boredNow;}

The setup...public class Server { public static void main(String[] args) { final DataBlob d=new DataBlob(); boolean stuffToDo=true; // set up the server thread, sockets, and so on final Socket p=null; ClientListener cl1=new ClientListener(p,d); ClientListener cl2=new ClientListener(p,d); final Thread ct1=new Thread(cl1); final Thread ct2=new Thread(cl2); ct1.start(); ct2.start(); // enter the main processing loop while (stuffToDo) { final String id="whatever"; final Object thing=data.getThing(id); final Object newThing=_modify(thing); data.addThing(newThing.toString(),newThing); } }}

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

•Half dozen or so (reported) since July of this year...

The core exploit•Privileged program creates a resource

•Hostile program grabs a shared resource (e.g., file):

•Before it is created (predicting its name/handle)

•After it is created, but before it is secured

•Privileged program accesses (R/W) resource

•Hostile program controls what privileged program sees

You thought you were safe

•Independent of language: Java will not save you!

•Beware when writing privileged code!

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

•Happens a lot on the web...

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

Preventing FS Race Conds

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

•Exploit still possible; hard to make fnames really random

•Similar “prediction” attack used to break early Netscape implementation of SSL

Preventing FS Race Conds•Ultimate answer: use OS atomicity facilities

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

•Similar mechanisms used at OS level to ensure atomic access to locks/monitors

•atomicTestAndSet(), et al.

•Harder w/ distributed databases -- data lives on multiple hosts

•DBs usually offer atomic access mechanisms for you

•Always be on guard!

Screwing up in Javaprivate Thread _myLock=null;

public void myCriticalMethod() {while (_myLock!=null);_myLock=Thread.currentThread();// do mutex critical section code_myLock=null;

}