introduction.tex

\chapter{Introduction}
\label{sec:intro}

Many modern applications split functionality into multiple processes, allowing programmers to achieve the design principle of separation of concerns.  For example, by creating a password manager that uses two processes, one to store the passwords and a second to display them to the user, programmers can separately focus on the two very different tasks.  One group can ensure that the stored passwords are unable to be stolen from the machine, while the other can provide the interface between the user and his or her information.  This division of labor also allows someone with security expertise to only work on keeping the passwords safe and a user-interface designer to create a functional UI, instead of having one group work in areas that are not their strengths.  However, separating related operations into different processes implies that they must communicate in some way.  The password manager needs some way of getting the passwords from the secured database to the UI for the user to view.  This is an example of inter-process communication.

\section{Inter-Process Communication}
\label{sec:ipcIntro}
Inter-process communication encompasses any form of communication between running processes.  This is a very broad definition that applies to much of the way that people use computers.  Inter-process communication, or IPC, captures everything from email to using a web browser to get webpages from a web server to password managers transmitting passwords within a computer.  Local IPC is communication that occurs within a single computer.  Instead of traversing the Internet and interacting with many hosts, local inter-process communication stays completely inside one computer, and is often dealt with entirely by the kernel.  Inter-process communication and local IPC will be further explored in Chapter~\ref{sec:interProcessCommunication}.

\section{Insecurity of Inter-Process Communication}
\label{sec:ipcInsecurity}
\subsection{What does it mean to be insecure?}
\label{sec:whatIsInsecure}
For an application to be insecure, an attacker must be able to exploit the application to act in a way that is not desired.  These attacks can be broken down into two broad classes: information disclosure and execution hijacking.  An information disclosure attack is when an attacker gains access to victims' confidential information.  This can include passwords, social security numbers, bank credentials, or other private information.  These attacks have been in the news recently as large companies like social media giant Facebook~\cite{o'sullivan_2018} and credit agency Equifax~\cite{timberg_dwoskin_fung_2017} have been hacked and millions of users' private information was taken.  

Execution hijacking attacks occur when an attacker is able to run arbitrary code on a victim's machine.  If the attacker can run code as the victim, then he or she can act while pretending to be the victim.  To an outside viewer, seeing a program running as a user on that user's computer would be expected, so attackers would be able to impersonate the victim without being easily spotted as a compromised machine.  These attacks violate a victim's security and privacy by allowing hackers to steal confidential information and use a victim's identity to perform arbitrary actions.  These two classes of attacks, while different, are similar in their lasting effects.  Attackers are able to act as the victim and do what they would like.  Whether that means using a stolen social security number to open a new credit card account or running a process on a victim's computer to send spam emails, the attacker gains new opportunities to act with the direct consequences falling onto the victim.

We will now use this idea of security and apply it to both networked and local IPC and examine the implications of both.

\subsection{Security of Networked IPC}
\label{sec:networkedIPCSecurity}
Since it requires other computers to handle a user's data, networked inter-process communication is fundamentally insecure.  Any computer on the route between the source and destination is given the data, and in theory, could do whatever it wants with the message.  This could include storing the data and attempting to decrypt it offline, or monitoring the traffic that different hosts and users send.  Without encryption, any computer along the path between the source and destination would be able to read all information passed in the message, allowing information disclosure vulnerabilities to be trivial.  This would include passwords, credit card numbers, and other forms of private information that are constantly sent through the Internet.  To protect against this, much of the confidential information sent across the Internet is encrypted.  As the Internet has become more popular, more and more information is being encrypted when sent over the network.  In the past, HTTPS, the encrypted version of HTTP, was used for secure transactions only, such as entering a credit card number to make an online purchase or typing in a password to log into an account.  Now, HTTPS is used more than ever before~\cite{google_transparency_report}.  This allows users to protect their browsing history and helps to reduce the ability of attackers to forge website URLs through the use of certificates.  However, even with HTTPS and other precautions, anytime that personal or confidential information is sent through other machines, that communication should be considered insecure.

