70004: Added new lectures

Author: OliverKillane

Diff for: 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)

Diff for: 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

Diff for: 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.

Diff for: 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.

Diff for: 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.

Diff for: 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).

Diff for: 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]]

Diff for: 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. 

Diff for: 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.

Diff for: 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]])
+ 

Diff for: 70004 - Advanced Computer Security/Java Virtual Machine.md

@@ -0,0 +1,6 @@
+## Definition
+A specification for a java bytecode interpreter. For example [The Java® Virtual Machine Specification (oracle.com)](https://docs.oracle.com/javase/specs/jvms/se7/html/).
+
+There are many implementations of the JVM, including [[HotSpot]] , [[IBM J9]] .
+
+The [[OpenJDK]] project includes an open source implementation of [[HotSpot]].

Diff for: 70004 - Advanced Computer Security/Malware.md

@@ -0,0 +1,10 @@
+## Definition
+Any software intended to be malicious to the system (and the system's users) it runs on.
+
+| Type | Description |
+| ---- | ---- |
+| Virus | A program capable of making copies of itself, and inserting those copies into other programs. |
+| Worm | A virus can can distribute itself to other systems. |
+| Spyware | Software to spy/gather information from a system. |
+| Trojan | Software masquerading as legitimate to provide a backdoor to an attacker. |
+| Drive by Download | A malware delivery technique triggered when a user accesses a website. |

Diff for: 70004 - Advanced Computer Security/Return Oriented Programming.md

@@ -0,0 +1,10 @@
+## Definition
+Forcing a jump to a gadget (a section of code already included & executable within a binary, ending in a return statement) by abusing the saved return pointer on the stack to force a jump to said code on return (i.e. loading that value from stack to the link register and executing a return instruction, or a jump to said register).
+
+By building up a stack of return values these gadgets can be chained together.
+
+Automatic tools for compiling return oriented code have been developed, such as Mona and [Q](https://edmcman.github.io/papers/usenix11.pdf). Gadgets can be found with tools like [ROPgadget](https://github.com/JonathanSalwan/ROPgadget).
+## Preventative Measures
+Tools to break gadgets (see [[Smashing the Gadgets]]), and types of [[Address Space Layout Randomisation]]
+## Examples
+[[Return to libc]]

Diff for: 70004 - Advanced Computer Security/Return to libc.md

@@ -0,0 +1,15 @@
+## Description
+The original [[Return Oriented Programming]] exploit, as `libc` is almost always linked, it takes advantage of gadgets present in `libc`.
+
+Many of these gadgets are powerful as `libc` contains useful calls from os-interaction.
+
+For example
+```python
+Stack:
+...
+address of system() in libc
+return from system()        <- EIP
+address of string "/bin/sh" <- ESP
+...
+```
+On return instruction, we jump to system with the string argument on the stack (hence running a new shell), on return from system() we are once again redirected to another address.

Diff for: 70004 - Advanced Computer Security/Security Principles.md

@@ -0,0 +1 @@
+[[Authentication]] [[Authorization]] [[Availability]] [[Confidentiality]] [[Non-Reputation]] [[Accountability]] [[Integrity]]

Diff for: 70004 - Advanced Computer Security/Virus-Antivirus Co-Evolution.md

@@ -0,0 +1,40 @@
+## Definition
+The changes in virus ([[Malware]]) and antivirus techniques as a result of improvements in the other.
+## Stages
+### Start
+| Virus | Antivirus |
+| ---- | ---- |
+| When the file is executed, modify other files to infect/include a copy of the virus. | Identify common virus code sequences (signatures), and can to find instances of the sequences in files. |
+*Antivirus is bound by the ability to scan files, and the current database of signatures to match.*
+### Entry Point Scanning
+| Virus | Antivirus |
+| ---- | ---- |
+| Place at the entry point of a program (or directly reachable from) and make the virus as small as possible to make matching signatures more difficult. | Scan and traverse entry points & code reachable from them to find jumps to virus code |
+### Encryption
+| Virus | Antivirus |
+| ---- | ---- |
+| Encrypt the virus's body on disk, and include a decryption routine to unencrypt into memory for execution. can then jump to this code/start of buffer. | Decryption routines (packers) are easy to fingerprint/get signature. |
+*Virus needs to use new keys when adding encrypted code to new files*
+### Polymorphic
+| Virus | Antivirus |
+| ---- | ---- |
+| Use a mutation engine to generate different encryption/decryption routine pairs that are semantically identical, but are represented differently (so antivirus signatures not effective)  | A custom detection program is used to recognise different engines. |
+*Antivirus can use Generic Decryption, where an emulator and signature matching engine is used to emulate and find viruses decrypting themselves. Snapshots of memory/disk at intervals can also be used to find viruses mid-decryption.*
+- *Virus can deliberately slow down and make emulation more difficult (e.g. adds sleeps)*
+- *Typically both signature-based (scanning) and runtime (emulation-based) techniques are used.*
+## False-Positives
+It is important for the antivirus not to flag uninfected files as infected
+- For the trust of the user
+- To avoid damaging the systems they run on.
+
+For example in May 2007 Norton/Symantec mistakenly removed essential OS system files, bricking thousands of PCs.
+
+(Also May 2007) Norton/Symantec falsely detected an executable required for PegasusMail as a Trojan, this included 3 releases of the software.
+
+> *"On the basis that Norton/Symantec has done this for every one of the last three releases of Pegasus Mail, we can only condemn this product as too flawed to use, and recommend in the strongest terms that our users cease using it in favor of alternative, less buggy anti-virus packages"*
+> **- PegasusMail**
+
+Users losing the minds here:
+- PegasusMail falsely detected as a trojan: [How to contact Symantec?? | PMAIL COMMUNITY](https://community.pmail.com/index.php?u=/topic/273/how-to-contact-symantec)
+- Automatic Driver Update bricking motherboards: [Norton 360 killed my pc after update | Norton Community](https://community.norton.com/en/forums/norton-360-killed-my-pc-after-update)
+Many other issues have occurred with AntiViruses removing system critical files.