Log4shell - CVE-2021-21985

[micoolpaul]

Hi,

Can Veeam issue a statement if any of their products (thinking AWS/Azure/GCP most likely) are vulnerable to Log4j/CVE-2021-44228?

I’m assuming if they are a normal security patch is all that’ll be required for Apache but would be good for a clear statement!

Thanks,
Michael

[nielsengelen]

We don’t utilise Apache in any of these products so I don’t think there is an issue. I will ask our security team to check it as well for 100% assurance.

[micoolpaul]

Thanks for the response, I thought I’d best ask as we can’t always see the individual components without going digging.

With the severity of this being so bad and the issue so widespread. A confirmation of “no risk” will be brilliant for all of us that will inevitably be questioned about this on Monday (or already are being questioned)

[Vitaliy S.]

A confirmation of “no risk” will be brilliant for all of us that will inevitably be questioned about this on Monday (or already are being questioned)

We don't use Apache in our Veeam Backup for Azure/AWS/GCP products family.

[nmace]

Are there any updates regarding the Veeam for AWS software and the log4j exploit that has been rocking the 'Net the past day or so? The https access for our Veeam instance is locked down via EC2 security groups to only allow https from our company's IP addresses. But I'd like to hear from Veeam if it affected and if it is running the log4j software package.

Thanks.

[Mildur]

Hi nmace
Michael was already asking for all products.
Veeam does not use this software in his products.

Read more about it here

[sbou]

Just to be sure.. This vulnerability is not apache (the webserver) related, it's related the java logging library log4j2 witch is part of the apache foundation.

[micoolpaul]

Hi Sbou,

Correct. Apache have a set of logging services of which Log4j is part of. I wanted to ask the question as you never know what dependencies a product has so thought best to ask and check!

[poulpreben]

Hi all,

Gostev already speculated on this in the weekly digest, and I totally agree that it is unlikely that there are any traces of log4j in Veeam components. However, I wanted to start this thread to track the development of the official statement from the Veeam team. I know our customers would like a final statement for sure

As for Veeam products, while I still need to get the official confirmation from our security team, it's unlikely we're affected because as far as I know we don't use Java in principle. Plus, as it comes to web servers, we're married to Microsoft IIS for our Windows-based apps (VBR/ONE/VSPC) and to nginx for Linux-based (Veeam Backup for AWS/Azure/GCP). The only place I'm aware that uses some Apache components is our SureBackup helper appliance, but that one certainly should not have any traces of Java.

Could you please let us know when this final confirmation is available?

[Mildur]

Hi Prepen

There are already 2 or 3 topics about this in the forums, some of them with statements from veeam.

EDIT Moderator: all links were merged into this thread

Thanks again for the architect training last week. It was really good

[poulpreben]

Thanks Fabian

While I was aware of the thread regarding Backup to Azure, I posted this thread on the general VBR section (which I actually thought was a global thread that listed all questions from all sub-sections as well).

Sorry for the duplicate. I'll let Veeam decide which thread becomes the master, since they're all specific to separate products, while this question spans across their entire portfolio.

[HannesK]

I threw everything together

Log4j is not used according to this list of used open source software https://www.veeam.com/eula-oss.html (which makes sense, we don't use Java)

Yes, some products are missing on that list and we will update that.

And yes, we will also confirm again after final statement from the security team.

[e.rottier]

Hi Prepen

There are already 2 or 3 topics about this in the forums, some of them with statements from veeam.

Log4j/CVE-2021-44228 for VBR
Veeam for AWS & the log4j exploit?
Log4j/CVE-2021-44228 vulnerability?

Thanks again for the architect training last week. It was really good

All those posts are pulled. 'Does not exist'.

The one I personally wonder about is the Agent for Linux.
I have a 'snapshot' folder with a log4j version in it, but I do not have the linux knowledge to say if this is default linux, some user or application or a Veeam component issue.

[HannesK]

yes, I moved one of the topics into this thread (links can break then). the other topics was from one of our employees, so I moved it to the "employee section" of the forums

from my point of view, the answer is already given for the Linux agent in the list I mentioned above

but yes, let's wait for final confirmation please.

[nielsengelen]

Veeam Agent for Linux does not use log4j / apache / java and therefore the folder you see is most likely some user application.

[e.rottier]

yes, I moved one of the topics into this thread (links can break then). the other topics was from one of our employees, so I moved it to the "employee section" of the forums
from my point of view, the answer is already given for the Linux agent in the list I mentioned above
but yes, let's wait for final confirmation please.

Ah thanks, that's nice.

It's quite the big thing in our country at government level atm.

Veeam Agent for Linux does not use log4j / apache / java and therefore the folder you see is most likely some user application.

Thanks for the confirmation!

[Gostev]

Gostev already speculated on this in the weekly digest, and I totally agree that it is unlikely that there are any traces of log4j in Veeam components. However, I wanted to start this thread to track the development of the official statement from the Veeam team. I know our customers would like a final statement for sure

Could you please let us know when this final confirmation is available?

I received the confirmation from our security team that no Veeam products use log4j. Because just as I thought, we don't use Java in principle.

[micoolpaul]

Thanks everyone from Veeam on the swift response to this, especially over the weekend.

[HannesK]

for those who need an "official" document... we created a KB article that states that none of our products is vulnerable to that issue: https://www.veeam.com/kb4254

[replicatius]

Want to also extend thanks for the quick responses here from Veeam. Certainly made my job a lot easier when we had our internal briefing surrounding what products were impacted and what needed remediation.

[Coldfirex]

The Veeam Proxy for AHV is clear too?

[nielsengelen]

Yes, all products are clear.

[e.rottier]

for those who need an "official" document... we created a KB article that states that none of our products is vulnerable to that issue: https://www.veeam.com/kb4254

Thanks! We do 'need' it.

[Ctek]

Hi,

Our security staff is urging my team to resolve the following matter before EoD, most of our Windows Veeam servers have these installed:

C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\log4j-1.2.17.jar

Not 100% sure but it looks to be from the default SQL Express package embedded from the Veeam installer.

What's your take on this?

Thanks

[HannesK]

Hello,
not from our software. That path does not exist on my backup servers.

Best regards,
Hannes

[Gostev]

1.2.17 seems to be outside of affected versions though? Although honestly, this version is so old and so out of support that it probably has a bunch of other severe vulnerabilities anyway

[Gostev]

Anyway I got curious what it is, and it looks to be a part of Data Transformation Services for importing/exporting database data from/to all sorts of external data sources, some of which require Java to interact with perhaps... so make sense.

See https://en.wikipedia.org/wiki/Data_Tran ... n_Services

[Ctek]

1.2.17 seems to be outside of affected versions though? Although honestly, this version is so old and so out of support that it probably has a bunch of other severe vulnerabilities anyway

Yep we know, I challenged, but no change, we need to remediate.

[micoolpaul]

Ctek, at least you know patching that won’t break Veeam then, as to anything else sharing the same SQL server…

[Ctek]

Hi,

Our security staff is urging my team to resolve the following matter before EoD, most of our Windows Veeam servers have these installed:

C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\log4j-1.2.17.jar

Not 100% sure but it looks to be from the default SQL Express package embedded from the Veeam installer.

What's your take on this?

Thanks

Stubborn Infrastructure specialist I am, I did some lab time at home, 8hrs later I got it....

If you upgrade the default v9.5-v11 2012 or 2014 SQL Express instance of Veeam to a 2019 SQL Express instance, with default settings, there you have it ("C:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars\log4j-1.2.17.jar")

Still some details to figure out, but the raw in-progress details are there.

D.