Vulnerabilities in Quarkus

[fraserisverycool]

Hello, first time writing here. We've added an owasp dependency checker to our Quarkus project and it tells us that Quarkus has a number of dependencies which fail the check due to multiple critical CVEs. Here is an example:
quarkus-keycloak-authorization-2.14.2, which uses redhat:keycloak:2.14.2, which has multiple CVEs, for example CVE-2022-1245

Is there anything I can do to mitigate these? Are they reported somewhere on the Quarkus website? Any advice is welcome!

[sberyozkin]

@fraserisverycool Hi, these are new Keycloak CVEs, such as GHSA-75p6-52g3-rqc8. You can consider it be false-positives from the Quarkus perspective - these are server-side scoped CVEs which are activated when Keycloak is invoked, example, requested to exchange a token as in the case of GHSA-75p6-52g3-rqc8.
quarkus-keycloak-authorization is a library which only posts a token to Keycloak for it to make authorization decisions - effectively it is a client side only library.
The reason you see it being affected is that quarkus-keycloak-authorization might be depending on the libraries like keycloak-core containing the affected code - this code however is not used.
We have also seen CVEs reported against quarkus-keycloak-authorization, which, after further investigation, proved to be impacting libraries like keycloak-services which quarkus-keycloak-authorization does not even depend upon

HTH

[fraserisverycool]

Thank you for your quick response! Alright, sounds like I can ignore these vulnerabilities with the assumption that the latest version of Quarkus will always be able to mitigate actual critical vulnerabilities. It's a bit of a shame because they cause the checker to fail, so we can't make the check break a build, for example.

[sberyozkin]

Np, Quarkus itself can't mitigate these issues because Quarkus has just nothing to do with these issues, this is a side-effect of a false positive. You can configure the checker to ignore them, see for ex, https://quarkus.io/guides/security#national-vulnerability-database, or the plugin docs directly

[fraserisverycool]

Ah, thank you for the link, I will reconfigure the tool!

[gsmet]

The problem is that the tool you are using sees quarkus-keycloak-authorization and considers it's Keycloak itself. In version 2.14.2 (which is probably not even a valid Keycloak version). Thus it matches vulnerabilities as if we were including Keycloak 2.14.2 - which is not the case, it's Quarkus 2.14.2.Final Keycloak extension.

Just have a look at the column with the values starting with cpe:2.3:. You will see it matches the Keycloak component.

We had this reported numerous times and we also reported the problems to this particular security tooling but they haven't improved on that yet. We can't do anything about it on our side as it's a tooling problem.

So whenever you see that, have a look at the components mentioned and that should help you filter false positives.

[fraserisverycool]

Thank you for your comprehensive response! This is my first time using such a dependency checker, and you're right, it appears to be confusing the version numbers. I've been linked to the Quarkus security guide which shows how to suppress these CVEs in owasp, so it shouldn't be a problem.

[sberyozkin]

Hi @gsmet, the cpe lines related to Keycloak might be just a noise, indeed, but there is a Quarkus CPE there, I tried the other day with the 7.1.1 version and it was all clear for some DB issues which previously were confused as Quarkus issues.
I'll give a try with KC 20.0.1 once it is updated, will report an OWASP plugin issue if necessary

[sberyozkin]

FYI, running OWASP plugin 7.4.3 against this extension on main shows no GHSA-75p6-52g3-rqc8, it does not necessarily mean no OWASP issue plugin exists, but it is also the case that very often the core keycloak packages are affected and quarkus-keycloak-authorization is ending up being falsely flagged