log4j

[gthibaul]

Hi,

We have installed AtoM 2.6.4 on Ubuntu 18.4.6 last spring. We've taken into account the security pertaining to log4j vulnerability and followed the recommended fix (Security announcement - Log4j vulnerability, December 2021 - AtoM wiki (accesstomemory.org) , yet the IT Central still flag the server as vulnerable to Log4Shell. Is there any explication for this? 

Thanks,

Ghislain

[Dan Gillean]

Hi Ghislain, 

According to our security developers, if your server is only running AtoM and you have removed the JndiLookup.class file as recommended on our wiki, then a security scan should not trigger a log4j vulnerability. Is it possible you have other applications that use Java (for example, logging / monitoring applications) installed on the server?

You could try doing a search across the server for other instances of that JndiLookup.class file. I'm not sure how other applications will handle having this file deleted, so if you find a second one from a different application install, I would suggest looking up the recommended mitigation instructions for that application and following those.  

If that's not the case then a bit more information would be helpful - what scanning tool are you using, and what exactly is the error being returned? Did you follow our recommended installation instructions, or have you made any changes (and if so, what)? Anything else about this installation or server that you think would help us better understand the context of this issue? Thanks in advance! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/3b1d826d-75b7-4b4a-be5d-0b14c920e35an%40googlegroups.com.

[Jim McGrath (uOttawa)]

We followed the recommended instructions during the configuration of the server.  We did not make any additional alterations.  The server is sole use AtoM, with no other applications installed.  Java is installed, as recommended.  The security scanning tool that our central IT uses is Qualys, we don't do the scans, so I am unsure of the exact error it is producing other than that they said it was still vulnerable.  

[Dan Gillean]

Hi Jim, 

I think it would be good to try to get more detailed information from your security team about this. It may really depend on the sophistication of the scanning tool - remember, the solution we recommend is not to fully remove Log4J (something that's not possible without also affecting Elasticsearch, from what I understand), but deleting the specific file that leads to the vulnerability. As such, if Qualys is merely throwing a flag because it detects a certain version of Log4j (which is my guess as to what's happening here), that is very different from it actually identifying a reproducible vulnerability. 

It would be very helpful to learn more about exactly what the tool is reporting, so our security team can reproduce the issue and find another solution if required - most of the security tool output reports I've seen include steps to reproduce, specific paths/pages/inputs that were targeted, etc. Any further details you can provide would be welcome. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/4bee9796-7cbe-4981-bb7d-315d9a405d33n%40googlegroups.com.

[Jim McGrath (uOttawa)]

I am currently waiting for a response from our IT Security team about what Qualys is returning in its security scan for the server.

[Jim McGrath (uOttawa)]

Our IT security team finally got back to me.  Qualys is coming back with security scan responses that Apache/log4j vulnerabilities are present and must be remedied.  Since AtoM uses Nginx and not Apache, I should be able to disable/uninstall Apache with there being no negative impact to AtoM.  Correct?

[Jim Adamson]

The Apache Software Foundation maintains log4j but Apache HTTPD is a separate package - nothing to do with log4j. So removing Apache HTTPD won't remove log4j, hence it won't remove any vulnerability still present in log4j. As Dan said, the Qualsys scan detail is what is needed in order to determine what next.

It's also possible the Qualsys scan has detected vulnerabilities in both Apache HTTPD and log4j, as another way of interpreting what you've typed.

AtoM is not dependent on Apache HTTPD so you can indeed remove it if you want.

Thanks, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/d797b55e-9816-4785-b1bf-ba54f5943b73n%40googlegroups.com.

--

Jim Adamson

Systems Administrator/Developer
Facilities Management Systems
IT Services

LFA/023 | Harry Fairhurst building | University of York | Heslington | York | YO10 5DD

+44 (0)1904 323859

Email disclaimer: https://www.york.ac.uk/about/legal-statements/email-disclaimer/

[Jim McGrath (uOttawa)]

I checked the patches and the vulnerabilities that Qualys is listing and IT security are indicating need to be done:

CVE-2021-44832 already installed.

CVE-2021-45046 does not affect the system

So I'm not sure why Qualys is saying the system is vulnerable and to install the patch, when the patch is already there.  There were several other security  vulnerabilities that it found, but IT security won't concerned with them.

[Jim McGrath (uOttawa)]

As it seems, it's an issue with Qualys, coming back with a false positive.  Our IT Security team has submitted a ticket with the vendor for an update/fix/solution.

[Dan Gillean]

Thanks for confirming and letting us know, Jim!

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/8e785d02-2381-491a-b7de-ee0519db5b80n%40googlegroups.com.

[Jim McGrath (uOttawa)]

We finally got word from our Security group about the log4j issue on the AtoM server.  It was apparently some sort of logic issue that Qualys uses when scanning a system for the vulnerability.  We tried all the steps that they indicated to resolve the problem, but none of them worked as there was nothing to patch/resolve.  They have closed the ticket, so we are apparently free and clear for now.  The system will be migrated in the coming weeks anyway, so we will be revisiting the system again no doubt to start the migration to off site.

[Dan Gillean]

Appreciate the heads up, Jim! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/e14b5ad6-c254-4a8c-9e6e-ac8760ae16fdn%40googlegroups.com.