P1:L2 Software Security

Question 1

Buffer (or memory) Overflow

Answer 1

A common and persistent vulnerability

In information security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer’s boundary and overwrites adjacent memory locations.

Question 2

Stack buffer overflows

Answer 2

In software, a stack buffer overflow or stack buffer overrun occurs when a program writes to a memory address on the program’s call stack outside of the intended data structure, which is usually a fixed-length buffer.

Question 3

stacks are used

Answer 3

• In function/procedure calls
• for allocation of memory for
  
  • local variables
  • parameters
  • control information (return address)

Question 4

Vulnerable password checking program

Answer 4

Not good to hardcode password in code

Question 5

Push and pop

Answer 5

Push = Stack grows
Pop = Stack shrinks

Question 6

Password check code quiz

Answer 6

Too much data gets stored in the variable for int
Remember memory (or buffer) overflow

So… variable could possible be different from 0

Bad input caused a manipulation

Question 7

Which vulnerability applied to the code in example quiz?

Answer 7

The code did not check the input and reject password strings longer than 12 bytes.

Question 8

Creates a shell which allows it to execute any code the attacker wants

Answer 8

Shell Code

Question 9

ShellCode

Answer 9

Has to be stored in memory… instructions… assembler language.. translated into machine code.

Question 10

Whose privileges are used when attacker code is executed?

Answer 10

• The host program’s
• System service or OS root privileges

“Keys to the kingdom”

Question 11

How many CVE vulnerabilities does NVD have?
NVD = National Vulnerability Database
CVE = Common Vulnerability and Exposure)

Answer 11

Close to 70,000

Question 12

How many buffer overflow vulnerabilities reported in the last 3 months

Answer 12

Close to one hundred

Question 13

How many buffer overflow vulnerabilities in last 3 years?

Answer 13

Over a thousand

Question 14

The return address is overwritten to point to a standard library function

Answer 14

Return-to-libc (write type)

This is a type of Buffer Overflow (a variation of)

Question 15

Data stored in the heap is overwritten. Data can be tables of function pointers.

Answer 15

Heap Overflows (write type)
(another variation of Buffer Overflow)

Question 16

Read much more of the buffer than just the data, which may include sensitive data

Answer 16

OpenSSL Heartbleed Vulnerability - a read-only overflow vulnerability which is dangerous if sensitive data is exposed.
(once again, another type of Buffer Overflow)

Question 17

Good defenses against Buffer Overflow Attacks

Answer 17

*Programming language is crucial
The language should be....
     *strongly typed
     *automatic bound checks
     *Automatic memory management

Question 18

Examples of “Safe languages”

Answer 18

Java, C++

OO languages make the problems above go away

Question 19

Why are some languages safe?

Answer 19

Buffer overflow becomes impossible due to runtime system checks

Question 20

What are drawbacks of secure languages?

Answer 20

Possible performance degradation

Question 21

What if you are stuck with language that does not auto check? Usage language that does not prevent buffer overflows?

Answer 21

• Check input (ALL input is EVIL!)
• Use safer functions that do “bounds checking”
• Use automatic tools to analyze code for potential unsafe functions.

Question 22

Strongly or Weakly typed?

Any attempt to pass data of incompatible type is caught at compile time or generates an error at runtime.

Answer 22

Strongly

Question 23

Strongly or Weakly typed?

An array index operation b[k] may be allowed even though k is outside the range of the array.

Answer 23

Weakly

Question 24

Strongly or Weakly typed?

It is impossible to do “pointer arithmetic” to access arbitrary area of memory.

Answer 24

Strongly

Question 25

Analysis tools...

Answer 25

* Can flag potential unsafe functions/constructs | * Can help mitigate security lapses, but it is really hard to eliminate all buffer overflows

Question 26

Stack canaries

Answer 26

When a return address is stored in a stack frame, a canary value is written just before it. Any attempt to rewrite the address using buffer overflow will result in the canary being rewritten and an overflow will be detected.

Question 27

ASLR | Address Space Layout Randomization

Answer 27

Randomizes stack, heap, libc, etc... This makes it harder for the attacker to find important locations (e.g. libc function address)

Question 28

Non-executable stack

Answer 28

Can be used with ASLR - This solution uses OS/harwdare support.

Question 29

Do stack canaries prevent return-to-libc buffer overflow attacks

Answer 29

Yes | Relies on re-writing return address... the canary will detect to see if the return-stack is modified

Question 30

Does ASLR protect against read-only buffer overflow attacks

Answer 30

No | Makes it harder to guess where certain variables are... but does not prevent 100%

Question 31

Can the OpenSSL geartbleed vulnerability be avoided with non-executable stack?

Answer 31

No | A read-only overflow: Doesn't need to execute... only needs to read.