Risks of Unvalidated Input

Any time your program accepts input from an uncontrolled source, there is a potential for a user to pass in data that does not conform to your expectations. If you don’t validate the input, it might cause problems ranging from program crashes to allowing an attacker to execute his own code. There are a number of ways an attacker can take advantage of unvalidated input, including:

• Buffer overflows

• Format string vulnerabilities

• URL commands

• Code insertion

• Social engineering

Many Apple security updates have been to fix input vulnerabilities, including a couple of vulnerabilities that hackers used to “jailbreak” iPhones. Input vulnerabilities are common and are often easily exploitable, but are also usually easily remedied.

/* receiving http packet */

int size = recv(fd, pktBuf, sizeof(pktBuf), 0);

if (size) {

    syslog(LOG_INFO, "Received new HTTP request!");

    syslog(LOG_INFO, pktBuf);

}

"AAAA%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%n"

alert = [NSAlert alertWithMessageText:"Certificate Import Succeeded"

    defaultButton:"OK"

    alternateButton:nil

    otherButton:nil

    informativeTextWithFormat:[NSString stringWithFormat: /* BAD! BAD! BAD! */

       @"The imported certificate \"%@\" has been selected in the certificate pop-up.",

       [selectedCert identifier]]];

[alert setAlertStyle:NSInformationalAlertStyle];

[alert runModal];

alert = [NSAlert alertWithMessageText:"Certificate Import Succeeded"

    defaultButton:"OK"

    alternateButton:nil

    otherButton:nil

    informativeTextWithFormat:@"The imported certificate \"%@\" has been selected in the certificate pop-up.",

       [selectedCert identifier]];

...

myapp://cmd/delete?file=cached data that is slowing down your system.,realfile

Fuzzing

Fuzzing, or fuzz testing, is the technique of randomly or selectively altering otherwise valid data and passing it to a program to see what happens. If the program crashes or otherwise misbehaves, that’s an indication of a potential vulnerability that might be exploitable. Fuzzing is a favorite tool of hackers who are looking for buffer overflows and the other types of vulnerabilities discussed in this chapter. Because it will be employed by hackers against your program, you should use it first, so you can close any vulnerabilities before they do.

Although you can never prove that your program is completely free of vulnerabilities, you can at least get rid of any that are easy to find this way. In this case, the developer’s job is much easier than that of the hacker. Whereas the hacker has to not only find input fields that might be vulnerable, but also must determine the exact nature of the vulnerability and then craft an attack that exploits it, you need only find the vulnerability, then look at the source code to determine how to close it. You don’t need to prove that the problem is exploitable—just assume that someone will find a way to exploit it, and fix it before they get an opportunity to try.

Fuzzing is best done with scripts or short programs that randomly vary the input passed to a program. Depending on the type of input you’re testing—text field, URL, data file, and so forth—you can try HTML, javascript, extra long strings, normally illegal characters, and so forth. If the program crashes or does anything unexpected, you need to examine the source code that handles that input to see what the problem is, and fix it.

For example, if your program asks for a filename, you should attempt to enter a string longer than the maximum legal filename. Or, if there is a field that specifies the size of a block of data, attempt to use a data block larger than the one you indicated in the size field.

The most interesting values to try when fuzzing are usually boundary values. For example, if a variable contains a signed integer, try passing the maximum and minimum values allowed for a signed integer of that size, along with 0, 1, and -1. If a data field should contain a string with no fewer than 1 byte and no more than 42 bytes, try zero bytes, 1 byte, 42 bytes, and 43 bytes. And so on.

In addition to boundary values, you should also try values that are way, way outside the expected values. For example, if your application is expecting an image that is up to 2,000 pixels by 3,000 pixels, you might modify the size fields to claim that the image is 65,535 pixels by 65,535 pixels. Using large values can uncover integer overflow bugs (and in some cases, NULL pointer handling bugs when a memory allocation fails). See Avoiding Integer Overflows and Underflows in Avoiding Buffer Overflows and Underflows for more information about integer overflows.

Inserting additional bytes of data into the middle or end of a file can also be a useful fuzzing technique in some cases. For example, if a file’s header indicates that it contains 1024 bytes after the header, the fuzzer could add a 1025th byte. The fuzzer could add an additional row or column of data in an image file. And so on.

When you are fuzzing, if you are using the Clang compiler, you should compile your software with the -fsanitize series of compiler flags. These flags enable additional run-time checks for signed and unsigned integer overflow, out-of-bounds array accesses (when the bounds can be determined at compile time), and other common coding errors. Although these additional checks do not prevent overflows from occurring, they do cause your software to print diagnostic messages when overflows occur, which can make it easier to detect the problem and locate the offending code during testing.

The -fsanitize flags are set by Xcode when you enable the address sanitizer feature. With address sanitizer enabled, you can take advantage of Xcode debugger features to locate and fix bad memory accesses. For more information about the address sanitizer, see Using the Address Sanitizer.

Interprocess Communication and Networking

When communicating with another process, the most important thing to remember is that you cannot generally verify that the other process has not been compromised. Thus, you must treat it as untrusted and potentially hostile. All interprocess communication is potentially vulnerable to attacks if you do not properly validate input, avoid race conditions, and perform any other tests that are appropriate when working with data from a potentially hostile source.

Above and beyond these risks, however, some forms of interprocess communication have specific risks inherent to the communication mechanism. This section describes some of those risks.

Mach Messaging

When working with Mach messaging, it is important to never give the Mach task port of your process to any other. If you do, you are effectively allowing that process to arbitrarily modify the address space of your process, which makes it trivial to compromise your process.

