diff options
| -rw-r--r-- | en_GB/Introduction to Information Security/introduction_to_information_security.md | 44 |
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. |