cs205: engineering software university of virginia fall 2006

cs205: engineering software university of virginia fall 2006 Hair-Dryer Attacks Image from www.clean-funny.com, GoldenBlue LLC.

Project Design Documents • A description of your project: what it will do and why it is useful, fun, or interesting. • A high-level description of your design, including a module dependency diagram showing the most important modules. • A description of your implementation and testing strategy including: • how you will divide the work amongst your team • how you will order the work to support incremental development • how you will do unit testing and integration testing • a list of milestones and a schedule for achieving them, leading to a completed project on December 4 • A list of questions

Friday’s Class • Project Design Documents due at beginning of class • Class will be at Undergraduate Research Symposium – Harrison Special Collections Library • 1:00pm Adrienne Felt, “Disk-Level Malware Detection” • other talks: “Candomblé and Healthcare in Bahia”, “An Investigation of the Medical Atmosphere in South Africa: the Role of Community Home-Based Caregivers”

Quiz • Everyone got 0xCAFEBABE • 3 people sort of got question 6 (full credit if your answer convinced me you’d looked at the ps5 comments) • I’ll ask a question on the final (open notes) about this same question, so make sure you understand it before then.

Teammate Assessment • Your answers: • Mostly: fair share of work, quality of work • “Did anybody make a huge breakthrough with some great idea that made everything else go smoother/faster?” • Being a good teammate is more... • Responsibility: takes responsibility for parts of the project and follows through • Reliability: comes to meetings on time • Cooperative: listens to teammates, willing to discuss things respectfully and come to a shared decision

Future Topics • write-ins: • GUI programming and design (4 people) • network programming (2 people) • “I think I have seen enough. :)” • Famous Software Disasters (everyone ranked, 1 2 2 2 5 6 7 7 9) • Web Programming (1 1 1 1 2 2 4 6) • C# (1 1 1 3 4), Different Programming Languages (4 5 6 7) • Performance (3 3 3 3 4 6 10)

checkcast • No one had a good answer to the checkcast question • “Explain what the checkcast instruction does?” vs “Write a specification for the checkcast instruction”

Pseudo-method Specification instruction checkcast (Stack s, Type t) throws CheckCastException REQUIRES s must contain at least one element, and the top of s must be an object reference MODIFIES nothing EFFECTS If the object on the top of the stack could be used where a type t is expected, no effects. Otherwise, throws CheckCastException.

checkcast Operation Check whether object is of given type Format checkcast Operation Check whether object is of given type Format checkcast indexbyte1 indexbyte2 Formscheckcast = 192 (0xc0) Operand Stack ..., objectref  ..., objectref DescriptionThe objectref must be of type reference. The unsignedindexbyte1 and indexbyte2 are used to construct an index into the runtime constant pool of the current class (§3.6), where the value of the index is (indexbyte1 << 8) | indexbyte2. The runtime constant pool item at the index must be a symbolic reference to a class, array, or interface type. The named class, array, or interface type is resolved (§5.4.3.1). Java VM Specification http://java.sun.com/docs/books/vmspec/2nd-edition/html/Instructions2.doc2.html

If objectref is null or can be cast to the resolved class, array, or interface type, the operand stack is unchanged; otherwise, the checkcast instruction throws a ClassCastException. • The following rules are used to determine whether an objectref that is not null can be cast to the resolved type: if S is the class of the object referred to byobjectref and T is the resolved class, array, or interface type, checkcast determines whether objectref can be cast to type T as follows: • If S is an ordinary (nonarray) class, then: • If T is a class type, then S must be the same class (§2.8.1) as T, or a subclass of T. • If T is an interface type, then S must implement (§2.13) interface T. • If S is an interface type, then: • If T is a class type, then T must be Object(§2.4.7). • If T is an interface type, then T must be the same interface as S or a superinterface of S (§2.13.2). • If S is a class representing the array type SC[], that is, an array of components of type SC, then: ...

If S is a class representing the array type SC[], that is, an array of components of type SC, then: • If T is a class type, then T must be Object (§2.4.7). • If T is an array type TC[], that is, an array of components of type TC, then one of the following must be true: • TC and SC are the same primitive type (§2.4.1). • TC and SC are reference types (§2.4.6), and type SC can be cast to TC by recursive application of these rules. • If T is an interface type, T must be one of the interfaces implemented by arrays (§2.15). • Linking Exceptions • During resolution of the symbolic reference to the class, array, or interface type, any of the exceptions documented in Section 5.4.3.1 can be thrown. • Runtime Exception • Otherwise, if objectref cannot be cast to the resolved class, array, or interface type, the checkcast instruction throws a ClassCastException. • Notes • The checkcast instruction is very similar to the instanceof instruction. It differs in its treatment of null, its behavior when its test fails (checkcast throws an exception, instanceof pushes a result code), and its effect on the operand stack.

Quiz 3 • Which of these components are part of the trusted computing base when a user runs a Java applet in a web page? Components: applet source code, applet class file, Java compiler, Java bytecode verifier, Java VM.

Java Security malcode.java javac Compiler malcode.class JVML Java Bytecode Verifier Invalid Trusted Computing Base “Okay” STOP JavaVM

Simulating All Paths • The bytecode verifier verifies type safety for all possible executions of the program • Since there are infinitely many paths through the program, how is this possible?

Verifier (should be) Conservative JVML programs Safe programs Verifiable programs (Slide from Nate Paul’s ACSAC talk)

Complexity Increases Risk JVML programs Safe programs Verifiable programs Bug (Slide from Nate Paul’s ACSAC talk)

