notes/docs/lectures/security/10_exploits.md

Exploits

• The easiest way of getting access to a machine is having the user install something for you
• A software or hardware bug that allows an attacker to circumvent an OS’ security perimeter

Memory Management

• In C and C++, the programmer performs memory management
• Flexible, powerful, fast but dangerous
  • Buffer Overruns
  • Stack Overruns
  • Heap Overruns
• Memory-managed languages avoid this, but of course may have their own vulnerabilities

Buffer Overflows

• When a program is executed, contiguous blocks of memory can be allocated to store arrays (buffers)
• If data is written into a buffer that exceeds its size, an overflow occurs
• The data will overwrite the memory beyond the buffer

Program Memory

• Memory is stored in virtual address space from 0x0000... to 0xFFFF...
• Parts of the program are held in different regions by convention
• Different restrictions are placed on these regions

The Stack

The stack holds information on local variables and function calls (stack frames)

1. A function call will push a new frame onto the stack
2. A return will pop it off, and go to ret

void function(int a, int b, int c)
{
    char buffer1[5];
    char buffer2[10];
}

void main()
{
    function(1,2,3);
}

Stack Smashing

• In C and C++, low level functions like strcpy perform no bounds checking at all
  • This is partly due to the fact strings are null terminated, if we provide no null character strcpy will continue to run
• If str is long, we can write into other memory

void function(char *str)
{
    // allocate local buffer
    char buffer[128];
    // Copy str into local buffer
    strcpy(buffer, str);
}

Stack Canaries

• Stack canaries modify the prologue and epilogue of all functions to check a value ion front of the return address is unchanged

• If you can work out the canary value, there is no issue

Data Execution Prevention (NX)

• Modern operating systems will mark the stack as non-executable
  • NX on AMD, XD on Intel and XN on arm
• An NX stack means that adding in our exploit code won’t work
• We can circumvent this using a return-to-libc attack

Further Protection

• To defeat ret2lib2 various 0x0 null bytes are inserted into standard library addresses
• Developers also restrict access to obvious system calls
• Address Space Layout Randomisation (ASLR) moves the address of library and programs around
  • They don’t have to move too much before your hand-crafted ret addresses will break

Return-Oriented Programming

• Lets forget about injecting code, how about just using existing code in the actual exploitable program
• No individual section of this program will do what we want
• Find short sections, gadgets and link them together

Race Conditions

• With concurrent threads or processes, timing can lead to security vulnerabilities

• Here the victim unknowingly modifies the wrong file
• This can happen because the CPU context switches and can execute these two processes simultaneously
• Running this continuously for about 10 minutes, this will work once

Heartbleed

• Heartbleed is a bug in OpenSSL
  • Open source SSL library
  • Started in OpenBSD
  • Used almost everywhere
• Specifically targeted the heartbeat extension
  • Extension to regular SSL and used for keep-alive purposes, to stop quiet connections being closed
    • Client sends a message to the server to say it’s alive
    • Server responds (also alive)

The Bug

buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;

/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, p1, payload); //BAD
bp += payload;

/* Random padding */
RAND_pseudo_bytes(bp, padding);

r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload +
padding);
if (r >= 0 && s->msg_callback)
	s->msg_callback(1, s->version, TLS1_RT_HEARTBEAT,
		buffer, 3 + payload + padding,
		s, s->msg_callback_arg);

This bug would just memcpy a bunch of the server’s ram and send it back to the client. This can expose RSA keys.

This is called a buffer overread attack.