Added last two CS lessons

Computer Security/lesson_07.md

@@ -0,0 +1,77 @@
+# Computer Security - lesson 7
+#### Stefano Zanero
+###### 14 April 2016
+## ASM function call
+ESP and EBP registers delimit the current location of the stack,
+they point to the *frame of activation*
+The `call` intruction saves the current EIP on the stack,
+The equivalent instructions to `call 0x8048484 <foo>` are:
+```
+push %eip
+jmp 0x8048484 ~foo()
+```
+The difference with the sole call of `jmp` is that the call saves
+the current state of EIP to return to it later.
+After the jump the stack allocation is done:
+- Save the EBP on the stack
+- Set the net EBP to current ESP
+- Allocate space on the stack incrementing ESP
+```
+push %ebp
+mov %esp, %ebp
+sub %0x4, %esp
+```
+To view this result I should disable the optimization with `-O0`
+and `-preferred-stack-boundary=2` turning off some optimization
+that store multiple (short) variables per stack word.
+Before the function return, the return value is moved into EAX
+The return from function is made with the `leave` op
+```
+mov %ebp, %esp
+pop %ebp
+ret
+```
+That deallocates the current stack, and the `ret` op pops the last value
+on the stack to EIP to restore it.
+
+## Stack Smashing
+Suggested reading: `Smashing the stack for fun and profit`
+This works in C because it doesn't do memory management for you
+like Python or Java
+If we have a code like this
+```
+char buf[8];
+gets(buf);
+```
+And we input during execution a sequence longer than 8
+we get a *segmentation fault*
+That is actually raised by the `jmp` op trying to jump to 
+a meaningless position in memory, since we overwritten EIP
+that was stored on the stack, by growing the heap.
+Maybe it would have been enough to overwrite the return value 
+wothout overwriting EBP and EIP, and that is another
+security vulnerability itself.
+
+To jump to any function i would need to setup the parameters correctly
+on the stack.
+I can also jump into a function of a library loaded into memory
+This is called __return to library__ or in particular __return to libc__.
+Also the environment variable loaded with a program are stored on
+top of the stack always in the same place, so i can put code in there
+and jump to it.
+Requirement for stack smashing:
+- The size of the buffer is not checked
+- Overflowed buffer has enough room for code
+Also we need to know at what address the stack is
+
+### Get the address of the stack
+We can use a debugger to stop the execution before the vulnerability
+and get the address of memory where ESP is stored
+On our own machine i can use a code to print to screen the position of ESP 
+(see slides)
+The debugger method is not so reliable because some debuggers like gdb add
+an offset to allocated memory.
+We can reduce the need of precision filling the heap area with `nop`
+forming a *nop sled* that make the processor go through to the right exploit code.
+This is a measure to make the exploit work reliably on remote machines,
+ans this is part of __weaponizing__ an explloit

Computer Security/lesson_08.md

@@ -0,0 +1,62 @@
+# Computer Security - lesson 8
+#### Stefano Zanero
+###### 15 April 2016
+## Stack smashing pt. 2
+We have now established that we can jump (modifying EIP) to any point in memory.
+We may want to jump to a function in our program, or a function in a library
+included in our program.
+For jumping inside a function we will need to prepare the parameters
+on the stack for the function to execute properly.
+```
+unsigned long get_sp(void) {
+   __asm__("movl %esp,%eax");
+} // content of %eax is returned
+
+void main() {
+   printf("0x%x\n", get_sp());
+}
+```
+With this code we can have the ESP of the get_sp function that will 
+be similar to the main one,
+In general __it is difficult__ to get the actual value of ESP,
+but we can make a good guess about it.
+The __NOPsled__ technique can help if we do not know precisely where our code 
+will be placed
+
+### What to execute now?
+The hystorical objectiva was to spawn a privileged shell
+runnign a so called __shellcode__
+In linux we could use a command like `execve`
+For launching the needed system call we need to fire an interrupt.
+ex: we use an `int` op with code `0x80`
+The parameters we will need to pass to `execve` are the following:
+- First parameter: "/bin/sh"
+- Second parameter: NULL, represent environment variables.
+
+If we disassemble the function `__execve` we know that
+the function pass the parameters through the registers and then
+calls `int 0x80`
+```
+movl $0xb,%eax
+movl 0x8(%ebp),%ebx
+movl 0xc(%ebp),%ecx
+movl 0x10(%ebp),%edx
+int  $0x80
+```
+Then we could use this code for our shellcode
+The problem is that we need to have the address of the string for `argv[0]`
+to pass it as parameter.
+But now we have already the possibility of running code, 
+so we can get the machine will in the address on its own.
+The trick used is *jump and call*
+For which we use the `jmp` op with the offset to `call` function
+the call function jumps again to the second instruction (pop)
+Then we pop the ADDRESS from stack to ESI register,
+then we have the ADDRESS to use to build the parameters for the `execve`
+
+The 0 bytes in the assembly code create problems with screen operations,
+to avoid this we can use the `jmp short` instruction instead of `jmp`
+The problem with 0 is that since we use C string functions to manipulate
+our exploit code, the function may terminate the string when they find 
+a NULL byte (0x00 or /0), that usually terminates strings.
+