Basic Flaws in Internet Security and Commerce

[gauthier@espresso.CS.Berkeley.EDU (Paul_A Gauthier)]

Basic Flaws in Internet Security and Commerce

We believe that the current focus on secure session-layer protocols and
sufficient randomness have obscured more fundamental flaws in end-to-end
security. In particular, secure end-to-end transactions require two parts: a
secure protocol to communicate over untrusted channels, and trusted code at
both endpoints. The latter problem has received less attention, but destroys
security regardless of the quality of the protocols or of the random numbers.

We have implemented a series of related attacks utilizing IP spoofing:

   *  We can spoof NFS to patch binaries on the fly if we are on any subnet
     between the NFS client and NFS server. We used this to turn legitimate
     Netscape browsers into versions that used a fixed key (known only to us),
     thus invisibly eliminating security.
   *  The same trick allows us to defeat Kerberos security by attacking kinit.
   *  We can also spoof NFS file-handle lookups, so that we can replace any
     file (such as .login) with another file that runs with root access
     privileges (even if the requesting user cannot).

These work because the trusted path to executables is really not trustworthy in
most environments. Although we use on-the-wire patching to compromise
executables, the client binaries can also be compromised during download, by
on-the-wire patching of FTP or HTTP transfers. Trojan horses and viruses could
also patch the client software after it's on the local disk, especially on
systems like Windows 95 that do not provide access control for files.

Given that these are realistic threats, we believe that these issues must be
resolved before internet security and commerce are realistic.

-------------------------------------------------------------------------------

We began to consider in more detail some fundamental weaknesses of common
network security practices that would lead to trivial further attacks on
Netscape as well as many other security tools like Kerberos. It was our goal to
demonstrate that it is trivially possible to patch executables on-the-wire to
completely compromise their security.

In doing so, we hope to reinforce the point that security is an end-to-end
problem that is far harder than getting the protocols correct. Strong, correct
protocols only make more subtle endpoint attacks more likely, especially in
light of the potential for financial gain as the amount of commerce on the
Internet increases. Most of the attacks we discuss are suitable for the
systematic exploitation of large groups of users: an entire organization, or
even a large fraction of the user base of a particular piece of software.

In many computing environments a pool of common executables, like the Netscape
binary, are provided to clients by a fileserver. In such systems, including
NFS, AFS and Windows NT, there is no authentication of the file contents sent
between clients and servers.

In these systems there are provisions for sophisticated access checks to
determine file permissions, at open or handle lookup time. But the file
contents that are read from the server are not authenticated in any secure way.
The client has no way to determine if the bytes are indeed being sent by the
server.

Our first attack model is one in which the attacker has (promiscuous) network
access to any machine on any ethernet subnet between the fileserver and the
clients under attack. In under a day we produced software that can exploit the
lack of authentication in NFS to patch the object code of any executable
on-the-wire as it travels between the NFS server and the client machine.

The technical details of the attack are rather simple. To retrieve data from
the NFS server a client sends a short request message detailing which block
from the file it is interested in (where a block is a range of bytes). The
attack software is located on an ethernet segment between the client and the
NFS server, so is able to snoop this traffic.

The attack software snoops, waiting for any request for a particular block of a
particular executable; for example, the block containing the session-key
generation code in the Netscape executable. It is then able to forge a reply
from the NFS server and transmit it to the client. If the forged packet reaches
the client before the legitimate reply, it is accepted and the legitimate reply
is discarded as a duplicate.

There is obviously a race condition between the injection of the forged
response and the true response. Since the attacking software is focused solely
on this task, while the fileserver is certainly servicing requests from many
clients, it stands a very good chance of winning the race. We have observed
that the attacking software wins the race a large fraction of the time.

Given this ability it becomes possible to compromise the security features of
any executable loaded from the network. We have examined the Netscape v1.1N
executable and located the code that selects the session key. By patching only
4 bytes we were able to cause the selection of a predictable session key every
time the browser engages in the SSL protocol. It is then trivial to snoop and
decrypt all traffic from the browser to secure servers, obtaining credit card
numbers or other private information.