Vulnerabilities in JavaVM 45 40 35 30 25 Vulnerabilities Reported 20 15 10 5 0 0 1 2 3 4 5 6 7 8 9 July 1996 Years Since First Release July 2005

Where are They? several of these were because of jsr complexity

Summary:Low-level vs. Policy Security • Low-level Code Safety: • Type safety, memory safety, control flow safety • Needed to prevent malcode from circumventing any policy mechanism • Policy Security: • Control access and use of resources (files, network, display, etc.) • Enforced by Java class • Hard part is deciding on a good policy

Bytecode Verifier • Checks JVML code satisfies safety properties • Simulates program execution to know types are correct, but doesn’t need to examine any instruction more than once • After code is verified, it is trusted: is not checked for type safety at run time (except for casts, array stores) Key assumption: when a value is written to a memory location, the value in that memory location is the same value when it is read.

Violating the Assumption … // The object on top of the stack is a SimObject astore_0 // There is a SimObject in location 0 aload_0 // The value on top of the stack is a SimObject If a cosmic ray hits the right bit of memory, between the store and load, the assumption might be wrong.

Improving the Odds • Set up memory so that a single bit error is likely to be exploitable • Mistreat the hardware memory to increase the odds that bits will flip Following slides adapted (with permission) from Sudhakar Govindavajhala and Andrew W. Appel, Using Memory Errors to Attack a Virtual Machine, July 2003.

Making Bit Flips Useful Fill up memory with Filler objects, and one Pointee object: class Filler { class Pointee { Pointee a1; Pointee a1; Pointee a2; Pointee a2; Pointee a3; Filler f; Pointee a4; int b; Pointee a5; Pointee a5; Pointee a6; Pointee a6; Pointee a7; Pointee a7; } }

a1 Filling Up Memory a2 a3 a4 Filler Object a5 a6 Pointee p = new Pointee (); Vector fillers = new Vector (); try { while (true) { Filler f = new Filler (); f.a1 = p; f.a2 = p; f.a3 = p; …; f.a7 =p; fillers.add (f); } } catch (OutOfMemoryException e) { ; } a7 a1 a2 f Pointee Object b a5 a6 a7 a1 Filler Object a2 a3 a4 a5 a6 a7

a1 Wait for a bit flip… a2 a3 a4 Filler Object a5 • Remember: there are lots of Filler objects (fill up all of memory) • If a bit flips, good chance (~70%) it will be in a field of a Filler object and it will now point to a Filler object instead of a Pointee object a6 a7 a1 a2 f Pointee Object b a5 a6 a7 a1 Filler Object a2 a3 a4 a5 a6 a7

a1 Type Violation a2 a3 a4 Filler Object a5 After the bit flip, the value of f.a2 is a Filler object, but f.a2 was declared as a Pointee object! a6 a7 a1 a2 f Pointee Object b a5 a6 Can an attacker exploit this? a7 a1 Filler Object a2 a3 a4 a5 a6 a7

Pointee p = new Pointee (); Vector fillers = new Vector (); try { while (true) { Filler f = new Filler (); f.a1 = p; f.a2 = p; f.a3 = p; …; f.a7 =p; fillers.add (f); } } catch (OutOfMemoryException e) { ; } Finding the Bit Flip while (true) { for (Enumeration e = fillers.elements (); e.hasMoreElements () ; ) { Filler f = (Filler) e.nextElement (); if (f.a1 != p) { // bit flipped! … } else if (f.a2 != p) { … } }

class Filler { class Pointee { Pointee a1; Pointee a1; Pointee a2; Pointee a2; Pointee a3; Filler f; Pointee a4; int b; Pointee a5; Pointee a5; Pointee a6; Pointee a6; Pointee a7; Pointee a7; } } Violating Type Safety Filler f = (Filler) e.nextElement (); if (f.a1 != p) { // bit flipped! Object r = f.a1; // Filler fr = (Filler) r; // Cast is checked at run-time Declared Type f.a1 Pointee f.a1.b int fr == f.a1 Filler fr.a4 == f.a1.b Pointee

class Filler { class Pointee { Pointee a1; Pointee a1; Pointee a2; Pointee a2; Pointee a3; Filler f; Pointee a4; int b; Pointee a5; Pointee a5; Pointee a6; Pointee a6; Pointee a7; Pointee a7; } } Violating Type Safety Filler f = (Filler) e.nextElement (); if (f.a1 != p) { // bit flipped! Object r = f.a1; // Filler fr = (Filler) r; // Cast is checked at run-time f.a1.b = 1524383; // Address of the SecurityManager fr.a4.a1 = null; // Set it to a null // Do whatever you want! No security policy now… new File (“C:\thesis.doc”).delete ();

Getting a Bit Flip • Wait for a Cosmic Ray • You have to be really, really patient… (or move machine out of Earth’s atmosphere) • X-Rays • Expensive, not enough power to generate bit-flip • High energy protons and neutrons • Work great - but, you need a particle accelerator • Hmm….

Using Heat • 50-watt spotlight bulb • Between 80°-100°C, memory starts to have a few failures • Attack applet is successful (at least half the time)! • Hairdryer works too, but it fries too many bits at once Picture from Sudhakar Govindavajhala

Should Anyone be Worried? Java virtual machine

Recap • Verifier assumes the value you write is the same value when you read it • By flipping bits, we can violate this assumption • By violating this assumption, we can violate type safety: get two references to the same storage that have inconsistent types • By violating type safety, we can get around all other security measures • For details, see paper linked from notes

Charge • Project design documents due Friday • Class will be at URN in Harrison Special Collections Library

cs205: engineering software university of virginia fall 2006