Instead, you should create a Mach port specifically for communicating with a given client.

Note: Mach messaging in macOS is not a supported API. No backwards compatibility guarantees are made for applications that use it anyway.

Distributed Objects

Distributed Objects are vended using an NSDistantObject proxy, which in turn communicates using an NSConnection object. However, because NSConnection does not require serialized objects to conform to the NSSecureCoding protocol and does not provide a built-in authentication mechanism, communication with an untrusted endpoint could result in unsafe method invocation or arbitrary code execution by an attacker. Therefore, Distributed Objects cannot be used securely between different processes and is only suitable for inter-thread communication within a single process using the connectionWithReceivePort:sendPort: method.

Instead, modern apps conduct inter-process communication using XPC Services.

XPC Services

XPC Services are the most secure way to conduct inter-process communication in a modern app, but even here, the level of security depends on the particulars of your implementation.

For example, the XPC Services API allows the exchange of only those objects conforming to the NSSecureCoding protocol. This helps to guard against object substitution attacks because it contractually obligates the receiving code to skip decoding objects that are not of the expected class. In principle, an object received from a remote service could be of any class, with potentially malicious behavior. Without NSSecureCoding, while you can choose to verify a decoded object’s class before using it, nothing enforces this. Even if you do, conducting such a test requires first decoding the object and placing it in memory, which is a security concern. With NSSecureCoding, objects fail to decode at all when they are not of the expected class. To fully benefit from this feature, however, it is vital that you correctly and securely implement the NSSecureCoding protocol for any custom classes whose objects you serialize and exchange this way.

XPC Services additionally provide a means to query the identity of the code at the other end of the connection. Your app can make security decisions based on properties of the connection object, such as processIdentifier and auditSessionIdentifier. However, if you are not using Library Validation, as described in Using Library Validation, you cannot be certain that untrusted code isn’t running in that same process (via a plug-in, for example).

For more information about XPC Services, including details about the high level NSXPCConnection API, and the lower level, C-based, XPC Services API, read Creating XPC Services in Daemons and Services Programming Guide

Shared Memory

If you intend to share memory across applications, be careful to allocate any memory on the heap in page-aligned, page-sized blocks. If you share a block of memory that is not a whole page (or worse, if you share some portion of your application’s stack), you may be providing the process at the other end with the ability to overwrite portions of your code, stack, or other data in ways that can produce incorrect behavior, and may even allow injection of arbitrary code.

In addition to these risks, some forms of shared memory can also be subject to race condition attacks. Specifically, memory mapped files can be replaced with other files between when you create the file and when you open it. See Securing File Operations for more details.

Finally, named shared memory regions and memory mapped files can be accessed by any other process running as the user. For this reason, it is not safe to use non-anonymous shared memory for sending highly secret information between processes. Instead, allocate your shared memory region prior to creating the child process that needs to share that region, then pass IPC_PRIVATE as the key for shmget to ensure that the shared memory identifier is not easy to guess.

Note: Shared memory regions are detached if you call exec or other similar functions. If you need to pass data in a secure way across an exec boundary, you must pass the shared memory ID to the child process. Ideally, you should do this using a secure mechanism, such as a pipe created using a call to pipe.

After the last child process that needs to use a particular shared memory region is running, the process that created the region should call shmctl to remove the shared memory region. Doing so ensures that no further processes can attach to that region even if they manage to guess the region ID.

shmctl(id, IPC_RMID, NULL);

Signals

A signal, in this context, is a particular type of content-free message sent from one process to another in a UNIX-based operating system such as macOS. Any program can register a signal handler function to perform specific operations upon receiving a signal.

In general, it is not safe to do a significant amount of work in a signal handler. There are only a handful of library functions and system calls that are safe to use in a signal handler (referred to as async-signal-safe calls), and this makes it somewhat difficult to safely perform work inside a call.

More importantly, however, as a programmer, you are not in control of when your application receives a signal. Thus, if an attacker can cause a signal to be delivered to your process (by overflowing a socket buffer, for example), the attacker can cause your signal handler code to execute at any time, between any two lines of code in your application. This can be problematic if there are certain places where executing that code would be dangerous.

For example, in 2004, a signal handler race condition was found in open-source code present in many UNIX-based operating systems. This bug made it possible for a remote attacker to execute arbitrary code or to stop the FTP daemon from working by causing it to read data from a socket and execute commands while it was still running as the root user. [CVE-2004-0794]

For this reason, signal handlers should do the minimum amount of work possible, and should perform the bulk of the work at a known location within the application’s main program loop.

For example, in an application based on Foundation or Core Foundation, you can create a pair of connected sockets by calling socketpair, call setsockopt to set the socket to non-blocking, turn one end into a CFStream object by calling CFStreamCreatePairWithSocket, and then schedule that stream on your run loop. Then, you can install a minimal signal handler that uses the write system call (which is async-signal-safe according to POSIX.1) to write data into the other socket. When the signal handler returns, your run loop will be woken up by data on the other socket, and you can then handle the signal at your convenience.

Important: If you are writing to a socket in a signal handler and reading from it in a run loop on your main program thread, you must set the socket to non-blocking. If you do not, it is possible to cause your application to hang by sending it too many signals.

The queue for a socket is of finite size. When it fills up, if the socket is set to non-blocking, the write call fails, and the global variable errno is set to EAGAIN. If the socket is blocking, however, the write call blocks until the queue empties enough to write the data.

If a write call in a signal handler blocks, this prevents the signal handler from returning execution to the run loop. If that run loop is responsible for reading data from the socket, the queue will never empty, the write call will never unblock, and your application will basically hang (at least until the write call is interrupted by another signal).