IntroSec

Added software security contents.

1 files changed, 42 insertions, 2 deletions

diff --git a/en_GB/Introduction to Information Security/introduction_to_information_security.md b/en_GB/Introduction to Information Security/introduction_to_information_security.md
index 434ace8..fbdd9ad 100644
--- a/en_GB/Introduction to Information Security/introduction_to_information_security.md
+++ b/en_GB/Introduction to Information Security/introduction_to_information_security.md
@@ -245,7 +245,7 @@ and not somebody you think is the receiver (receiving machine being used by many
 1. Sender and receiver share a common secret key *k*.
 2. Sender computes $\text{MAC}_\text{sent} = \text{h}(\text{k}, \text{x})$, *h* being a one-way-function, *x* being the message.
 3. Sender sends message *x* with $\text{MAC}_\text{sent}$.
-4. Receiver receives the message and $\text{MAC}_\text{sent}$ and $\text{MAC}_\text{received} = \text{h}(\text{k}, \text{x'})$ with *x'* being the received message.
+4. Receiver receives the message and $\text{MAC}_\text{sent}$ and calculates $\text{MAC}_\text{received} = \text{h}(\text{k}, \text{x'})$ with *x'* being the received message.
 5. Receiver compares $\text{MAC}_\text{sent}$ and $\text{MAC}_\text{received}$. If they match, the message is considered not modified.
 
 ### Digital Signatures
@@ -346,7 +346,7 @@ Infrastructure providing the service of public key distribution.
 
 ### Side Channel Analysis
 
-*Side Channel Analysis* focuses on analyzing unintended *side-channels*, which might not have respected enough in security design.  
+*Side Channel Analysis* focuses on analyzing unintended *side-channels*, which might not have been respected enough in security design.  
 *Side-channels* are all communication channels not used for main communication.
 In many embedded devices, IO pins are the main channel of communication. Any other channel is a *side-channel*.  
 The attack focus moves from the logical layer (algorithms) to the physical layer (time, power etc.).
@@ -383,6 +383,14 @@ The password is `IntroSec`.
    so it is likely that there is no new correct char.
 4. The attacker continues, learning char by char for each processing time increase, until he got the full password.
 
+## Software Security
+
+### Buffers
+
+Logically, values are assigned to variables.
+In reality, for every variable, a portion of memory on the call stack gets allocated (*buffer*), and the data gets written to that buffer.
+Data written to the buffer is written upwards from the address allocated to the buffer.
+
 ## Threat scenarios
 
 No security issues without threat models! E.g. a password is considered safe without any provided threat model.
@@ -439,3 +447,35 @@ Victim enters his password and the attacker captures the data forwarded by the f
 - Picking random, hard to guess SIDs
 - Storing cookies in a safe place
 - Include a MAC with the SID to check for integrity
+
+### Buffer Overflow
+
+If the size of the data to be written to the buffer is larger than the size of the memory allocated to that buffer,
+the upper buffer limit gets exceeded. If additionally those limits are not checked, memory not assigned to the buffer
+gets overwritten.
+
+1. Attacker knows that there is a buffer with 80 bytes allocated.
+2. Attacker invokes the function writing to the buffer, with shellcode beginning from byte 80 in the data array.
+3. This shellcode overwrites the return address of the current stack function in that program.
+4. As soon as the program exits its function, it executes the attackers shellcode *with this programs privileges*.
+
+#### Examples of vulnerable functions
+
+##### strcpy
+
+```C
+char *strcpy(char *destination, const char *source );
+```
+
+`strcpy(...)` works with `NULL` terminated strings as `destination` and `source`.
+If `destination` is not `NULL` terminated, the behaviour of this function is undefined and might cause a buffer overflow
+and overrides in wrong memory.
+
+#### Defences
+
+- Check size of data input and compare to actual allocated buffer size.
+- Use functions requiring explicit size definition.
+- Check for integer overflows.
+- Protect return address using *canaries*.
+  Special instructions placed before actually returning to check for correct return address.
+- Mark potential shellcode memory as non-executable.