Re: Fuseki 2: Security issue “Information Exposure”

Andy Seaborne Mon, 01 Feb 2016 02:56:55 -0800

On 31/01/16 17:05, A. Soroka wrote:

Just for the record, Andy, do we now have a standard way of determining a 
running version for when it is necessary to answer a question?


I’m thinking here of folks who may have “inherited” a deployed Fuseki install 
and who then run into questions or troubles (it could happen to anyone {grin}), 
and what we can tell them to do if we need to know the version to help them. 
Maybe there is a good place to check in the config directory? Or would we have 
to go inside the WEB-INF/lib jars and look at metadata there?


It is printed as the first line of the server log.

        Andy

---
A. Soroka
The University of Virginia Library

On Jan 31, 2016, at 11:57 AM, Andy Seaborne <[email protected]> wrote:

https://issues.apache.org/jira/browse/JENA-1125

Output of version should only be in developer mode now.
"developer mode" means anything that is not a formal release, i.e. with a 
version number without SNAPSHOT.

   Andy

On 28/01/16 21:03, Andy Seaborne wrote:

If you want to lock down a java-based webapp server, jetty, tomcat,
fuseki whatever, then another starting point is to put it behind a
reverse proxy (httpd, nginx etc), slave the java server to only receive
request from localhost i.e. the reverse proxy.

httpd, nginx have a much greater range of facilities to defend the service.

On 28/01/16 11:36, Massimiliano Ricci wrote:

Dear All,
  for a customer we'd like to use Fuseki 2.3.1. on Linux RedHat as a
standalone server.
Unfortunatelly we've encountered an anomaly of "Information Exposure"
(CWE-200 - http://cwe.mitre.org/data/definitions/200.html), in particular
the Fuseki and JETTY versions are showed. For example, if I submit an
incorrect query, it's shown:

Error 400: ...
Fuseki - version 2.3.1 ....

And in response header:

HTTP/1.1 200 OK
Date: Thu, 28 Jan 2016 10:20:34 GMT
Cache-Control: must-revalidate,no-cache,no-store
Pragma: no-cache
Content-Type: text/plain;charset=utf-8
Content-Length: 31
Server: Jetty(9.3.z-SNAPSHOT)


CWE-200 is about private or useful information to an attacker.

Counting version numbers as sensitive or attack information is debatable
IMO.  At most, it is minor - it's all in the POM files and source code
for open source - and attacking an unknown version is a matter of
running an attack on all possible versions in parallel.

Even the Apache webserver at www.apache.org puts in the version:

  Server: Apache/2.4.7 (Ubuntu)


Why it says "9.3.z-SNAPSHOT" I don't know - this is a known Jetty issue
- the version of Jetty is not a snapshot and it was pulled from maven
central.  Weirdly, current development, same Jetty, prints 9.3.3.v20150827.

The Apache Jena release process will not proceed if a SNAPSHOT is found,
not that maven central has snapshots at all.

In order to don't show the Jetty version I've modified the
"jena-3.0.1-source-release\jena-3.0.1\jena-fuseki2\examples\fuseki-jetty-https.xml":


<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "
http://www.eclipse.org/jetty/configure_9_3.dtd";>

<Configure id="Server" class="org.eclipse.jetty.server.Server">
     <New id="httpConfig"
class="org.eclipse.jetty.server.HttpConfiguration">
       <Set name="sendServerVersion"><Property
name="jetty.httpConfig.sendServerVersion"
deprecated="jetty.send.server.version" default="false" /></Set>
     </New>
</Configure>


but running fuseki:

java -Xmx16384M -jar fuseki-server.jar --jetty-config=fuseki-jetty.xml

--port=8080 --loc=/mytdb /myDataSet
the following exception was raised:
10:36:11 INFO  Server               :: Jetty server config file =
/space/weblogic/apache-jena-fuseki-2.3.1/fuseki-jetty.xml
10:36:11 ERROR Server               :: SPARQLServer: Failed to configure
server: 0
java.lang.ArrayIndexOutOfBoundsException: 0


That means the jetty configuration file has not defined a connector.

If that was the whole file fuseki-jetty.xml then it's incomplete. The
connector is created by <Call name="addConnector"> in the example.

There are examples at:

http://www.eclipse.org/jetty/documentation/current/configuring-connectors.html#jetty-connectors


I used fuseki-jetty-https.xml with only the setting for
name="sendServerVersion" changed and it worked (no Server line for Jetty)

         at
org.apache.jena.fuseki.jetty.JettyFuseki.configServer(JettyFuseki.java:266)

         at
org.apache.jena.fuseki.jetty.JettyFuseki.buildServerWebapp(JettyFuseki.java:222)

         at
org.apache.jena.fuseki.jetty.JettyFuseki.<init>(JettyFuseki.java:91)
         at
org.apache.jena.fuseki.jetty.JettyFuseki.initializeServer(JettyFuseki.java:86)

         at
org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.exec(FusekiCmd.java:358)

         at jena.cmd.CmdMain.mainMethod(CmdMain.java:93)
         at jena.cmd.CmdMain.mainRun(CmdMain.java:58)
         at jena.cmd.CmdMain.mainRun(CmdMain.java:45)
         at
org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.innerMain(FusekiCmd.java:95)

         at org.apache.jena.fuseki.cmd.FusekiCmd.main(FusekiCmd.java:60)
I think because Fuseki is using the wrong version Jetty (9.3.z-SNAPSHOT
instead 9.3.3).


Fuseki at the 2.3.1 release is running with 9.3.3.v20150827

See
https://github.com/apache/jena/blob/jena-3.0.1/jena-fuseki2/pom.xml


For Fuseki version I didn't find any solution.

Could anyone suggest us how to figure out this issue?
There are proprerties to set to avoid it?
Do I have to open an issue on JIRA?

Thanks,
Max


     Andy

Re: Fuseki 2: Security issue “Information Exposure”

Reply via email to