Extensible Security Architectures for Java ========================================== We saw with SFI that software protection makes boundary crossings a lot cheaper Java, as a safe language, also makes boundary crossings cheaper In Fig. 1, evidence suggests mobile code naturally crosses boundaries a lot What is the difference between boundary crossings in SFI vs. Java? With SFI, crossings more like RPCs All permitted calls must be enumerated in Jump tables With Java, any method call can be a boundary crossing At high level, Java divides code into local, trusted, and remote untrusted What is a ClassLoader? Takes an array of bytes, and treats them as bytecodes It's how you get new classes into the system Every class is loaded by a ClassLoader Keeps a reference to its ClassLoader Any other classes accessed by the class are loaded by its loader Every stack frame has a pointer to the class's loader Local classes have a special system class loader So by looking at stack can know if you were called by a trusted class or not Security policies are enforced by a SecurityManager class Can check if any untrusted fram on stack, and throw exception if so Is this good enough? No... not enough flexibility E.g., trusted code might need to open file (in restricted directory) on behalf of untrusted code How do you formulate a policy in Java? What is a principal? Principals are implemented as digital signatures on code Principal is the author of the code, not the person running the code! Signature represents endorsement--multiple people might sign same applet Want policy engine that can answer questions about access But should also be extensible, if new resource types are added Capabilities We've talked of three kinds of capabilities: Hardware-enforced, kernel-enforced, and self-authenticating Which kind of capability are Java capabilities? Most like kernel-enforced, though in JVM & jave system, not kernel Do pointers make good capabilities? Sort of--you need a reference to an object in order to call methods Applet must call static methods to get pointers--can control access But no permission bits on pointers--e.g., can't give read-only access Is treating capabilities like pointers a viable approach to java security? None of the libraries were written with this as an assumption E.g., even if you block access to FileSystem, applet can just construct its own FileInputStream object would need to hide FileInputStream or make constructor private Would require rewriting all the java libraries Extended stack introspection Add three new calls: enablePrivilege() disablePrivilege() checkPrivilege() Idea: Policy determines who can enablePrivilege what privs trusted code calls checkPrivilege(), which throws exception if privilege was not enabled Problem: What is a *luring* attack? Trusted code enables privilege, calls untrusted code (e.g., window cb) So how is checkPrivilege implemented? enablePrivilege(target) checks if caller has that privilege, if so, marks the privilege as enabled on the stack checkPrivilege() goes back through the stack inspecting each frame - If it finds a frame with privilege enabled, OK - permitted - If it finds a un untrusted frame (remote ClassLoader), fail - If it hits top of stack? Netscape: default to no privilege Microsoft: default to OK (for compatibility w. all-local program) Name space management Idea: Implement a new ClassLoader, PrincipalClassLoader PrincipalClassLoader hides certain classes from applet, based on policy + Simple to implement + Allows untrusted code to be bundled with trusted components - Libraries not designed for this E.g., to get secure files, would need to hide FileInputStream which would break sockets Java Security: From HotJava to Netscape and Beyond =================================================== So we know what mechanisms are available... what are the kinds of things we need to defend against? Denial of service attacks Busy waiting Grab locks on critical pieces of code (e.g., static synchronized funcs) Covert Channels - What if site unwittingly serves bad applet? Supposedly applet can only communicate with server whence it came accept() system call not protected, however Applet can also connect to server SMTP port and mail its bad author Also, DNS routines can be used as two-way communication channel Look up name in attacker's domain, name/result contain information HotJava even allowed DNS calls when supposedly no network access Applets can make browser download any page on the web Could be used to log all web requests from a user running bad applet Some URLs perform acctions (e.g., delete message in web mail account) Too much information is available to applets Default permissions sometimes allowed write access to \TEMP System.getenv() leaks a host of information to applet Implementation bugs Restriction on only connecting back to applet's server is broken As long as server and target have one IP address is common, connect allowed Can easily manipulate DNS for this to be the case Using this technique, applet can attack hosts behind the user's firewall Buffer overflows in early versions allowed attacks w. long symbol names Public proxy variables let attacker redirect all requests to his own proxy! Inter-applet security Applets can find out what other applets are running Can call stop() and setpriority() on other applets! Java Language vs. JVM All constructors must call another constructor or a superclass constructor SecurityManager, FileInputStream, & SecurityManager All check to make sure they are not called from an applet Throw an exception if called in an illegal context Unfortunately bytecode verifier lets programs catch these exceptions Attacker can create his own class loader Allows arbitrary manipulation of name spaces Can completely defeat type system Make name C in class A mean C, and in class B mean C' Passing object o of type C from A to B Can now access o as if it were type C' Private fields in C might correspond to public locations in C' Bad package names allow code to be loaded from file system Code loaded from file system treated as trusted But what about something like AFS or SFS? Can access attacker's files Also, the browser cache itself contains files from the attacker Language type system not specified, yet relied on for security Bytecode verification a more difficult task than source verification Why not ship source? Obfuscation, probably Efficiency, maybe (initial byte code verifiers not faster than compiler) Methods can be called on partially initialized objects This can be very confusing to programmers E.g., superclass constructor calls overridden function private keyword not enforced on code loaded from disk Allows inlining of procedures, at potential cost of security Section 4 of paper looks at Java in light of the Orange book. Java isn't a military system... is the Orange book relevant? Some obscure military concepts become relevant with web security! Information flow--don't want untrusted code leaking information Policy--need to control more strictly what resources applets access Monitor--The JVM and system classes are much like a reference monitor How does Java do by orange book criteria? Policy--no explicit and well-defined policy Does it provide a reference monitor? No, lacks 3 properties: 1. Always invoked - No, only when core class implementers remember 2. Tamperproof - No, because of bugs, but could be fixed 3. Verifiable - No, because java does not have semantics Discussion: What would it take to fix java in orange book fashion? Probably most important issue is for securitymanager always to be invoked Might have to redesign API into multiple levels: programmer-friendly interface on top of more bare-bones TCB How many problems would be prevented with JiF? Discussion: What can you do about fundamental problem that most users do not know enough to express policies? - Browser vendor can include pre-set policies ("typical game") - Make policy decisions implicit in natural interfaces (e.g., file selection dialog implicitly give permission to save in a file name) - Require trusted path to authorize security-sensitive operations Remember "secure attention key" in Vax VMM security kernel? How about "Push to talk" button so applet can't turn mike on itself?