Since this is really an attack on the client, it is not limited to the Netscape
browser. On the contrary, it is extremely widely applicable. An appropriate
patch to the Kerberos kinit executable makes possible the compromise of any
passwords entered by users, and therefore all of the authentication facilities
provided by Kerberos.

In many environments, including our own here at UC Berkeley, all the Kerberos
application binaries are served from an NFS server. This represents a major
flaw in security as our attack demonstrates. Having authenticated file services
(kerberized NFS or AFS) is useless if the integrity of the kinit executable
cannot be ensured (most easily by obtaining it from local disk).

However, making local copies of crucial binaries is not sufficient in the face
of a more serious set of variants on the NFS spoofing attack. The spoofing
software can be placed as before, in a position to snoop requests to the NFS
server. As clients issue a lookup filehandle request the spoofing software can
return the handle to a different executable and also forge its attributes. By
tricking users into executing code that is setuid root, unlimited access to the
client's workstation can be obtained easily.

It is possible to mount NFS partitions so that setuid root executables will not
be honored by the client. Still, the spoofing software can make arbitrary NFS
filehandle lookup requests succeed, and substitute a trojan of some sort. The
attacker could cause misspellings of commonly executed commands to appear to
succeed, or could spoof other files that are trusted by the operating system.
For example, the user's .login file is a natural and easy target from which to
leverage further damage.

This implies that it is unsafe to execute any program obtained via an insecure
channel to an NFS server, no matter what the privilege level of the client
user.

Neither is it limited to NFS or file-serving protocols in particular. Protocols
based on TCP, rather than UDP, are just as vulnerable. It is possible to hijack
non-authenticated TCP connections, although it is somewhat more complicated.

Attacks based on spoofing traffic coming from the distribution site of popular
software packages is also possible. Berkeley, for example, is a mirror site for
the Netscape browser. Any student with promiscuous network access on a machine
between the ftp server and the main link to the larger Internet could have
installed similar patching software to patch the huge number of copies of the
binary that were retrieved from server.berkeley.edu.

More mundane attacks based on trojan horses or viruses remain viable today.
These attacks must exploit some other weakness in a system's security to
infiltrate, but once in place they can perform patches to local binaries to
fully compromise a system. Previously such attacks were mostly motived only by
ego or malice; it is now more valuable to compromise a client invisibly, so
that the user believes the system is secure. Thus, unlike traditional viruses,
the new strains will aim to have no visible effect on the system, thus making
them difficult to detect and easy to spread unintentionally. Our patch of
Netscape has this flavor.

We realize that it is impossible to eliminate all security holes; one can
always question whether it is safe to trust the hardware, or whether outside
channels used for communication of public keys or checksums are truly secure,
etc. Fortunately, in practice it should suffice to handle far less than all of
these risks. We hope to have demonstrated one gaping hole in practical security
today, and to have highlighted the problem of the trusted endpoint.

There is one simple step that we can suggest that would go a long way towards
improving the security of endpoints. Increasing the practice of software
providers widely publishing cryptographically secure checksums of their
executables would be extremely helpful. A small amount of paranoia and care
must be applied to securing the executables used in the verification process. A
read-only floppy disk would be appropriate to hold the verification software,
for example.

We are concerned that security on users' workstations and PCs is currently
insufficient. When real money is at stake, endpoint security must withstand
greater scrutiny. In summary, protecting the communications channel doesn't
help if the endpoints can be subverted. We implemented and discussed several
related attacks that replace legitimate programs by compromised versions. Until
we can trust every program that executes between the time we boot and the time
we finish the secure protocol, we cannot reliably authenticate anything. Today
there is no basis for this trust.

Eric Brewer, brewer@cs.berkeley.edu
Paul Gauthier, gauthier@cs.berkeley.edu
Ian Goldberg, iang@cs.berkeley.edu
David Wagner, daw@cs.berkeley.edu

A copy of this post is available as
http://http.cs.berkeley.edu/~gauthier/endpoint-security.html