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 CS35 1 8:009:0010:0011:0012:001:002:003:00 CS35 1 8:009:0010:0011:0012:001:002:003:00

Dictionary confusions UNM’s definition of “delay”: de· lay |di ˈ lā| (n): Cancel some stuff, but make no other changes. CS35 1 8:009:0010:0011:0012:001:002:003:00 CS35 1 ??? 8:009:0010:0011:0012:001:002:003: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 (); } public void addThing(String id, Object thing) { _data.put(id,thing); } public Object getThing(String id) { return _data.get(id); } private final Map _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. Exploit priv proc

Basic Race Cond. Exploit priv proc file /tmp/foo write() read() close() unlink() open(“/tmp/foo”, O_RDWR | O_CREAT);

Basic Race Cond. Exploit priv proc open(“/tmp/foo”, O_RDWR | O_CREAT); file /tmp/foo write() read() close() unlink() hostile proc open(...) read()

Basic Race Cond. Exploit priv proc open(“/tmp/foo”, O_RDWR | O_CREAT); file /tmp/foo write() read() close() unlink() hostile proc chmod()

Basic Race Cond. Exploit priv proc open(“/tmp/foo”, O_RDWR | O_CREAT); file /tmp/foo write() read() close() unlink() hostile proc chmod() open(...)

Basic Race Cond. Exploit priv proc open(“/tmp/foo”, O_RDWR | O_CREAT); file /tmp/foo write() read() close() unlink() hostile proc umask()

Basic Race Cond. Exploit priv proc open(“/tmp/foo”, O_RDWR | O_CREAT); file /tmp/foo write() read() close() unlink() hostile proc umask() open(...) read()

Basic Race Cond. Exploit priv proc open(“/tmp/foo”, O_RDWR | O_CREAT); file /tmp/foo write() read() close() unlink() hostile proc umask() symlink(“/tmp/foo”, “/etc/passwd”)

Basic Race Cond. Exploit priv proc stat(“/tmp/foo”); if (!exists) { open(“/tmp/foo”, O_RDWR | O_CREAT); } else { error(); } file /tmp/foo write() read() close() unlink() hostile proc umask()

Basic Race Cond. Exploit priv proc stat(“/tmp/foo”); if (!exists) { open(“/tmp/foo”, O_RDWR | O_CREAT); } else { error(); } file /tmp/foo write() read() close() unlink() hostile proc umask() 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 Java private Thread _myLock=null; public void myCriticalMethod() { while (_myLock!=null); _myLock=Thread.currentThread(); // do mutex critical section code _myLock=null; }