Message-ID: <87vf2s3pe9.fsf@deneb.enyo.de>
Date: Sat Jul 30 23:33:40 2005
From: fw at deneb.enyo.de (Florian Weimer)
Subject: The Java applet sandbox and stateful firewalls

The Java/Firewall vulnerability
===============================

Current version: <http://www.enyo.de/fw/security/java-firewall/>

The Java sandbox for applets and stateful firewalls interact in a
surprising way. As a result, external hosts can initiate TCP
connections to supposedly protected network services.

* Attack Requirements

This is a passive attack. The attacker must lure the victim to a
carefully crafted web page. The victim's web browser must download and
execute the embedded Java applet. The victim's computer must offer
some vulnerable networking service, and a stateful firewall must
prevent access to this service from the Internet.  Impact

An attacker can gain access to potentially vulnerable network services
which are located behind firewall and/or NAT devices, so that direct
access is impossible.

* Severity

This is a passive vulnerability which can only be used as a stepstone
for further attacks. As a result, the risk posed by this vulnerability
alone is fairly low.

* Technical Description

The attack is carried out as follows.

   1. The attacker creates a specifically crafted web site.

   2. She lures the victim to visit this web site.

   3. The victim's browser downloads the applet and begins to run it.

   4. The applet initiates a TCP connection back to the originating
      web server, on port 21 (used by FTP, RFC 959). This connection
      is permitted according to the standard Java sandbox model for
      applets.  5.

      A FTP server on the same machine that hosts the originating web
      site answers.

   6. The applet continues to pose as an FTP client, logs in and
      issues an FTP PORT command, which prepares an active FTP
      connection. The TCP port specified in the command refers to some
      existing TCP service, such as 445/TCP (SMB over TCP) or 1433/TCP
      (Microsoft SQL Server, MSDE). This port is chosen by the
      attacker.

   7. The firewall between the attacker and the victim recognizes this
      command and prepares to open a second connection for the FTP
      data transfer.

   8. The applet issues a FTP command which requests the data
      transfer, for example a LIST command.

   9. The attacker uses her server to initiate a TCP connection to the
      port indicated in the PORT on the victim host. The firewall
      passes through the connection, assuming that it is a legitimate
      FTP data transfer.

This attack exploits the fact that the Java security model for applet
assumes that arbitrary TCP connections back to the server pose no
risks. However, the presence of stateful firewalls or NAT devices with
heuristic FTP protocol modules between the involved hosts invalidates
this assumption because TCP connections back to the originating
servers do have side effects.

This is not an error in the Java implementation or in the firewall
implementation. Both programs implement their respective
specifications. Even the specifications themselves are not inherently
flawed. Only the combination of these two components creates a
vulnerable configuration. This stresses an important point about
secure systems: Security does not compose, and classic
divide-and-conquer approaches do not necessarily result in complete
systems which are secure.

The attack differs from previous attacks using POST requests to ports
such as 21/FTP. Such attacks could be detected by the firewall and
stopped. In contrast, the Java applet could implement a
fully-compliant FTP client, and the firewall cannot tell whether an
FTP data transfer was initiated by a rogue Java applet or a legitimate
FTP client controlled by the user.

* Workarounds

    * Use clients that do not support active client such as Java
      applets.

    * In firewalls, do not use heuristic approaches to stateful
      filtering. Complex protocols should be handled by application
      layer gateways that actually understand the protocols they are
      letting through.

Note that in principle, this vulnerability is not specific to Java or
FTP protocol helpers (see below). A more general approach to eradicate
this problem is therefore necessary.

* Proof of concept

A simple TCP server which emulates FTP and a corresponding Java applet
is provided on the web: <http://www.enyo.de/fw/security/java-firewall/>

* Open questions

Some questions need further examination.

    * Other implementations of mobile code might be used to carry out
      the attack. For example, it could be possible that Flash objects
      can achieve the same effect.

    * The vulnerability is not inherently FTP-related. FTP is used
      here because its active mode is widely used because it is the
      default mode in a widely-used web browser, and stateful filters
      usually implement heuristics to handle such FTP data
      transfers. Other candidate protocols are IRC DCC, Sun and DCE
      RPC, and in particular H.323 and SIP.

    * We only tested one firewalling implementation (a custom-compiled
      Linux 2.6 kernel and an OpenWRT Linux kernel, both with NAT
      enabled). Other firewall implementations might enforce further
      restriction and restrict the data flow on the FTP data
      connection, which slightly mitigates the impact of this
      vulnerability.

    * Maybe it is possible to introduce a method by which Java virtual
      machines can mark outgoing connections initiated by untrusted
      applets. Even though the protocol described in RFC 3514 could be
      used for this purpose, significant code changes are needed, and
      it is not clear if this vulnerability is worth the complexity of
      such a solution.

* Acknowledgments

Bastian Blank wrote the Java applet which demonstrates this
exploitation technology. The applet contains source code copied from
the GNU Classpath project.

* Revisions

2005-07-30 22:00: published

Powered by blists - more mailing lists