1. Computer Security 3e
Dieter Gollmann

2. Chapter 10: Software Security

3. Secure Software
Software is secure if it can handle intentionally malformed input; the attacker picks (the probability distribution of) the inputs.
Secure software: Protect the integrity of the runtime system.
Secure software ≠ software with security features.
Networking software is a popular target:
Intended to receive external input.
May construct instructions dynamically from input.
May involve low level manipulations of buffers.

4. Security & Reliability
Reliability deals with accidental failures: Failures are assumed to occur according to some given probability distribution.
The probabilities for failures is given first, then the protection mechanisms are constructed.
To make software more reliable, it is tested against typical usage patterns: “It does not matter how many bugs there are, it matters how often they are triggered”.

5. Security & Reliability
In security, the defender has to move first; the attacker picks inputs to exploit weak defences.
To make software more secure, it has to be tested against “untypical” usage patterns (but there are typical attack patterns).
On a PC, you are in control of the software components sending inputs to each other.
On the Internet, hostile parties can provide input: Do not “trust” your inputs.

6. Agenda Malware Dangers of abstraction Input validation Integers
Buffer overflows
Scripting languages
Race conditions
Defences: Prevention – Detection – Reaction

7. Malware Malware: software that has a malicious purpose.
Computer virus: self-replicating code attached to some other piece of code; a virus infects a program by inserting itself into the program code.
Worm: replicating but not infecting program; most reported virus attacks would be better described as worm attacks.
Trojan horse: program with hidden side effects, not intended by the user executing the program.
Logic bomb: program that is only executed when a specific trigger condition is met.

8. Preliminaries
When writing code, programmers use elementary concepts like character, variable, array, integer, data & program, address (resource locator), atomic transaction, …
These concepts have abstract meanings.
For example, integers are an infinite set with operations ‘add’, ‘multiply’, ‘less or equal’, …
To execute a program, we need concrete implementations of these concepts.

9. Benefits of Abstraction
Abstraction (hiding ‘unnecessary’ detail) is an extremely valuable method for understanding complex systems.
We don’t have to know the inner details of a computer to be able to use it.
We can write software using high level languages and graphical methods.
Anthropomorphic images explain what computers do (send mail, sign document).

10. Dangers of Abstraction
Software security problems typically arise when concrete implementation and the abstract intuition diverge.
We will explore a few examples:
Address (location)
Character
Integer
Variable (buffer overflows)
Double-linked list
Atomic transaction

11. Input Validation
An application wants to give users access only to files in directory A/B/C/.
Users enter filename as input; full file name constructed as A/B/C/input.
Attack: use ../ a few times to step up to root directory first; e.g. get password file with input /../../../../etc/passwd.
Countermeasure: input validation, filter out ../ (but as you will see in a moment, life is not that easy).
Do not trust your inputs.

12. Unicode Characters UTF-8 encoding of Unicode characters [RFC 2279]
Multi-byte UTF-8 formats: a character has more than one representation
Example: “/”
format binary hex
1 byte 0xxx xxxx F
2 byte 110x xxxx C xx xxxx AF
3 byte 1110 xxxx E xx xxxx xx xxxx AF

13. Exploit “Unicode bug”
Vulnerability in Microsoft IIS; URL starting with {IPaddress}/scripts/..%c0%af../winnt/system32/
Translated to directory C:\winnt\system32
The /scripts/ directory is usually C:\inetpub\scripts
Because %c0%af is the 2 byte UTF-8 encoding of /
..%c0%af../ becomes ../../
../../ steps up two levels in the directory
IIS did not filter illegal Unicode representations using multi-byte UTF-8 formats for single byte characters.

14. Double Decode
Consider URL starting with {addr.}/scripts/..%25%32%66../winnt/system32/
This URL is decoded to {addr.}/scripts/..%2f../winnt/system32/
Convert %25%32%66 to Unicode:  %2f ( = /)
If the URL is decoded a second time, it gets translated to directory C:\winnt\system32
Beware of mistranslations (between levels of abstraction) that change the meaning of texts.
The URL may be passed to a second application that does not trust the first

