Possibility of vulnerability on Gatling logging component LogBack

Hi,

I’m posting this question here to discuss the possibility, not to prove the existence of the vulnerability in logging system used by Gatling.

I’ve seen that Gatling uses LogBack as logging system, and in this blog post on LogBack news they are talking about it: http://logback.qos.ch/news.html

Don’t we have to upgrade Gatling to use newer version of LogBack ?

Depending on the use case, if the vunerability is confirmed, there is possible threat when the logBack is activated, and for me i’m using it.

This is the link to the ticket for the work in progress being done on the subject: https://jira.qos.ch/browse/LOGBACK-1591

Regards,

Ouael Boufaden

This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Unauthorized publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited.

Let’s respect the environment together. Only print this message if necessary.

Please read the logback CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-42550

an attacker with the required privileges to edit configurations files could craft a malicious configuration allowing to execute arbitrary code loaded from LDAP servers

Severity is ranked 6.6, which is nowhere like the 10.0 of log4j’s Log4Shell.
In order to be able to use this vulnerability, an attacker needs to have write access to your logback config file. It’s your responsibility to secure it. Basically, it means that your source code repository or the server you run Gatling on are compromised. If so, you have way more critical problems than just logback.

The next release of Gatling will ship the latest version of logback, as we always do for all our dependencies.
But this vulnerability is not critical enough to trigger a hot patch from us, moreover as you can easily upgrade the logback version on your side.

Hi Stéphane,

Thank you for your response.

I was looking for an expert insight on the matter, i’m not an expert, that’s why i tried to post my question here.
I’ve already read the LogBack CVE, and i’ve seen that versions affected by this vulnerability, regardless of it’s severity, are versions of LogBack prior to 1.2.9 and in Gatling core i found that we are using 1.2.3 that’s whay i did post my question.
The severity of the vulnerability or the way it could be used, are not the subject of my question, i was just trying to have some insight on the matter, the Gatling use of LogBack version 1.2.3 (Gatling version 3.6.1) and it’s possible risks.

I thank you again for your response and i wanted to have some informations, if it’s possible, about the timeline for the next Gatling release that will use LogBack 1.2.9 or higher.

Regards,

Ouael Boufaden

Making things clear: Gatling is not affected by this CVE, unless you’re the one doing something weird and unlikely such as enabling a JMS appender and such.

the Gatling use of LogBack version 1.2.3 (Gatling version 3.6.1)

Well, if you’re really concerned about versions of libraries that have CVEs (even though neither critical nor working in Gatling’s context), you should first upgrade to 3.7.2. See Netty’s release note for past CVEs.

timeline for the next Gatling release that will use LogBack 1.2.9 or higher

I can’t say for now.
I expect Java logging libraries to be under scrutiny for vulnerabilities in the short future, and lots of patches being published. I don’t see a point in panicking and releasing over and over again while you’re not really affected. Generally speaking, logback is safe. We’ll probably wait until the dust settles unless something critical is discovered.

Currently, the major blocker is that the Sonatype gateway to publish on maven central is completely saturated with people trying to publish new releases of their libraries with log4j 2 upgrades (and failing, and trying again, and again). We can’t publish under those conditions.

Thank you very much Stéphane. This answers my questions.

Regards,

Ouael Boufaden