Software security

"Unexpected" inputs to programs can break security. Examples:

1.1.1. URL encodings (cf von Braun)

Various ways of hiding the "real" destination of a HTML link.

1. explicit URL in link text, e.g. <a href="http://villain.si.te">http://www.nordea.se</a>: in some situations the browser may not even show the real link before the user clicks
2. encoding the href, e.g. http://129.168.1.42, http://quite-a-long-prefix-of.nordea.se:incomprehensible-junk@villain.si.te where the quite-...se is interpreted as username, incomprehensible-junk as a password, and the combined length hides the real host villain.si.te if the browser field to show the link is too short.
3. homograph encodings: the "Internationalized Domain Name" (IDN) encoding allows full unicode character set, where many characters look the same: using a letter looking just like ascii "o", the domain www.nordea.com can be registered, and the user agent/client may not show the difference, making spoofing attacks easier.

1.1.2. Name-based protection

1. e.g. file name case sensitivity (the file "MyFile" has separate access control (not internal to file system) with that spelling, but can be accessed as "myfile" bypassing access control)
2. encodings of names/identifiers, e.g. ASCII vs ISO-8859-x vs UTF-8 vs Unicode, or IP address vs DNS name

Good solution: rewrite to one canonical form before lookup/control. (Don't decode twice! Cf foo&amp;amp;bar => foo&amp;bar => foo&bar)

1.1.3. Script and SQL insertion

Scripts (typically interpreted high-level programs) are often used for programming web pages, handling web forms etc. Input is often received in variables (program-level or environment variables) corresponding to the fields of the web form and other information about the web request.

Problem: input may be used in un-controlled ways. Example from the book: web script accepting a mail address to send a file to (say $clientaddr), executing

cat thefile | mail $clientaddr

in a standard shell.

A malicious client can now supply not only a mail address, but a partial shell command, e.g. "foo@bar.com; rm -rf /". What gets executed is

cat thefile | mail foo@bar.com; rm -rf /

Similar standard attacks on SQL commands (database language used in many web applications); may be used to change the database query and find/change data.

Solution:

• always escape/quote special characters for the "command interpreter" whether it is a shell, programming language, or SQL database. E.g. replace ";" with "\;", "|" with "\|", in shell scripts; "'" with "\'" in SQL code, etc.
• validate the input before using it; e.g. checking for correct syntax (mail addresses, integers, ...), typing (if possible) and length. Client-side validation (e.g. using JavaScript) is only a help for the user; the important issue is server-side validation.

1.1.4. Pathnames

Files used by e.g. a web server are typically located in a specific "branch" of the file system, such as /var/www/html, and web clients should not have access to files outside that branch (e.g. /etc/passwd). File names are input (implicitly) from the client through the URL, and are typically relative to the "root of the web branch".

What happens if the file name is relative, e.g. ../../../../etc/passwd?

Solutions:

• disallow/remove "../" components - and check for encodings of that string (cf Gollmann 14.2.1)
• translate the pathname to an absolute one, and make sure it is within the correct "branch" (cf "canonical forms")
• in Unix, use chroot to make it impossible to access paths outside the intended branch (chroot changes the root (/) interpretation in the process and subprocesses)

Each of these may be more or less practical.

Integer representation is typically finite/fixed size (8, 16, 32, 64 bits).

• Wraps around: 255+1 = 0 (unsigned 8-bit), 127+1 = -1 (signed 8-bit)
• Converting between representations may lose value: 32-bit to 16-bit throws away half the bits!

1.2.1. Array bounds checking

In low-level languages like C, there is no array bounds checking. Specifically, strings are arrays of 8-bit bytes (terminated by 0 ("null" character)). Indexing an array is just doing pointer arithmetic:

arr[index] is the same as &arr+index*sizeof(array element)

i.e. start address of arr plus offset to index

Consider negative indexes.

Standard problem:

gets(buf) reads bytes into buf until EOF or newline - without checking that the contents fit!

Solution:

fgets(buf, nbytes, stream) reads maximum nbytes (from stream, e.g. stdin)

Similar problems with strcpy(dest, src): use strncpy(dest, src, nbytes) or even better strlcpy(dest, src, nbytes where nbytes is the size of dest including the terminating "null" character! (Note that for strncpy you need to allow room for the null byte, and put it there.)

Exploit of the bounds checking problem, in combination with how local variables are allocated. Consider a function

void foo(void) {		/* no argument, no value */
  char buf[70];

  gets(buf);			/* read input */
  if (strncmp(buf, "foo", 3))	/* are the first three characters "foo"? */
    printf("bar!\n");		/* then give some response */
}

When the function is called, the stack has the following content (on a system where the stack grows from higher to lower addresses):

When input is read, it is stored in buf (without range checking), so in particular the return address can be overwritten, changing where the process jumps to when done. Also, the higher addresses on the stack can be overwritten with code, which can then be jumped to. Thus an "attacker" can make the program execute arbitrary code! Cf the Worm 1988, and Gollmann 14.4.3.