How Software gets Security Wrong

Computer Security Lecture, Dr. Lawlor

Computer Security failures have a long history, and that history tends to repeat.

Unpatched Systems

The biggest problem on the internet today is not systems getting hit by new unknown zeroday attacks, it's systems getting hit by known, fixed problems where the fix has simply not been applied.

2017 Equifax hack, which exposed over 100 million Americans to potential identity theft, was likely due to a two month old Apache Struts vulnerability.

HTTPS Nowhere

The Certificate Authority Public Key Infrastructure is not perfect, but it's way better than plain HTTP, which has zero protection against sniffing or injection of traffic by anybody that controls any part of the network between client and server.

2009 sslstrip transparently redirects HTTPS requests to HTTP requests.

Least Privilege

Way too much code runs with too many privileges, for the simple reason that it's easier to get code running on a wide-open system than on a locked-down system.

To open port 80, you need root or CAP_NET_BIND_SERVICE. But running a network-facing service as root is an awful idea, since any vulnerability in the service hands the entire machine to the attacker in one step. The fix is to setuid as a non-privileged user after opening the port--this is the default on Apache, nginx, IIS, and any grown-up web server, but many hand rolled servers don't do this.

Input Validation

SQL injection, script injection, and directory traversal vulnerabilities all stem from allowing bad network-derived strings into parts of the system that they're not supposed to access.

Perl has a "taint mode" that treats all external strings as "tainted" unless and until they've been checked with a regex. Using a tainted string to open a file or run a shell command results in perl preemptively exiting rather than run the possibility of an injection attack.

Pointer Mixups

The classic pointer mixup is walking a C string pointer off the end of the C string's buffer, corrupting memory beyond. Any application that manipulates C strings is at least theoretically vulnerable to this, often in weird corner cases.

2017 Stack Clash: trash heap memory with stack memory, or stack memory with heap memory, by allocating enough stack space that the stack and heap intersect. Much harder on 64-bit machines, which have much more space for the stack to grow before it hits anything.

2017 mmap bugs in device drivers: many device drivers don't fully validate mmap calls, which can allow kernel memory to get mapped directly into user space, allowing an attacker read/write access to the kernel.

Integer Overflow

The general problem is summarized well in Phrack vol 0x0b, issue 0x3c "Basic Integer Overflows".

2005 Linux Kernel ELF core dump vulnerability: the code to check if a section length was too big treated the length as signed, while the code to actually load the section treated the length as unsigned.

2010 BitCoin value overflow incident: custom transaction splits one address containing 0.5 bitcoin into two transfers of size 92.2 billion each. Due to an overflow in the miner, this transaction was accepted. The code was patched within hours to check for overflow, and the new block chain is the basis for everything used since.

Time of check to time of use (TOCTOU)

Any code of this general format is vulnerable to a TOCTOU attack:

	if (check_request())
		perform_request();

The problem is everything might have been OK when the check was performed, but by the time the machine actually performs the request, things have changed and the request is now unsafe. Typical things that can change:

Filesystem changes, like inserting a symlink right where a setuid executable is about to drop its temporary file.
Memory deallocation, resulting in a use-after-delete during the request. The denial-of-service possibilities are obvious, but things like heapspray can allow targeting for these random changes by creating lots of targets.
Account changes, like creating, deleting, or promoting a user account while another request is ongoing. At the least, these can result in data corruption; at most, they can hand the system to an attacker.

The 2016 Ethereum DAO thefts were enabled by poorly written contract code. More bad contract code was exploited in July 2017, but the damage was limited by white hat hackers draining the accounts first.

SMP Race conditions

Like TOCTOU, SMP race conditions are timing dependent vulnerabilities.

2016 DirtyCOW: a linux kernel bug in the pagetable handling for copy-on-write (COW) memory pages.

Side Channels

Side channels are unintentional leakage of data that is supposed to be secret. Typical side channel attacks monitor the code's timing, memory usage, network usage, temperature history, etc.

2005 SSL timing attack showed 1024-bit RSA private keys could be extracted just by generating custom SSL traffic and measuring the time it took for the server to respond.

2016 JavaScript keystroke timing attack showed nanosecond timings are possible from sandboxed javascript (such as from malvertizing), which enables reliable detection of the extra CPU overhead during the processing of keystrokes, taps, and swipes.

Direct Hardware Access

Hardware is the ultimate side channel, since electron states can be read or written at the hardware level regardless of any software protections in place.

2016 PCILeech (video) is a tiny PCIexpress card that allows physical memory to be read or written at 150MB/second, using PCI direct memory access (DMA).

Ostrich Logging

If several terabytes of data left your network, would you know? You should!