Attacker Value
High
(2 users assessed)
Exploitability
High
(2 users assessed)
User Interaction
Unknown
Privileges Required
Unknown
Attack Vector
Unknown
2

CVE-2019-0232

Disclosure Date: April 15, 2019 •
CVE-2019-0232
Exploited in the Wild
Reported by gwillcox-r7
View Source Details
Add MITRE ATT&CK tactics and techniques that apply to this CVE.

Description

When running on Windows with enableCmdLineArguments enabled, the CGI Servlet in Apache Tomcat 9.0.0.M1 to 9.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93 is vulnerable to Remote Code Execution due to a bug in the way the JRE passes command line arguments to Windows. The CGI Servlet is disabled by default. The CGI option enableCmdLineArguments is disable by default in Tomcat 9.0.x (and will be disabled by default in all versions in response to this vulnerability). For a detailed explanation of the JRE behaviour, see Markus Wulftange’s blog (https://codewhitesec.blogspot.com/2016/02/java-and-command-line-injections-in-windows.html) and this archived MSDN blog (https://web.archive.org/web/20161228144344/https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/).

Add Assessment

1
Technical Analysis

Background

Apache Tomcat is an open source implementation of the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies. It powers numerous large-scale, mission-critical web applications across a diverse range of industries and organizations.

The Common Gateway Interface (CGI) defines a way for a web server to interact with external content-generating programs, which are often referred to as CGI programs. Within Tomcat, CGI support is disabled by default, but can be manually added in the configuration file.

One of the configurations for the CGI servlet is enableCmdLineArguments, which allows command line arguments from the query string, but can be abused to inject system commands in order to gain remote code execution.

Vulnerable Setup

The following versions of Apache Tomcat on Windows are effected:

  • 9.0.0.M1 to 9.0.17
  • 8.5.0 to 8.5.39
  • 7.0.0 to 7.0.93

Since enableCmdLineArguments isn’t enabled by default, the following code needs to be added in the conf/web.xml file:

<servlet>
<servlet-name>cgi</servlet-name>
<servlet-class>org.apache.catalina.servlets.CGIServlet</servlet-class>
<init-param>
  <param-name>cgiPathPrefix</param-name>
  <param-value>WEB-INF/cgi</param-value>
</init-param>
<init-param>
  <param-name>executable</param-name>
  <param-value></param-value>
</init-param>
<init-param>
  <param-name>enableCmdLineArguments</param-name>
  <param-value>true</param-value>
</init-param>
<load-on-startup>5</load-on-startup>
</servlet>

Also:

<servlet-mapping>
<servlet-name>cgi</servlet-name>
<url-pattern>/cgi/*</url-pattern>
</servlet-mapping>

Finally, a script should be added in the webapps\ROOT\WEB-INF\cgi directory, which is the trigger for the CGI servlet:

@echo off
echo Content-Type: text/plain
echo.
echo Hello, World!

For convenience, a vulnerable setup of Apache Tomcat can be downloaded here. It was also used during the analysis on a x64 Windows 10 with JDK 8 installed.

Vulnerability Analysis

Static Code Analysis

In Apache Tomcat, CGI support is handled by the CGIServlet class, which can be found in the lib/catalina.jar file. You can easily find this by grepping for CGISeverlet as the keyword.

CGIServlet is a subclass of the abstract HttpServlet class, which is within the Java API. The way you want to start reading this code is by looking at the service method, which will tell you to go down to doGet, so let’s start with doGet:

protected void doGet(HttpServletRequest req, HttpServletResponse res)
        throws ServletException, IOException {

    CGIEnvironment cgiEnv = new CGIEnvironment(req, getServletContext());

    if (cgiEnv.isValid()) {
        CGIRunner cgi = new CGIRunner(cgiEnv.getCommand(),
                                      cgiEnv.getEnvironment(),
                                      cgiEnv.getWorkingDirectory(),
                                      cgiEnv.getParameters());

        if ("POST".equals(req.getMethod())) {
            cgi.setInput(req.getInputStream());
        }
        cgi.setResponse(res);
        cgi.run();
    } else {
        res.sendError(404);
    }

    if (log.isTraceEnabled()) {
        String[] cgiEnvLines = cgiEnv.toString().split(System.lineSeparator());
        for (String cgiEnvLine : cgiEnvLines) {
            log.trace(cgiEnvLine);
        }

        printServletEnvironment(req);
    }
}

The first thing that happens in the doGet method is creating a new instance of CGIEnvironment. The constructor of the class looks like this:

protected CGIEnvironment(HttpServletRequest req,
                         ServletContext context) throws IOException {
    setupFromContext(context);
    setupFromRequest(req);

    this.valid = setCGIEnvironment(req);

    if (this.valid) {
        workingDirectory = new File(command.substring(0,
              command.lastIndexOf(File.separator)));
    } else {
        workingDirectory = null;
    }
}

We see the first argument is an HttpServletRequest, which is extra interesting because since it’s an HTTP request, it implies there are user-controlled inputs. There are two methods that need the HTTP request: setupFromRequest, and setCGIEnvironment. Let’s take a look at the first:

protected void setupFromRequest(HttpServletRequest req)
        throws UnsupportedEncodingException {

    boolean isIncluded = false;

    // Look to see if this request is an include
    if (req.getAttribute(
            RequestDispatcher.INCLUDE_REQUEST_URI) != null) {
        isIncluded = true;
    }
    if (isIncluded) {
        this.contextPath = (String) req.getAttribute(
                RequestDispatcher.INCLUDE_CONTEXT_PATH);
        this.servletPath = (String) req.getAttribute(
                RequestDispatcher.INCLUDE_SERVLET_PATH);
        this.pathInfo = (String) req.getAttribute(
                RequestDispatcher.INCLUDE_PATH_INFO);
    } else {
        this.contextPath = req.getContextPath();
        this.servletPath = req.getServletPath();
        this.pathInfo = req.getPathInfo();
    }
    // If getPathInfo() returns null, must be using extension mapping
    // In this case, pathInfo should be same as servletPath
    if (this.pathInfo == null) {
        this.pathInfo = this.servletPath;
    }

    // If the request method is GET, POST or HEAD and the query string
    // does not contain an unencoded "=" this is an indexed query.
    // The parsed query string becomes the command line parameters
    // for the cgi command.
    if (enableCmdLineArguments && (req.getMethod().equals("GET")
        || req.getMethod().equals("POST") || req.getMethod().equals("HEAD"))) {
        String qs;
        if (isIncluded) {
            qs = (String) req.getAttribute(
                    RequestDispatcher.INCLUDE_QUERY_STRING);
        } else {
            qs = req.getQueryString();
        }
        if (qs != null && qs.indexOf('=') == -1) {
            StringTokenizer qsTokens = new StringTokenizer(qs, "+");
            while ( qsTokens.hasMoreTokens() ) {
                cmdLineParameters.add(URLDecoder.decode(qsTokens.nextToken(),
                                      parameterEncoding));
            }
        }
    }
}

The first block of the code about “include” can be skipped because that’s not what our request would be, so we want to focus on the second block:

if (enableCmdLineArguments && (req.getMethod().equals("GET")
                               || req.getMethod().equals("POST") || req.getMethod().equals("HEAD"))) {
  String qs;
  if (isIncluded) {
    qs = (String) req.getAttribute(
      RequestDispatcher.INCLUDE_QUERY_STRING);
  } else {
    qs = req.getQueryString();
  }
  if (qs != null && qs.indexOf('=') == -1) {
    StringTokenizer qsTokens = new StringTokenizer(qs, "+");
    while ( qsTokens.hasMoreTokens() ) {
      cmdLineParameters.add(URLDecoder.decode(qsTokens.nextToken(),
                                              parameterEncoding));
    }
  }
}

The first thing that gets checked in the if condition is the enableCmdLineArguments variable, which is also mentioned in the advisory. By default, this option is set to false:

private boolean enableCmdLineArguments = false;

In the init function of CGIServlet, it is also clear for us that the setting needs to be configured in the config file in order to get loaded in the code:

if (getServletConfig().getInitParameter("enableCmdLineArguments") != null) {
    enableCmdLineArguments =
            Boolean.parseBoolean(config.getInitParameter("enableCmdLineArguments"));
}

As the advisory and the code describe, when enableCmdLineArguments is enabled and the request is either GET, POST, or HEAD, we basically reach this part of the code:

qs = req.getQueryString();

Once the query string is loaded, that is normalized into command line parameters:

if (qs != null && qs.indexOf('=') == -1) {
  StringTokenizer qsTokens = new StringTokenizer(qs, "+");
  while ( qsTokens.hasMoreTokens() ) {
    cmdLineParameters.add(URLDecoder.decode(qsTokens.nextToken(),
                                            parameterEncoding));
  }
}

Back to the doGet method, after the command line parameters are loaded. We are at this block of code:

CGIRunner cgi = new CGIRunner(cgiEnv.getCommand(),
                              cgiEnv.getEnvironment(),
                              cgiEnv.getWorkingDirectory(),
                              cgiEnv.getParameters());

if ("POST".equals(req.getMethod())) {
  cgi.setInput(req.getInputStream());
}
cgi.setResponse(res);
cgi.run();

CGIRunner is a class that actually executes the CGI program, which occurs in the run method. The run method is really big, so it would be too much code to post but basically this is where code execution is gained:

rt = Runtime.getRuntime();
proc = rt.exec(
  cmdAndArgs.toArray(new String[cmdAndArgs.size()]),
  hashToStringArray(env), wd);

The run method also handles the program output that is returned to the HTTP client, which is another bonus for the attacker.

Dynamic Analysis

To verify this execution flow, we can use IntelliJ to set up some breakpoints to observe. To do this, first add the following to the bin/startup.bat file (at around line 21):

set JAVA_OPTS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n

Next, start that file. There will be two important ports running: 4000 is the debugging port, and 8080 is the Tomcat server where the CGI program is served. Connect port 4000 with IntelliJ.

There are many possible methods we can add breakpoints for, but since we have seen that the Java’s Runtime class is used to execute the CGI program, we can add a breakpoint right there:

java.lang.Runtime.exec

When we visit the CGI program, the breakpoint should trigger with the following backtrace:

exec:617, Runtime (java.lang)
run:1579, CGIServlet$CGIRunner (org.apache.catalina.servlets)
doGet:575, CGIServlet (org.apache.catalina.servlets)
service:538, CGIServlet (org.apache.catalina.servlets)
service:741, HttpServlet (javax.servlet.http)
internalDoFilter:231, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
doFilter:53, WsFilter (org.apache.tomcat.websocket.server)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
invoke:200, StandardWrapperValve (org.apache.catalina.core)
invoke:96, StandardContextValve (org.apache.catalina.core)
invoke:490, AuthenticatorBase (org.apache.catalina.authenticator)
invoke:139, StandardHostValve (org.apache.catalina.core)
invoke:92, ErrorReportValve (org.apache.catalina.valves)
invoke:678, AbstractAccessLogValve (org.apache.catalina.valves)
invoke:74, StandardEngineValve (org.apache.catalina.core)
service:343, CoyoteAdapter (org.apache.catalina.connector)
service:408, Http11Processor (org.apache.coyote.http11)
process:66, AbstractProcessorLight (org.apache.coyote)
process:834, AbstractProtocol$ConnectionHandler (org.apache.coyote)
doRun:1415, NioEndpoint$SocketProcessor (org.apache.tomcat.util.net)
run:49, SocketProcessorBase (org.apache.tomcat.util.net)
runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
run:61, TaskThread$WrappingRunnable (org.apache.tomcat.util.threads)
run:748, Thread (java.lang)

For the extra file, we can also attach WinDBG to java.exe. You may have multiple java.exe for whatever reason, just make sure you’re attaching the one that listens on port 8080. In WinDBG, add this breakpoint:

bu KERNELBASE!CreateProcessW

Again, when you visit the CGI program, you should see that Java is using CreateProcessW to launch the CGI program:

0:021> r
rax=0000000000000001 rbx=0000000008000400 rcx=0000000000000000
rdx=0000000017bbdd80 rsi=0000000017f869f8 rdi=ffffffffffffff00
rip=00007ffd8d423dd0 rsp=0000000019d7dee8 rbp=0000000019d7e050
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
r11=0000000019d7df48 r12=0000000000000000 r13=0000000000000064
r14=00000000176d8980 r15=0000000000000060
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
KERNELBASE!CreateProcessW:
00007ffd`8d423dd0 4c8bdc          mov     r11,rsp
0:021> du rdx
00000000`17bbdd80  "C:\Users\sinn3r\Desktop\apache-t"
00000000`17bbddc0  "omcat-9.0.17\webapps\ROOT\WEB-IN"
00000000`17bbde00  "F\cgi\test.bat &echo CQdjFeaVZh"

It looks we are calling test.bat (the CGI program) with an arbitrary echo command. At this point, we have proven the exploitability of the vulnerability.

Log in to Add Reply
1
Ratings
  • Attacker Value
    High
  • Exploitability
    High
Technical Analysis

Given that the enableCmdLineArguments setting is configured, it looks fairly easy to get code execution. This should definitely be patched.

Log in to Add Reply
CVSS V3 Severity and Metrics
Base Score:
None
Impact Score:
Unknown
Exploitability Score:
Unknown
Vector:
Unknown
Attack Vector (AV):
Unknown
Attack Complexity (AC):
Unknown
Privileges Required (PR):
Unknown
User Interaction (UI):
Unknown
Scope (S):
Unknown
Confidentiality (C):
Unknown
Integrity (I):
Unknown
Availability (A):
Unknown

General Information

Offensive Application
Unknown
Utility Class
Unknown
Ports
Unknown
OS
Unknown
Vulnerable Versions
Tomcat 9.0.0.M1 to 9.0.17
Tomcat 8.5.0 to 8.5.39
Tomcat 7.0.0 to 7.0.93
Prerequisites
Unknown
Discovered By
Unknown
PoC Author
Unknown
Metasploit Module
Unknown
Reporter
Unknown

Vendors

  • apache

Products

  • tomcat,
  • tomcat 9.0.0

Exploited in the Wild

Reported by:

References

Canonical
CVE-2019-0232 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0232)
BID-107906 (http://www.securityfocus.com/bid/107906)
Advisory
[tomcat-users] 20190410 [SECURITY] CVE-2019-0232 Apache Tomcat Remote Code Execution on Windows (https://lists.apache.org/thread.html/5f297a4b9080b5f65a05bc139596d0e437d6a539b25e31d29d028767@%3Cannounce.tomcat.apache.org%3E)
[tomcat-dev] 20190415 svn commit: r1857582 [18/22] - in /tomcat/site/trunk: docs/ xdocs/stylesheets/ (https://lists.apache.org/thread.html/1dd0a59c1295cc08ce4c9e7edae5ad2268acc9ba55adcefa0532e5ba@%3Cdev.tomcat.apache.org%3E)
[ofbiz-commits] 20190415 svn commit: r1857587 - in /ofbiz: ofbiz-framework/branches/release18.12/build.gradle ofbiz-plugins/branches/release18.12/example/build.gradle (https://lists.apache.org/thread.html/673b6148d92cd7bc99ea2dcf85ad75d57da44fc322d51f37fb529a2a@%3Ccommits.ofbiz.apache.org%3E)
[tomcat-dev] 20190415 svn commit: r1857582 [17/22] - in /tomcat/site/trunk: docs/ xdocs/stylesheets/ (https://lists.apache.org/thread.html/3d19773b4cf0377db62d1e9328bf9160bf1819f04f988315086931d7@%3Cdev.tomcat.apache.org%3E)
[ofbiz-commits] 20190415 svn commit: r1857586 - in /ofbiz: ofbiz-framework/trunk/build.gradle ofbiz-plugins/trunk/example/build.gradle (https://lists.apache.org/thread.html/a6c87a09a71162fd563ab1c4e70a08a103e0b7c199fc391f1c9c4c35@%3Ccommits.ofbiz.apache.org%3E)
[tomcat-dev] 20190415 svn commit: r1857582 [19/22] - in /tomcat/site/trunk: docs/ xdocs/stylesheets/ (https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3@%3Cdev.tomcat.apache.org%3E)
[ofbiz-commits] 20190415 svn commit: r1857588 - in /ofbiz: ofbiz-framework/branches/release17.12/build.gradle ofbiz-plugins/branches/release17.12/example/build.gradle (https://lists.apache.org/thread.html/52ffb9fbf661245386a83a661183d13f1de2e5779fa23837a08e02ac@%3Ccommits.ofbiz.apache.org%3E)
[ofbiz-notifications] 20190415 [jira] [Commented] (OFBIZ-10920) Update Tomcat to 9.0.18 due to CVE-2019-0232 (https://lists.apache.org/thread.html/dd4b325cdb261183dbf5ce913c102920a8f09c26dae666a98309165b@%3Cnotifications.ofbiz.apache.org%3E)
[ofbiz-notifications] 20190415 [jira] [Closed] (OFBIZ-10920) Update Tomcat to 9.0.18 due to CVE-2019-0232 (https://lists.apache.org/thread.html/96849486813a95dfd542e1618b7923ca945508aaf4a4341f674d83e3@%3Cnotifications.ofbiz.apache.org%3E)
https://www.synology.com/security/advisory/Synology_SA_19_17
https://security.netapp.com/advisory/ntap-20190419-0001
[tomcat-dev] 20190421 svn commit: r1857901 - in /tomcat/site/trunk: docs/security-7.html docs/security-8.html docs/security-9.html xdocs/security-7.xml xdocs/security-8.xml xdocs/security-9.xml (https://lists.apache.org/thread.html/f4d48b32ef2b6aa49c8830241a9475da5b46e451f964b291c7a0a715@%3Cdev.tomcat.apache.org%3E)
https://www.broadcom.com/support/fibre-channel-networking/security-advisories/brocade-security-advisory-2019-784
20190504 RCE in CGI Servlet - Apache Tomcat on Windows - CVE-2019-0232 (http://seclists.org/fulldisclosure/2019/May/4)
https://access.redhat.com/errata/RHSA-2019:1712
[announce] 20200131 Apache Software Foundation Security Report: 2019 (https://lists.apache.org/thread.html/r6d03e45b81eab03580cf7f8bb51cb3e9a1b10a2cc0c6a2d3cc92ed0c@%3Cannounce.apache.org%3E)
[tomcat-dev] 20200203 svn commit: r1873527 [24/30] - /tomcat/site/trunk/docs/ (https://lists.apache.org/thread.html/r6ccee4e849bc77df0840c7f853f6bd09d426f6741247da2b7429d5d9@%3Cdev.tomcat.apache.org%3E)
[tomcat-dev] 20200203 svn commit: r1873527 [25/30] - /tomcat/site/trunk/docs/ (https://lists.apache.org/thread.html/r3bbb800a816d0a51eccc5a228c58736960a9fffafa581a225834d97d@%3Cdev.tomcat.apache.org%3E)
[tomcat-dev] 20200213 svn commit: r1873980 [27/34] - /tomcat/site/trunk/docs/ (https://lists.apache.org/thread.html/r9136ff5b13e4f1941360b5a309efee2c114a14855578c3a2cbe5d19c@%3Cdev.tomcat.apache.org%3E)
[tomcat-dev] 20200213 svn commit: r1873980 [28/34] - /tomcat/site/trunk/docs/ (https://lists.apache.org/thread.html/raba0fabaf4d56d4325ab2aca8814f0b30a237ab83d8106b115ee279a@%3Cdev.tomcat.apache.org%3E)
[tomcat-dev] 20200213 svn commit: r1873980 [29/34] - /tomcat/site/trunk/docs/ (https://lists.apache.org/thread.html/r48c1444845fe15a823e1374674bfc297d5008a5453788099ea14caf0@%3Cdev.tomcat.apache.org%3E)
Miscellaneous
https://codewhitesec.blogspot.com/2016/02/java-and-command-line-injections-in-windows.html
https://web.archive.org/web/20161228144344/https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way
https://blog.trendmicro.com/trendlabs-security-intelligence/uncovering-cve-2019-0232-a-remote-code-execution-vulnerability-in-apache-tomcat
https://wwws.nightwatchcybersecurity.com/2019/04/30/remote-code-execution-rce-in-cgi-servlet-apache-tomcat-on-windows-cve-2019-0232
http://packetstormsecurity.com/files/153506/Apache-Tomcat-CGIServlet-enableCmdLineArguments-Remote-Code-Execution.html
https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html
https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html
https://www.oracle.com/security-alerts/cpujan2020.html

Additional Info

Authenticated
Unknown
Exploitable
Unknown
Reliability
Unknown
Stability
Unknown
Available Mitigations
Unknown
Shelf Life
Unknown
Userbase/Installbase
Unknown
Patch Effectiveness
Unknown
Technical Analysis