C Security Quiz (Short Version)

1. Which of the following is true with respect to buffer overflows?

Buffer overflows on the heap cannot be exploited to run arbitrary code.

Buffer overflows can be used to alter the state and operation of the vulnerable application in an undetectable way.

a]NO; heap-based buffer overflows are significantly harder to exploit, but they can still be used to run arbitrary code.
b]NO; in most cases, the attacker can put extremely long input – several hundred kilobytes of data, or even more – in the fixed-size buffer. Increasing the buffer size will only allow the attacker to inject longer shellcode in most cases.
c]YES; e.g. if the attacker only overwrites local variables on the stack.
d]NO; there are several techniques to avoid DEP and similar techniques, such as return-to-libc attacks and return-oriented programming.
e]NO; in the right circumstances, a double free can lead to a buffer overflow on the heap.

Explanation

a]NO; heap-based buffer overflows are significantly harder to exploit, but they can still be used to run arbitrary code.
b]NO; in most cases, the attacker can put extremely long input – several hundred kilobytes of data, or even more – in the fixed-size buffer. Increasing the buffer size will only allow the attacker to inject longer shellcode in most cases.
c]YES; e.g. if the attacker only overwrites local variables on the stack.
d]NO; there are several techniques to avoid DEP and similar techniques, such as return-to-libc attacks and return-oriented programming.
e]NO; in the right circumstances, a double free can lead to a buffer overflow on the heap.

2. Which of the following statements (in the area of protection against typical C/C++ vulnerabilities) is true?

There is no reliable way to protect against format string vulnerabilities.

Injected shellcode can be reliably identified by intrusion detection software.

Proper use of secure integer libraries eliminates integer overflow vulnerabilities.

Using strncpy and strncat instead of strcpy and strcat guarantees error-free operation.

a] NO; format string vulnerabilities are trivially avoided by e.g. #define printf(str) printf("%s",str)
b] NO; shellcode can be obfuscated, encrypted, or even masquerade as alphanumeric text.
c] YES; secure integer libraries either prevent overflows altogether or throw errors when an overflow is encountered.
d] NO; heap spraying, return-oriented programming, return-to-libc and similar techniques can be used to bypass these protections.
e] NO; strncpy/strncat do not add a trailing zero if the 'num' parameter specifying the number of characters to copy is greater than the length of source string. This can lead to a buffer overflow later when the string is read out.

Explanation

a] NO; format string vulnerabilities are trivially avoided by e.g. #define printf(str) printf("%s",str)
b] NO; shellcode can be obfuscated, encrypted, or even masquerade as alphanumeric text.
c] YES; secure integer libraries either prevent overflows altogether or throw errors when an overflow is encountered.
d] NO; heap spraying, return-oriented programming, return-to-libc and similar techniques can be used to bypass these protections.
e] NO; strncpy/strncat do not add a trailing zero if the 'num' parameter specifying the number of characters to copy is greater than the length of source string. This can lead to a buffer overflow later when the string is read out.

3. This function is part of a program that is running on a 32-bit x86 system; the compiler does not change the order of variables on the stack. void function(char *input) { int i = 1; char buffer[8]; int j = 2; strcpy(buffer,input); printf("%x %x %s\n",i,j,buffer); } What is the minimum length of a string – passed to the function through the input parameter – that can crash the application?

9

10

11

12

13

12 characters. Since the string is zero-terminated, it will be stored in a 13-byte array that is copied over the buffer, and the first byte of the EBP will be overwritten - causing the program to crash.

Explanation

12 characters. Since the string is zero-terminated, it will be stored in a 13-byte array that is copied over the buffer, and the first byte of the EBP will be overwritten - causing the program to crash.

4. When dealing with Unicode user input in C, the following issues need to be taken into account:

Unicode characters may be used to bypass black-list filtering

In every encoding form, the size of Unicode characters may differ from each other

The length() of a Unicode string may be different from its size()

Unicode strings cannot be printed easily out on the screen

Directional control characters such as U+202E may be exploited

a]YES; filtering may use a different Unicode conversation routine than the called function.
b]YES; the character representation length varies for different characters in UTF-8 encoding form.
c]YES; depending on the Unicode encoding being used, size may be up to 4x larger than length.
d]NO; every function has an Unicode pair, for example you can use wprintf instead of printf.
e]YES; if the user-provided string is concatenated with UI elements, it may be used to reverse built-in UI element text.

Explanation

a]YES; filtering may use a different Unicode conversation routine than the called function.
b]YES; the character representation length varies for different characters in UTF-8 encoding form.
c]YES; depending on the Unicode encoding being used, size may be up to 4x larger than length.
d]NO; every function has an Unicode pair, for example you can use wprintf instead of printf.
e]YES; if the user-provided string is concatenated with UI elements, it may be used to reverse built-in UI element text.

Submit

5. #define ll 12 char pwd[37], n[ll]; void s(char *u) {strncpy(n,u,ll); printf(n);} How would you fix the code above?

Char pwd[37], n[ll+1];

#define ll 13

Void s(char *u) {strncpy(n,u,ll-1); printf(n);}

Void s(char *u) {strncpy(n,u,11); printf(“%s”, n);}

Void s(char *u) {strncpy(n,u,ll-1); cout

a]NO; this fixes the off-by-one error in the strncpy, but does not fix the printf vulnerability
b]NO; neither of the bugs is fixed in this way, just increases the string’s size by one
c]NO; this fixes the off-by-one error in the strncpy, but does not fix the printf vulnerability
d]YES; both the off-by-one error and the printf vulnerability are fixed, but hard-coding the number of characters to be copied may cause problems in the future
e]YES; both the off-by-one error and the printf vulnerability are fixed

Explanation

a]NO; this fixes the off-by-one error in the strncpy, but does not fix the printf vulnerability
b]NO; neither of the bugs is fixed in this way, just increases the string’s size by one
c]NO; this fixes the off-by-one error in the strncpy, but does not fix the printf vulnerability
d]YES; both the off-by-one error and the printf vulnerability are fixed, but hard-coding the number of characters to be copied may cause problems in the future
e]YES; both the off-by-one error and the printf vulnerability are fixed

Submit