Insecure version of Jetty on SemanticTurkey ?

[db...@essex.ac.uk]

Hi. we recently had a penetration test conducted on our servers and one issue that was reported on VocBench 11.4.2 is that the version of Jetty is 9.4.3 has known vulnerabilities (cf. https://www.cvedetails.com/vulnerability-list/vendor_id-10410/product_id-34824/version_id-597125/Eclipse-Jetty-9.4.3.html )

We run a public VocBencg front-end HTTP server on Tomcat 8.5 which connects internally to a different SemanticTurkey server (which contains Jetty 9.4.3)

My questions are:

 (1) is there a significant risk here, as the SemanticTurkey server is internal and not exposed outside of our firewall?

(2) Are there any plans to upgrade the version of Jetty in future versions of VocBench.

Many thanks.

[Armando Stellato]

Hi,

 

about point 1, if your front end is public, then I suppose that the requests can be sent to the server somehow from outside. However, in general, I can tell that CVEs about Jetty were reviewed and either secured or considered safe after analysis. For instance, concerning CVE-2023-44487, HTTP/2 is not even enabled.

 

About point 2, yes, a forthcoming version of VocBench will have a completely renewed architecture. The reason for the wait is data compatibility. We are waiting for an update routine that will be incorporated into a new version of GraphDB. We are also fixing some bugs as the complete reengineering of part of the backend required heavily testing all the applications and fixing a few bugs. In this version lot of old dependencies will be updated or even completely replaced.

 

Hope this helps!

 

Kind Regards,

 

Armando

 

--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/2ec30ed7-0294-427b-a407-8cf9a80cf7c9n%40googlegroups.com.

[Armando Stellato]

I reread incidentally the previous msg, and I think it is worth adding a little corrigendum

 

The point is not data compatibility, rather repository compatibility. GraphDB repositories are portable from version 9.x to 10.x. To ensure this, there are little update routines running on GDB 10.x that account for some small changes in the repository configuration. However, as we are extensively using the RDF4J sail mechanism allowing for extensions to the triple store, we noticed that configurations featuring such extensions have not been properly ported. So we liaised with OntoText in order to fix this issue.

 

Kind Regards,

 

Armando

To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/AS8PR09MB4982CABE41EFA782F8FAA9AFC7752%40AS8PR09MB4982.eurprd09.prod.outlook.com.

[Will T]

Hi Armando,

I work with the OP and am responsible for cyber security at our organisation. We are regularly audited for information security compliance so I need to explain to assessors in more detail about these detected vulnerabilities. 

We are always asked to show evidence of vulnerability mitigation - would you be able to share any records you have of the CVE review and analysis/fix that you referred to above?

Many thanks,

Will

[Armando Stellato]

Dear Will,

 

We have a support contract with the OP (to clarify: if by “OP” you mean Publications Office of the EU).

 

We produce reports each time a new version is released and both automatic dependency-vulnerability analysis and code analysis are conducted and then discussed by us for the open points.

The reports are, however, not shareable as per policy of the OP, but you should have access to them (again, if we are talking about the  same organization :-) )

 

Kind Regards,

 

Armando

 

To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/e491e414-7a29-4bbb-8902-58f5c79270c0n%40googlegroups.com.

[Joeli Takala]

Hi,

Regarding the vulnerable jetty versions, one detail of hardening the application during the install is modifying the jetty configuration like this.

vocbench-folder/etc/jetty.xml :
<Set name="sendServerVersion">false</Set>


_______
Joeli