70004: Added new lectures

Author: OliverKillane

70004 - Advanced Computer Security/10 Years of Java Exploits.md

@@ -0,0 +1,18 @@
+## [10 Years of Java Exploits](https://comp97109.doc.ic.ac.uk/reading/10yearsJavaExploits.pdf)
+## Summary
+The paper presents an overview of 61 unique exploits against java's security isolation (reduced to their core mechanism from 87 exploits found on publicly available sources such as *Metasploit*, *Exploit-DB* and *Packet-Storm*) targeting the IBM and Oracle JDKs.
+
+The paper includes an introduction to Java's security model, and discusses the classified weaknesses & related exploits in this context. Statistics for the 
+## Pros
+1. The paper create a useful scheme/*"meta model"* for categorising exploits by primitives, attack vectors, and then grouping by a more abstract set of 9 weaknesses  (e.g. *"W5: Unauthorized use of restricted classes"*, or *"W2: Confused deputies"*) from 33 different *"attack vectors"*. By aggregating the large collection of exploits into these categories, it is easier to see the general security issues that need to be fixed, and to back decisions on prioritising focus with statistics on their use.
+2. The paper discusses potential solutions to the discussed weaknesses. For example suggesting adding the class initiating a thread to the thread's stack to limit some *"W3: Privileged Code Execution"* exploits. Another example in is in *"W5: Unauthorized use of restricted classes"* where the paper identifies restricted packages as a major surface area for attack, that has expanded  from 4 in `1.7.0` to 47 in `1.8.0u92`). It clearly identifies the potential solution in the Java Module System proposals.
+3. The .NET CLR is discussed as a different runtime that also uses stack-based access control. The abstraction of exploits into attack vectors and weaknesses also ensure some discussion is applicable across languages/implementations.
+4. The paper included exploits up to a recent version of java for the time, including Java `1.8.0u92` released on 19/04/2016, with the paper released in October that year.
+5. The introduction to java's security model is concise & provides sufficient context to understand the rest of the paper.
+## Cons
+1. The paper claims *"We make the full documentation of the exploit sample set publicly available along with this paper"* with the source repository https://github.com/pholzinger/exploitstudy. However this repository only contains a readme, and the *Download Additional Artifacts* download link is broken. I was unable to find the artifacts on the Wayback machine (earliest scan in 2019)
+2. The paper does not present new information beyond their simple *"meta-model"* and the statistics for the categories selected. It is suitable only as a summary.
+3. The paper contains a mix of solved and unpatched vulnerabilities to the range of java versions it analyses.  For example the *"W7: Serialization issues and type confusion"* weakness involves exploit `CVE-2013-1489`, though the paper does not make it clear that this exploit was present in java `1.7.0u10` and `1.7.0u11` fixed with many other exploits (see [Oracle Java SE Critical Patch Update Advisory - February 2013](https://www.oracle.com/security-alerts/javacpufeb2013.html)) on 01/02/2013, more than 3 years before this paper was released. This caused me some confusion as to which exploits were for historical discussion & were already fixed, and which were unresolved as of the paper's release.
+## Improvements
+1. Make the source for the paper available (including the vulnerabilities, reduced code, categorisations and backing of the statistics presented in the paper).
+2. Clearly denote which discussed vulnerabilities have been resolved (possibly discussing how & whether *"security patches literally only “patch” the discovered hole without addressing the actual underlying security problem"* - from introduction)

70004 - Advanced Computer Security/1975 Design Principles.md

@@ -3,7 +3,6 @@
 ## Description
 Covers the evolution of basic computer security principles.
 
-
 > In my view, a defender who doesn’t know how to attack is no defender at all. 
 > - Earl Boebert
 ## Commentary

70004 - Advanced Computer Security/A Few Billion Lines of Code Later.md

@@ -0,0 +1,17 @@
+## [Paper Link](https://dl.acm.org/doi/pdf/10.1145/1646353.1646374)
+## Summary
+The paper documents examples of technical and social difficulties in promoting the use of their coverity static analysis tool. Much of the article analyses the social response of developers to different types of error from the tool (such as false-positives), as well as to found bugs (e.g. dismissal of misunderstood diagnostics as false-positives by developers).
+## Pros
+1. The paper discusses the difficulty in accessing a representation of client codebases to analyse. This includes their decision to move from capturing make commands to capturing invocations of the compiler to identify files and their relations, as well as their use of modified EDG parsers and file transformations for C++ in order to support a huge number of compilers, versions, and build systems. 
+2. Strategies for solving developer-social problems and solutions are discussed. As coverity is a commercial tool ensuring developers & managers feel the tool is useful is just as important as the technical details of false-positive rates. Reactions ranging from *"Shrug"* to *"No, your tool is broken; that is not a bug"* are presented as reactions to on-site sales staff demoing the tool.
+3. The coverity tool has been used to find bugs in compilers. These range from *"dubious honor of being the single largest source of EDG bug reports after only three years of use"*, to finding a *"use-after-free bug"* in the Visual Studio C++ compiler when using a microsoft specific extension in debug mode.
+4. Careful ignoring of diganostics is allowed by the tool, this includes persisting ignores for diagnostics that are repeated, as well as ignoring errors originating from the codebase when the tool is initially used (developers want to keep old code unchanged and ignore errors from it).
+5. Coverity is deterministic, given the time constraints on the tool timeouts are discouraged and random algorithms (even *"elegant solutions to many of the exponential problems [they] encounter"* are disallowed). This is important for the aforementioned social aspect - developers need to trust the tool, and trust deterministic results more.
+## Cons
+1. Complex analyses are ignored due to their propensity for misdiagnosis and difficult errors. The paper gives very little detail on what complex analysis was investigated and rejected, and only leaves the justification that *"errors found with little analysis are often better than errors found with deeper tricks"*. Given other tools that have since been released such as infer (which directly competes with coverity as a bug finder not requiring annotation) do much complex analysis (e.g. finding data races, deadlock, and even basic performance analysis) across billion line codebases (at facebook, uber, mozilla and more) this justification is unsubstantiated.
+2. The tool is inherently conservative about reporting errors due to the distrust associated with false-positives. From the article it seems the developers opted to not include functionality, rather than convert suspect or high-false-positive scans into warnings. 
+3. Performance is impacted by the commitment to determinism, while this can be a positive (as mentioned in the *pros* section), it is a negative if you don't need determinism. The lack of options to enable faster non-deterministic scanners is a weakness in this respect.  
+4. Significant development resources are consumed supporting a wide variety of builds, compilers and standards, taking time away from bug-finding improvement. By comparison for C/C++ infer only supports code compliable with clang, and a limited number of build systems (cmake, make, gradle, buck).
+## Improvements
+1. Better justification of the technical decision to avoid more complex analyses, given infer has  found great success doing this.
+2. Better justification of the choice for determinism, how much performance is lost for a given example case.

70004 - Advanced Computer Security/Address Space Layout Randomisation.md

@@ -0,0 +1,4 @@
+## Definition
+A memory protection process for operating systems to guard against buffer overflow attacks by randomising the layout of executables loaded to memory.
+
+In order to exploit a buffer overflow to manipulate some code/data, the location of the buffer relative to said target code needs to be known, randomisation breaks this.

70004 - Advanced Computer Security/CVE-2012-1723.md

@@ -0,0 +1,22 @@
+## [NVD - CVE-2012-1723 (nist.gov)](https://nvd.nist.gov/vuln/detail/CVE-2012-1723)
+## Description
+A bug in [[HotSpot]]'s bytecode verifier that resulted in an invalid optimisation when bytecode verification is applied to deferred field access instructions (i.e. `GETSTATIC`, `PUTSTATIC`, `GETFIELD`, `PUTFIELD`).
+## Exploit
+See full description at [here](https://schierlm.users.sourceforge.net/CVE-2012-1723.html).
+```java
+
+class Myclass {
+    int member;
+    
+	void dothing(bool cont) {
+		if (!cont) {
+			return;
+		}
+		member += 2; // requires two accessses to the same member
+		member += 1;
+	}
+}
+```
+- The verification of the instructions is deferred until they need to be executed.
+- By calling the method with `cont = false` many times, the method is JIT compiled, but as we never hit `member` the two access instructions are never verified
+- On the next call with `cont = true` the partially-unverified JIT compiled version is called.

70004 - Advanced Computer Security/Common Language Runtime.md

@@ -0,0 +1,2 @@
+## Definition
+A common runtime environment targeted by C#, F#, Visual Basic, and now even a prototype for [Rust](https://github.com/FractalFir/rustc_codegen_clr).

70004 - Advanced Computer Security/Data Execution Prevention.md

@@ -0,0 +1,4 @@
+## Description
+Pages for the stack and heap are marked as non-executable, which prevents code loaded or generated and placed there from being executed.
+- protection against malicious code loaded from file or network from being executed.
+- Weakened by [[Return Oriented Programming]]

70004 - Advanced Computer Security/HotSpot.md

@@ -0,0 +1,6 @@
+## Definition
+The *Java HotSpot Performance Engine* is a [[Java Virtual Machine]] implemented by Sun, then taken over by oracle and finally open sourced under [[OpenJDK]].
+
+Its name is derived from analysing program behaviour to identify frequently executed code (hot spots) to JIT compiler.
+
+It was the default sun [[Java Virtual Machine]] from `java 1.3` onwards. 

70004 - Advanced Computer Security/Integrity.md

@@ -2,5 +2,4 @@
 > *How can Alice and Bob ensure Malory cannot tamper with their messages*
 
 Data and message integrity, detecting and repairing errors.
-- Techniques include using Hashing & Checksums, or message authentication codes.
-- 
+- Techniques include using Hashing & Checksums, or message authentication codes.

70004 - Advanced Computer Security/Java Security.md

@@ -0,0 +1,49 @@
+## Language Design
+*Note: More information available from [Overview of Java SE Security (oracle.com)](https://docs.oracle.com/javase/8/docs/technotes/guides/security/overview/jsoverview.html)*
+$$\text{Java} \underset{compile}{\longrightarrow} Bytecode \underset{interpret}{\longrightarrow} Execute$$
+Java is compiled to a portable bytecode that is then interpreted.
+- Bytecode comes in `.class` files
+- Bytecode can be created manually, and is not necessarily produced by a java compiler.
+The Java Virtual Machine loads the `.class`, and can then execute.
+$$\text{Loader} \to \text{Verifier} \to \text{Linker} \to \text{Bytecode Interpreter}$$
+Each program can have multiple threads with their own stacks, sharing a heap.
+### Class Loader
+A loader (potentially extending the default [ClassLoader](https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html)) loads files (or from network) and extracts bytecode.
+- This loading mechanism can be overridden and replaced
+- The classloader used to load a given class is included in the class object
+- Each class has a *protection domain* associated
+ - [[Code Signing]] can be used in some circumstances to verify the origin of a class.  
+### Verifier
+Checks the bytecode prior to loading (security & correctness), throwing a `verifyError` on failure.
+
+Given that there is no way to determine the source of some bytecode (i.e. if it was generated by `javac`, or manually constructed), bytecode cannot be trusted to be correct or not contain malicious non-java standard compliant code.
+#### Correctness Checks
+- Every instruction has a valid opcode, and obeys type discipline
+- Every branch goes to the start of a valid instruction
+- Access modifiers are not breached (e.g. access from outside class method to private member), including final (e.g. cannot extend `final class`)
+- No operand stack overflows or underflows
+- Methods have structurally correct signatures
+A larger list of checks is available from 
+### Linker
+Adds a compiled class or interface to the runtime, initialises static fields, and resolves names to reference the correct loaded classes/methods/statics.
+### Runtime Security
+Checks for [[Generic Bugs]] are performed (for example array bounds checks, null pointer access checks). Furthermore pointer arithmetic is not supported, and garbage collection is automatic.
+### Native Interaction
+Bytecode can be compiled into native (e.g. x86, ARM) instructions, as well as interoped with native code compiled from C/C++/other languages.
+- JIT is good for performance, and a core feature of [[HotSpot]]
+- Required for interaction with OS, drivers, etc that present a system call interface, or library interface over the C ABI.
+- Similarly C# and the [[Common Language Runtime]]
+
+## Security Manager
+Java library methods call the security manager to check permissions on operations.
+
+When called at runtime the *Security Manager* assesses:
+- The protection domain of the calling class (including the signer if [[Code Signing]] -  validated at load time, and the location of the java class)
+- A system policy is used to allow or deny permission to call the java library method.
+
+The checks usable can be found in the [SecurityManager documentation](https://docs.oracle.com/javase/8/docs/api/java/lang/SecurityManager.html#method.detail).
+
+Stack inspection is used to determine the calling method.
+- Permissions depend of the permission of methods above it on the stack.
+- Vulnerabilities have been found in the implementation of this method (see [[10 Years of Java Exploits]])
+