15. Unix rlogin Unix login command: Unix rlogin command for remote login:
login [[-p] [-h<host>] [[-f]<user>]
-f option “forces” log in: user is not asked for password
Unix rlogin command for remote login:
rlogin [-l<user>] <machine>
The rlogin daemon sends a login request for <user> to <machine>
Attack (some versions of Linux, AIX):
% rlogin -l -froot <machine>
Results in forced login as root at the designated machine
% login -froot <machine>

16. Unix rlogin Problem: Composition of two commands.
Each command on its own is not vulnerable.
However, rlogin does not check whether the “username” has special properties when passed to login.

17. Programming with Integers
In mathematics integers form an infinite set.
On a computer systems, integers are represented in binary.
The representation of an integer is a binary string of fixed length (precision), so there is only a finite number of “integers”.
Programming languages: signed & unsigned integers, short & long (& long long) integers, …

18. What will happen here?
int i = 1;
while (i > 0) {
i = i * 2; }

19. Computing with Integers
Unsigned 8-bit integers
=  17 = 16
0 – 1 = 255
Signed 8-bit integers
= /-1 = -1
In mathematics: a + b  a for b  0
As you can see, such obvious “facts” are no longer true.

20. Two’s Complement
Signed integers are usually represented as 2’s complement numbers.
Most significant bit (sign bit) indicates the sign of the integer:
If sign bit is zero, the number is positive.
If sign bit is one, the number is negative.
Positive numbers given in normal binary representation.
Negative numbers are represented as the binary number that when added to a positive number of the same magnitude equals zero.

21. strncat will be executed
Code Example 2
OS kernel system-call handler; checks string lengths to defend against buffer overruns.
len1 < sizeof(buf)
char buf[128];
combine(char *s1, size_t len1,
char *s2, size_t len2) {
if (len1 + len2 + 1 <= sizeof(buf)) {
strncpy(buf, s1, len1);
strncat(buf, s2, len2); }
len2 = 0xffffffff
len2 + 1 =
= 0 mod 232
strncat will be executed
Example from Markus Kuhn’s lecture notes

22. Array
You are given an array starting at memory location 0xBBBB (on a 16-bit machine)
Array elements are single words.
Which index do you write to so that memory location 0x8000 is overwritten?
You also must check lower bounds for array indices.
0xBBBB
base
48059
0xC445
-15291
-0xCCCC: flip bits: 0x4444, add 1: 0x4445; 0x x4445 = 0xC445
0x8000
32768

23. Canonicalization
Canonicalization: the process that determines how various equivalent forms of a name are resolved to a single standard name.
The single standard name is also known as the canonical name.
In general, an issue whenever an object has different but equivalent representations;
Example: XML documents
Canonicalization must be idempotent.

24. Napster File Filtering
Napster was ordered by court to block access to certain songs.
Napster implemented a filter that blocked downloads based on the name of the song.
Napster users found a way around by using variations of the name of songs.
This is a particularly difficult problem because the users decide which names are equivalent.

25. Case-sensitive? Security mechanism is case sensitive:
MYFILE is different from MyFile
File system is case-insensitive:
MYFILE is the same as MyFile
Permissions are defined for one version of the name only:
Attacker requests access to another version.
The security mechanism grants the request.
The file system gives access to the resource that should have been protected.
Vulnerability in Apache web server with HFS+

26. Directory Traversal
An application may try to keep users in a specific directory.
Attack: walk out of the directory using ../; attack may try to hide “..” by using alternative UTF-8 encodings.
Relative file names: system starts from a list of predefined directories to look for the file.
Attack: put malicious code in a directory that is searched before the directory used by the application being attacked.
Don’t filter for patterns, filter for results.

27. Memory configuration stack
heap
memory
0000
FFFF
Stack: contains return address, local variables and function arguments; relatively easy to decide in advance where a particular buffer will be placed on the stack.
Heap: dynamically allocated memory; more difficult but not impossible to decide in advance where a particular buffer will be placed on the heap.

28. Variables Buffer: concrete implementation of a variable.
If the value assigned to a variable exceeds the size of the allocated buffer, memory locations not allocated to this variable are overwritten.
If the memory location overwritten had been allocated to some other variable, the value of that other variable is changed.
Depending on circumstances, an attacker can change the value of a sensitive variable A by assigning a deliberately malformed value to some other variable B.

29. Buffer Overruns
Unintentional buffer overruns crash software, and have been a focus for reliability testing.
Intentional buffer overruns are a concern if an attacker can modify security relevant data.
Attractive targets are return addresses (specify the next piece of code to be executed) and security settings.
In languages like C or C++ the programmer allocates and de-allocates memory.
Type-safe languages like Java guarantee that memory management is ‘error-free’.

30. Buffer Overrun (1980s)
Login in one version of Digital’s VMS operating system: to log in to a particular machine, enter
username/DEVICE =<machine>
The length of the argument ‘machine’ was not checked; a device name of more than 132 bytes overwrote the privilege mask of the process started by login; users could thus set their own privileges.

31. System Stack
Function call: stack frame containing function arguments, return address, statically allocated buffers pushed on the stack.
When the call returns, execution continues at the return address specified.
Stack usually starts at the top of memory and grows downwards.
Layout of stack frames is reasonably predictable.

32. Stack Frame – Layout argument n.
argument 1
local
variables
saved EBP
saved EIP
extended instruction pointer (return address)
extended base pointer
(reference point for relative addressing)
a.k.a. frame pointer

33. Stack-based Overflows
Find a buffer on the runtime stack of a privileged program that can overflow the return address.
Overwrite the return address with the start address of the code you want to execute.
Your code is now privileged too.
value1
my_address
value2
return
address
write to A:
value1|
value2|
my_address
buffer for
variable A

34. Code Example Declare a local short string variable char buffer[80];
use the standard C library routine call
gets(buffer);
to read a single text line from standard input and save it into buffer.
Works fine for normal-length lines, but corrupts the stack if the input is longer than 79 characters.
Attacker loads malicious code into buffer and redirects return address to start of attack code.

35. Shellcode
Overwrite return address so that execution jumps to the attack code (‘shellcode’).
Where to put the shellcode?
Shellcode may be put on the stack as part of the malicious input; a.k.a. argv[]-method.
To guess the location, guess distance between return address and address of the input containing the shellcode.
Details e.g. in Smashing the Stack for Fun and Profit.
return-to-libc method: attack calls system library; change to control flow, but no shellcode inserted.

36. Heap Overruns
More difficult to determine how to overwrite a specific buffer.
More difficult to determine which other buffers will be overwritten in the process; if you are an attacker, you may not want to crash the system before you have taken over.
Even attacks that do not succeed all the time are a threat.
Can overwrite filenames and function pointers, and mess up memory management.

37. Memory Allocation

38. Overwriting Pointers
Modify return address with buffer overrun on stack.
Attacker can fairly easily guess the location of this pointer relative to a vulnerable buffer.
Defender knows which target to protect.
More powerful attack: overwrite arbitrary pointer with an arbitrary value.
More targets, hence more difficult to defend against.
Attacker does not even have to overwrite the pointer!
Attacker can lure the operating system into reading malformed input and then do the job for the attacker.

39. Managing Memory in C Allocating memory: Deallocating memory:
void * malloc (size_t size)
Returns pointer to newly allocated block of size bytes.
Contents of the block are not initialized.
Returns null pointer if block cannot be allocated.
Deallocating memory:
void free (void *ptr)
*ptr must have been returned by a previous call to malloc(), calloc()or realloc().
If ptr is null, no operation is performed.
Behaviour undefined if free(ptr) has already been called.

40. Memory Organization Case study: Doug Lea malloc.
Memory divided into chunks.
A chunk contains user data and control data.
Chunks allocated by malloc contain boundary tags.
Free chunks are placed in bins; a bin is a double linked lists.
Several bins, for chunks of different sizes.
Free chunks contain boundary tags and forward and backward pointer to their neighbours in the bin.

41. Allocated and Free Chunks
previously used for data
prev_size
size
user data
allocated
chunk
prev_size fd
size
PREV_INUSE
unused bk
free chunk
size of chunk
offset 4
offset 8
offset 12
size of previous chunk

42. Control Flags Values for size always given in multiples of 8.
Three last bits of size may be used for control flags:
PREV_INUSE 0x1
IS_MAPPED 0x2
Some libraries also use the third bit.
When a chunk is freed it is coalesced into a single chunk with neighbouring free chunks.
No adjacent free chunks in memory.
Technicality: prev_size not used when the previous chunk is allocated.

43. Coalescing Chunks size C 0x0 PREV_INUSE = 0 so merge chunks A and B
and remove B from bin
user
data
chunk C
allocated
size C 0x0
prev_size
unused
go to next chunk using
size as offset and
check PREV_INUSE bk
chunk B
free fd
size B 0x1
prev_size
go to next chunk
using size as offset
user
data
chunk A
to be freed
size A
prev_size

44. Managing a Bin
Bin: double-linked lists of free chunks, ordered by increasing size to facilitate fast smallest-first search.
To allocate a buffer, take a suitable block from the list using unlink().
When a block is freed, it is inserted in this list using frontlink().
Search in reverse order? B1 B4 B3 B2

45. Frontlink() – Simplified
#define frontlink(A, P, S, IDX, BK, FD)
...
[1] FD = start_of_bin(IDX);
[2] while ( FD != BK && S < chunksize(FD) ) {
[3] FD = FD->fd; }
[4] BK = FD->bk;
[5] P->bk = BK;
[6] P->fd = FD;
[7] FD->bk = BK->fd = P;

46. Frontlink() Macro
Store chunk of size S, pointed to by P, at appropriate position in the double linked list of bin with index IDX.
[1] FD initialized with a pointer to the start of the list of the given bin.
[2] Loop searches the double linked list to find first chunk smaller than P or the end of the list by following consecutive forward pointers (line [3]).
[4] Follow back pointer BK to previous element in list.
[5]+[6] Set backward and forward pointers for chunk.
[7] Update backward pointer of next chunk and forward pointer of previous chunk to address of chunk P (field fd at 8 byte offset within a boundary tag).

47. Unlink #define unlink(P, BK, FD) { [1] FD = P->fd;
[2] BK = P->bk;
[3] FD->bk = BK;
[4] BK->fd = FD; }
Save pointers in chunk P to FD and BK.
Update backward pointer of next chunk in the list: address located at FD plus 12 bytes (offset of bk field in boundary tag) overwritten with value stored in BK.
Update forward pointer of previous chunk in the list.

48. Mental Exercise
What will happen if we free a chunk that has already been freed?
Add a chunk B3’ into the following list.
Then add it again B1 B4 B3 B2

49. Insert chunk B’ before B3
Assume loop terminates with FD equal to B3
[4] BK = FD->bk; BK = B2;
[5] P->bk = BK; B’->bk = B2;
[6] P->fd = FD; B’->fd = B3;
[7] FD->bk = BK->fd = P;
B3->bk = B2->fd = B’; B1 B3 B’ B2

50. Insert chunk B’ again B1 B3 B’ B2 Loop ends with FD equals to B’
[4] BK = FD->bk; BK = B2;
[5] P->bk = BK; B’->bk = B2;
[6] P->fd = FD; B’->fd = B’;
[7] FD->bk = BK->fd = P; B’->bk = B2->fd = B’; B1 B3 B’ B2

51. Unlink double-free’d chunk B’
[1] FD = P->fd; FD = B’->fd = B’
[2] BK = P->bk; BK = B’->bk = B’
[3] FD->bk = BK; FD->bk = B’->bk = B’
[4] BK->fd = FD; BK->fd = B’->fd = B’
Nothing changes: the chunk removed from the list of free chunks is still on the list! B1 B2 B’ B3

52. Double-free vulnerabilities
Double Free Bug in zlib Compression Library (v1.1.3)
CERT® Advisory CA

53. Double-free Allocate memory chunk A.
Call free(A), with forward or backward consolidation to create larger chunk.
Allocate larger chunk B; likely to get space just freed.
Copy fake chunk into B that appears as an unallocated chunk adjacent to A, with fake pointers fd and bk chosen by the attacker.

54. Double-free
Call free(A) again; unlinking the “free” fake chunk overwrites memory using fake pointers fd and bk:
[1] FD=fd
[2] BK=bk
[3] fd->bk=bk
Value bk written to memory address fd+12.
Second call of free(A) has desired effect only if the pointer to A had not been set to null when A was freed the first time.
free(ptr) : If ptr is null, no operation is performed.

55. Double-free Attack allocated large free as chunk B chunk
Now free A again;
A will be coalesced with neighbouring fake free chunk; unlink is applied to fake chunk.
fake free chunk
chunk A
ptr *A
free chunk

56. Type Confusion

57. Type Safety – Java
Type safety (memory safety): programs cannot access memory in inappropriate ways.
Each Java object has a class; only certain operations are allowed to manipulate objects of that class.
Every object in memory is labelled with a class tag.
When a Java program has a reference to an object, it has internally a pointer to the memory address storing the object.
Pointer can be thought of as tagged with a type that says what kind of object the pointer is pointing to.

58. Type Confusion
Dynamic type checking: check the class tag when access is requested.
Static type checking: check all possible executions of the program to see whether a type violation could occur.
If there is a mistake in the type checking procedure, a malicious applet might be able to launch a type confusion attack by creating two pointers to the same object-with incompatible type tags.

59. Type Confusion
Assume the attacker manages to let two pointers point to the same location.
class T {
SecurityManager x; }
class U {
MyObject x;
class definitions
T t = the pointer tagged T;
U u = the pointer tagged U;
t.x = System.getSecurity();
MyObject m = u.x;
malicious applet

60. Type Confusion object 1 t type T u type U v type V object 2 …
Reference Table
memory

61. Type Confusion
The SecurityManager field can now also be manipulated from MyObject.
We sketch a type confusion attack in Netscape Navigator 3.05 (discovered by Drew Dean), fixed in version 3.06.
Source: Gary McGraw & Edward W. Felten: Java Security, John Wiley & Sons, 1997.

62. Netscape Vulnerability
Java allows a program that uses type T also to use type array of T.
Array types are defined by the VM for internal use; their name begins with the character [.
A programmer defined classname is not allowed to start with this character.
Hence, there should be no danger of conflict.
However, a Java byte code file could declare its own name to be a special array types name, thus redefining one of Java’s array types.

63. Data and Code

64. Scripting
Scripting languages used to construct commands (scripts) from predefined code fragments and user input.
Script is then passed to another software component where it is executed.
Attacker may hide additional commands in user input.
Defender has to check and sanitize user inputs.
Both have to be aware of certain technical details of the component executing the script:
Symbols that terminate command parameters.
Symbols that terminate commands.
Dangerous commands, e.g. commands for executing the commands they receive as input ( eval, exec, system, …).

65. Scripting
Scripting languages: Perl, PHP, Python, Tcl, Safe-Tcl, JavaScript, …
Example: A CGI script for a Unix server that sends file to clientaddress:
cat file | mail clientaddress
With the “mail address” | rm -rf / as input the server executes
cat file | mail | rm -rf /
After mailing the file all files the script has permission to delete are deleted.

66. SQL Injection Strings in SQL commands placed between single quotes.
Example query from SQL database:
$sql = "SELECT * FROM client WHERE name= ‘$name’"
Intention: insert legal user name like ‘Bob’ into query.
Attack enters as user name: Bob’ OR 1=1 --
SQL command becomes
SELECT * FROM client WHERE name = Bob’ OR 1=1--
Because 1=1 is TRUE, name = Bob OR 1=1 is TRUE, and the entire client database is selected; -- is a comment erasing anything that would follow.

67. SQL Injection Countermeasures against code injection:
Input validation: make sure that no unsafe input is used in the construction of a command.
Change the modus operandi: modify the way commands are constructed and executed so that unsafe input can do no harm.
Parametrized queries with bound parameters (DBI placeholders in Perl) follow the second approach.
Scripts compiled with placeholders instead of user input.
Commands called by transmitting the name of the procedure and the parameter values.
During execution, placeholders are replaced by the actual input.
This defence does not work for parametrized procedures containing eval() statements that accept user inputs as arguments.

68. Race Conditions

69. Race Conditions
Multiple computations access shared data in a way that their results depend on the sequence of accesses.
Multiple processes accessing the same variable.
Multiple threads in multi-threaded processes (as in Java servlets).
An attacker can try to change a value after it has been checked but before it is being used.
TOCTTOU (time-to-check-to-time-of use) is a well-known security issue.

70. Example – CTSS (1960s) Password file shown as message of the day.
Every user had a unique home directory.
When a user invoked the editor, a scratch file with fixed name SCRATCH was created in this directory .
Innovation: Several users may work concurrently system manager.

71. Race Conditions The abstraction ‘atomic transaction’ has been broken.
M-o-D
Passwd
hello
EsxT9
User1
edits M-o-D
User2
edits passwd
saves M-o-D
The abstraction ‘atomic transaction’ has been broken.

72. Defences

73. Prevention – Hardware
Hardware features can stop buffer overflow attacks from overwrite control information.
For example, a secure return address stack (SRAS) could protect the return address.
Separate register for the return address in Intel’s Itanium processor.
With protection mechanisms at the hardware layer there is no need to rewrite or recompile programs; only some processor instructions have to be modified.
Drawback: existing software, e.g. code that uses multi-threading, may work no longer.

74. Prevention – Non-executable Stack
Stops attack code from being executed from the stack.
Memory management unit configured to disable code execution on the stack.
Not trivial to implement if existing O/S routines are executing code on the stack.
General issue – backwards compatibility: security measures may break existing code.
Attackers may find ways of circumventing this protection mechanism.

75. Prevention – Safer Functions
C is infamous for its unsafe string handling functions: strcpy, sprintf, gets, …
Example: strcpy
char *strcpy( char *strDest, const char *strSource );
Exception if source or destination buffer are null.
Undefined if strings are not null-terminated.
No check whether the destination buffer is large enough.

76. Prevention – Safer Functions
Replace unsafe string functions by functions where the number of bytes/characters to be handled are specified:
strncpy, _snprintf, fgets, …
Example: strncpy
char *strncpy( char *strDest, const char *strSource, size_t count );
You still have to get the byte count right.
Easy if data structure used only within a function.
More difficult for shared data structures.

77. Prevention – Filtering
Filtering inputs has been a recommended defence several times before in this course.
Whitelisting: Specify legal inputs; accept legal inputs, block anything else.
Conservative, but if you forget about some specific legal inputs a legitimate action might be blocked.
Blacklisting: Specify forbidden inputs; block forbidden inputs, accept anything else.
If you forget about some specific dangerous input, attacks may still get through.
Taint analysis: Mark inputs from untrusted sources as tainted, stop execution if a security critical function gets tainted input; sanitizing functions produce clean output from tainted input.

78. Prevention – Filtering
White lists work well when valid inputs can be characterized by clear rules, preferably expressed as regular expressions.
Filtering rules could also refer to the type of an input; e.g., an is_numeric() check could be applied when an integer is expected as input.
Dangerous characters can be sanitized by using safe encodings.
E.g., in HTML <, > and & should be encoded as <, >, and &.
Escaping places a special symbol, often backslash, in front of the dangerous character.
E.g., escaping single quotes will turn d’Hondt into d\’Hondt.

79. Interaction between Layers
addslashes(): inserts backslash as “guard” in front of every single quote – or does it?
GBK: character set for Simplified Chinese, has one and two byte characters.
0xbf27 is not a valid GBK multi-byte character; as single-byte characters, we get ¿'.
Note: 0x27 is the single quote; 0x5c is the slash.
Add a slash in front of the single quote: 0xbf5c27
Valid multi-byte character 0xbf5c followed by a single quote; the single quote has survived unguarded!
Lesson: Danger of abstraction – manipulation at lower layer does not have the desired effect.
Looking for Unicode characters: 縗'

80. Prevention – Type Safety
Type safety guarantees absence of untrapped errors by static checks and by runtime checks.
The precise meaning of type safety depends on the definition of error.
Examples: Java, Ada, C#, Perl, Python, etc.
Languages needn’t be typed to be safe: LISP
Type safety is difficult to prove completely.

81. Detection – Canaries
Detect attempts at overwriting the return address.
Place a check value (‘canary’) in the memory location just below the return address.
Before returning, check that the canary has not been changed.
Stackguard: random canaries.
Alternatives: null canary, terminator canary
Source code has to be recompiled to insert placing and checking of the canary.

82. Canaries return address write to A: value1| canary value2| my_address
check value
value2 ≠ check value
canary
value1
buffer for
variable A
attack detected

83. Detection – Code Inspection
Code inspection is tedious: we need automation.
K. Ashcraft & D. Engler: Using Programmer-Written Compiler Extensions to Catch Security Holes, IEEE Symposium on Security &Privacy 2002.
Meta-compilation for C source code; ‘expert system’ incorporating rules for known issues: untrustworthy sources  sanitizing checks  trust sinks; raises alarm if untrustworthy input gets to sink without proper checks.
Code analysis to learn new design rules: Where is the sink that belongs to the check we see?
Microsoft has internal code inspection tools.

84. Detection – Testing
White box testing: tester has access to source code.
Black-box testing when source code is not available.
You do not need source code to observe how memory is used or to test how inputs are checked.
Example: syntax testing of protocols based on formal interface specification, valid cases, anomalies.
Applied to SNMP implementations: vulnerabilities in trap handling and request handling found
Found by Oulu University Secure Programming Group

85. Mitigation – Least Privilege
Limit privileges required to run code; if code running with few privileges is compromised, the damage is limited.
Do not give users more access rights than necessary; do not activate options not needed.
Example – debug option in Unix sendmail: when switched on at the destination, mail messages can contain commands that will be executed on the destination system.
Useful for system managers but need not be switched on all the time; exploited by the Internet Worm of 1988.

86. Lesson Learned
In the past, software was shipped in open configurations (generous access permissions, all features activated); user had to harden the system by removing features and restricting access rights.
Today, software often shipped in locked-down configurations; users have to activate the features they want to use.

87. Reaction – Keeping Up-to-date
Information sources : CERT advisories, BugTraq at security bulletins from software vendors.
Hacking tools use attack scripts that automatically search for and exploit known type of vulnerabilities.
Analysis tools following the same ideas will cover most real attacks.
Patching vulnerable systems is not easy: you have to get the patches to the users and avoid introducing new vulnerabilities through the patches.

88. Intrusion Patterns
number of intrusions
Time
disclosure
attack scripts released
patch
released
W. Arbaugh, B. Fithen, J. McHugh: Windows of Vulnerability:
A Case Study Analysis, IEEE Computer, 12/2000

89. Broken Abstractions
Treating the problems presented individually, would amount to penetrate-and-patch at a meta-level.
We looking for general patterns in insecure software, we see that familiar programming abstractions like variable, array, integer, data & code, address, or atomic transaction are being implemented in a way that breaks the abstraction.
Software security problems can be addressed
in the processor architecture,
in the programming language we are using,
in the coding discipline we adhere to,
through checks added at compile time (e.g. canaries),
and during software development and deployment.

90. Summary Many of the problems listed may look trivial.
There is no silver bullet:
Code-inspection: better at catching known problems, may raise false alarms.
Black-box testing: better at catching known problems.
Type safety: guarantees from an abstract (partial) model need not carry over to the real system.
Experience in high-level programming languages may be a disadvantage when writing low level network routines.