\subsection{Security of Local IPC}
\label{sec:localIPCSecurity}
Local IPC, on the other hand, is completely contained within a single computer.  The messages stay within the machine, and are almost always handled by the kernel itself.  However, that does not mean that this communication is entirely secure.  In fact, since many believe that communicating within a single computer is secure, security precautions that are standard for networked communication are often missing in local IPC~\cite{MitMa}.  It is not the case that programmers do not try at all to secure this communication; in fact, there is often some form of security, but it is not enough, as shown by~\cite{MitMa}.  This will be discussed in-depth in Section~\ref{sec:manInMachineAttack}, but researchers studied the ways that applications communicate locally and were able to impersonate the client or server, or both, in a dozen commonly-used applications.  Further, they showed that it is possible to do so while also making it difficult for the victim to know that their machine has been compromised, running their attack from another user account on the machine.  Additionally, many different attacks against Windows named pipes and Mac OS X application isolation have been found that abuse local IPC; these are the subject of Section~\ref{sec:localIPCVulnerabilities}.


\section{Plan of this thesis}
\label{sec:planOfThesis}
After giving related work to this topic in Section~\ref{sec:relatedWork}, Chapter~\ref{sec:interProcessCommunication} discusses IPC, its uses and the forms of local IPC that I studied.  Chapter~\ref{sec:securityOfIPC} will explore security of applications, including attacks against host-only applications and input-based vulnerabilities.  Chapter~\ref{sec:methods} explains my methods and Chapter~\ref{sec:results} analyzes the specific results for each application that I examined: \texttt{Spotify}, \texttt{Visual Studio Code}, \texttt{launchd}, and \texttt{mDNSResponder}.  Since we know that local IPC is of concern, it will be helpful to characterize the security of these individual applications that use this form of communication.  Finally, I will give ideas of future work in Chapter~\ref{sec:futureWork} and then end this thesis by discussing my results in Chapter~\ref{sec:discussion}.


\section{Related Work}
\label{sec:relatedWork}
\subsection{Man-in-the-Machine Attacks}
\label{sec:manInMachineAttack}
In a 2018 paper, Bui et al. looked at the ways common applications used local IPC and found that they were able to read communication between processes and either hijack execution or disclose confidential information~\cite{MitMa}.  They named this attack the Man-in-the-Machine Attack, since the attacker is using communication that stays within the computer and the attack comes from the same machine.

These authors explored the situation where an attacker had access to the victim's host, but neither as an administrator nor as the victim.  Instead, the attacker used a separate login session, either as another authenticated user to that computer, or using the guest account.  Many people who use a personal computer do not disable the guest account, which leaves their computer open to possible attacks.  Additionally, a public terminal with many accounts, such as at a university or an office, would allow an authenticated user to possibly steal confidential information from many people, instead of the single victim of a personal computer.  Using fast user switching on Windows~\cite{microsoft_developers_network_2018} or running a program with \texttt{nohup} on Mac OS X and Linux allows a program to run even when the user who started the program is no longer logged in, or the user is running in the background.  Using these techniques, an attacker could start the malicious program while logged into an account, then log out while continuing their attack.

Bui et al. looked specifically at three vulnerable types of local IPC: network sockets, Windows named pipes, and communication with universal serial bus (USB) devices.  Network sockets provide an easy attack vector for both client and server impersonation.  Since the authors only investigated local IPC, the IP address for all communication was the address of the loopback interface, 127.0.0.1.  Therefore, they only needed to find what port the software used to find the communication between the processes.  A server listens on a set of specific port numbers that is defined in the source code, so a malicious process would need to connect to one of these ports to impersonate a client.  If the server can only support one connection, then the malicious client must connect before the genuine client does.  To impersonate the server, the malicious program must listen on the selected ports before the actual server has the chance to bind to them.  By creating a fake client and a fake server, an attacker is able to complete a man-in-the-middle attack.

It is similarly easy to impersonate either the client or server when they communicate through named pipes.  Instead of using port numbers, named pipes have a name, or location in the filesystem, that can be used to identify them.  To impersonate the client, the malicious program must join the named pipe as a reader, and to impersonate the server, the program must create the named pipe before the real server does.  The only requirement for either of these is to know the name of the pipe, which can easily be found by running the \texttt{lsof} program on UNIX operating systems or the \texttt{handle} or \texttt{pipelist} programs on Windows~\cite{russinovich_2018}~\cite{markruss_sharkey_2016}.  The attacker can then use this name for his or her attack.

The last class of vulnerable local IPC uses USB devices.  On some operating systems, including Windows, a USB device is available to any user once it is plugged into the machine.  To keep access secure, the programmers behind the software on the USB device must implement security features to protect unwanted use.  Without these features, any user, including the malicious user, could access the USB device.

