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 design Network Listener thread Model (GridWorld2d + stuff) GUI data structures (JLabel, etc.) data (server update) set(x,y,data) notify(x,y) get(x,y)

Classic MVC design Network Listener thread Model (GridWorld2d + stuff) GUI data structures (JLabel, etc.) data (server update) set(x,y,data) notify(x,y) get(x,y) SWING/AWT event proc thread GUI event (click, etc.) Danger Will Robinson! Multiple access! Data corruption! Here be Monsters!

What you want Network Listener thread Model (GridWorld2d + stuff) GUI data structures (JLabel, etc.) data (server update) set(x,y,data) notify(x,y) get(x,y) SWING/AWT event proc thread A miracle occurs GUI event (click, etc.) Deferred ! 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 code public void listenToNetwork(Socket s) { while (!toStop) { Message data= // read from network synchronizedBuffer.add(data); SwingUtilities.invokeLater(new _msgHandler()); }

Network listener code public void listenToNetwork(Socket s) { while (!toStop) { Message data= // read from network synchronizedBuffer.add(data); SwingUtilities.invokeLater(new _msgHandler()); } private static class _msgHandler implements 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 network SwingUtilities.invokeLater(new _msgHandler(data)); } private static class _msgHandler implements 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. 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 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!