Synology Security Synology-SA-21:30 Log4Shell

[Synology RSS]

None of Synology's products are affected as CVE-2021-44228 only affects products equipped with log4j 2.

Continue reading...
- - -
Source: synology.com

 

[Telos]

Interesting... so Java packages are unaffected? Any 3rd party packages confirmed?

 

[EAZ1964]

There is a long, scary list on github:

log4shell/software/README.md at main · NCSC-NL/log4shell

Operational information regarding the log4shell vulnerabilities in the Log4j logging library. - NCSC-NL/log4shell

github.com

 

[one-eyed-king]

Interesting... so Java packages are unaffected? Any 3rd party packages confirmed?

Well java itself won't be affected as it's an external dependency. But I'd be surprised if a 3rd party package that depends on java would not be affected. Afterall log4j is still the most widespread logging framework used in the java-verse. It even hits people that use a logging facade like slf4j which may use it as their logging framework under the hood.

This one is realy nasty! And guys, it is NOT a bug, it works as designed.. though the way it's designed is highly questionable

 

[jeyare]

when you aren't sure about the vulnerability in your sys check this simple 'scanner':

PowerShell

gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path

Linux

find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}".class "{}"

I like txt logs for enhanced analysis, the I'm using fin with logging into file:

\; > /var/log/log4j-find.txt

in my case just Unifi controller was affected:

 

[one-eyed-king]

N.B.: even though java libraries do come packaged as .jar, it is possible they are encapsulated in a .war package, which themself can be standalone or encapsulated in an .ear package. The good part is that .war and .ear packages get "exploded" (as in extracted from the archive) during bootstrapping of the application. Just keep in mind that this means the search will succeed for containers, but not for images. Nowadys many applications come as sprint-boot applications, so that war and ear packages are seen less and less...

In my current project, log4j was patched to 2.15.0 last saturday, to 2.16.0 a couple of days later.. and we upgraded to 2.17.0 today.

 

[jeyare]

Just keep in mind that this means the search will succeed for containers, but not for images.

for every image, I use Grype as the first instance of checking:

https://github.com/anchore/grype

so for the UNIFI image it is easy to scan the vulnerabilities:

grype jacobalberty/unifi:latest

The next stage is:
DockerScan (installed in my NAS)

docker scan jacobalberty/unifi:latest --severity high

same for other images

 

[jeyare]

It was one of my recommendations to gents from iX - be different from others - use these native and "free" scanners for default CVE check of deployed k3s/docker containers - in the pre-deployment stage. Seems to be they understand this message.
I don't have clue who is able to describe this idea to Syno gents in Taiwan.

 

[davss]

FYI - I'm really puzzled, my client use AlertLogic.com (AL) who have been very good / spot on in terms of security. Recently they picked up Log4j on a port that's being used for DSM's web control panel on the latest version of DSM 6.2. So far other reports were correct and we were able to locate Log4j/Log4Shell on all other devices except this Synology. I understand the UI is being served by Nginx who, same as Synology for DSM and their native packages, are officially stating their web server is unaffected by this vulnerability. I've searched entire volumes for log4j and similar words as well as inside found .jar files - no log4j to be found. We only have few native packages such as Cloud Station Server, PHP 7.4, Hyper Backup and Vault, File Station, Universal Search, Storage Analyzer. Therefore, am not sure if this is a first false positive on AlertLogic's side or the package has been renamed to something else in Synology's DSM 6.2. I will soon be upgrading to the latest DSM 7.2 and will see if this removes the report from AL. In the mean time, have restricted the device to an absolute minimum access.