Bui et al. also found that there are some types of local IPC that are immune to the man-in-the-machine attack.  The two most common types are anonymous pipes and anonymous socket pairs.  Anonymous pipes are often used in pipelines while using a shell or created using the \texttt{pipe} or \texttt{CreatePipe} system calls.  A command like \texttt{ls $|$ grep sys} uses an anonymous pipe to take the output of \texttt{ls} and send it as input to \texttt{grep}.  These pipes are safe while named pipes are not because the anonymous pipe owns both ends of the communication channel.  The pipe also does not have a name that can be joined by other processes.  Therefore, for another process to have access, it must be explicitly given one end.  This mostly occurs between parent and child processes, as in the shell example above.  Anonymous socket pairs are safe for the same reason.  Since the sockets do not have names and cannot be joined by outside processes, any use of them is considered safe because another process must be explicitly granted access by the process that owns the sockets.

The authors went on to study four classes of applications: password managers, USB hardware tokens, applications that have an HTTP backend, and two other applications of interest.  Of the thirteen applications studied, twelve were vulnerable to some form of impersonation, while the other was vulnerable to signing incorrect two-factor authentication requests.

Some of the studied password managers had such careless security that a man-in-the-machine attack was trivial.  \texttt{RoboForm} connected its browser extension with the password database through the loopback interface, and communicated the password in plaintext.  To steal a user's passwords, the attacker only needed to connect to the loopback interface's port 54512, ask for a list of accounts, and then choose one of the keys that was sent from the database.  The database would then send the password associated with that account in plaintext.  While the other password managers had stricter security, Bui et al. were able to impersonate one side of the conversation because of weak key-exchange protocols, secret keys stored in Javascript code, or other easily fixable security holes.

The two applications that used hardware tokens are used for two-factor security.  While a password is a ``thing you know,'' a physical two-factor device is a ``thing you have.''  Two-factor authentication with a security token is employed when a user wants extra security for a password-protected account by requiring both a ``thing you know'' and a ``thing you have.''  For example, one of the studied tokens, \texttt{Fujitsu DigiSign}, is used by the Finnish people for additional security when interacting with government services, including healthcare resources~\cite{MitMa}.  The attack on this token takes the primary port that the card-reader listens on before the real client can, then impersonates the server by connecting to the real client from a secondary port.  This allows the attacker to have malicious requests signed by the token and the user.

The other applications, while lacking the protection guarantees that are required of a password manager or security token, still had insufficient security.  For example, \texttt{Spotify} is a music streaming platform that used a socket connected to the loopback interface to play music.  After connecting to the server, an attacker could spoof the Origin field in the header of the HTTP request so the malicious request will be accepted by the server.  They could then design the payload of the packet to change the song that the victim is listening to.  \texttt{MySQL} is a database server that can be configured to use named pipes.  Here, an attacker can join the server's real named pipe as a reader and create its own instance for the client to join, resulting in a man-in-the-middle attack.  The attacker can then query the database itself, as well as modify legitimate queries to and responses from the database.

\subsection{Local IPC Vulnerabilities}
\label{sec:localIPCVulnerabilities}
Bui et al. were not the first to identify vulnerabilities in local IPC.  Many have found issues with the way local IPC is implemented by kernels.  Named pipes, specifically in Windows, have well-documented security issues.  First of all, the default access rights for a Windows named pipe allow anyone to read it, meaning that a programmer must change the default setting to even begin to securely use a named pipe~\cite{microsoft_2018}.  Additionally, a lack of complete understanding of how to use named pipes created many vulnerabilities in Windows applications that gratuitously used named pipes, including a remote code execution attack against \texttt{qBittorrent}~\cite{cohen_2019}.  Finally, by exploiting the way that Windows creates named pipes, a named pipe server could gain the security context of and impersonate the client~\cite{watts2002discovering}.

However, named pipes are not the only form of local IPC with vulnerabilities.  It has been shown that malicious applications on both iOS and Mac OS X can use local IPC to gain access to all the resources of a victim application~\cite{Xing_2015_CAI_2810103_2813609}.  An attacker was able to bind to the port used by the \texttt{1Password} password manager before the real app could.  Then, he or she could steal passwords, even though the two applications were supposed to be sandboxed from each other.  On the Android operating system, UNIX domain sockets have been shown to be vulnerable as well.  A malicious program could give itself root access, view the confidential files of other apps, or access the Bluedroid (Android Bluetooth) radio and control devices connected through Bluedroid~\cite{Shao_2016_MAU_2976749_2978297}.  These vulnerabilites are due to a lack of authentication by both processes connecting to the socket.