If you are using DefaultServlet or ResourceHandler with indexing/listing, then you are vulnerable to a variant of XSS behaviors surrounding the use of injected HTML element attributes on the parent directory link. We recommend disabling indexing/listing or upgrading to a non-vulnerable version.

To disable indexing/listing:

If using the DefaultServlet (provided by default on a standard WebApp/WAR), you’ll set the dirAllowed init-param to false.

This can be controlled in a few different ways:

Directly in your WEB-INF/web.xml

Add/edit the following entry …

Alternatively, you’ll edit your configured web descriptor default (usually declared as webdefault.xml) or your web descriptor override-web.xml.

The web defaults descriptor can either be configured at the WebAppProvider level and will be applied to all webapps being deployed, or at the individual webapp.

For the WebAppProvider level, you have several choices.

If you are managing the XML yourself, you can set the Default Descriptor to your edited version:

Note: the WebAppProvider cannot set the override-web.xml for all webapps.

If you are using the jetty.home/jetty.base module system and associated start.d/*.ini or start.ini, then you should be able to just point to your specifically edited webdefault.xml.

Example:

If you are using a webapp specific deployment XML, such as what’s found in ${jetty.base}/webapps/<appname>.xml then you’ll edit the XML to point to your specific webdefault.xml or override-web.xml:

Reminder, the load order for the effective web descriptor is …

  1. Default Descriptor – webdefault.xml
  2. WebApp Descriptor – WEB-INF/web.xml
  3. Override Descriptor – override.xml

If using the ResourceHandler (such as in an embedded-jetty setup), you’ll use the ResourceHandler.setDirAllowed(false) method.

Additionally, we discovered that usages of DefaultHandler were susceptible to a similar leak of information. If no webapp was mounted on the root “/” namespace, a page would be generated with links to other namespaces. This has been the default behavior in Jetty for years, but we have removed this to safeguard data.

As a result of these CVEs, we have released new versions for the 9.2.x, 9.3.x, and 9.4.x branches. The most up-to-date versions of all three are as follows, and are available both on the Jetty website and Maven Central.

Versions affected:

  • 9.2.27 and older (now EOL)
  • 9.3.26 and older
  • 9.4.16 and older

Resolved:

  • 9.2.28.v20190418
  • 9.3.27.v20190418
  • 9.4.17.v20190418

 

Indexing/Listing Vulnerability in Jetty

2 thoughts on “Indexing/Listing Vulnerability in Jetty

  • May 1, 2019 at 4:07 am
    Permalink

    does jetty on JDK 11 still benefit from conscrypt provider?
    Could constrypt be used as workaround for above issue?

    Reply
    • May 2, 2019 at 11:10 am
      Permalink

      Jetty on JDK 11 still benefits from the Conscrypt provider because of its better performance.
      The issue reported here is independent from Conscrypt.

      Reply

Leave a Reply to simon Cancel reply

Your email address will not be published. Required fields are marked *