Post on 22-Dec-2015
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;
}