As this is causing such a big fuss currently: is there anything we should be worried about?
I think Apache is not any part of OMV and i could not find anything else that might include log4j on my system. But who knows....
As this is causing such a big fuss currently: is there anything we should be worried about?
I think Apache is not any part of OMV and i could not find anything else that might include log4j on my system. But who knows....
log4j isn't used with OMV and shouldn't even be installed.
log4j2 is used in about 60% of all java applications. check your docker containers.
Here's an official blog post from Docker.
https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
I'm still searching for an article like "These are the most used docker vulnerable to log4j".
However I'm not super worried since I have a daily automated run for Watchtower so my server will pick up container updates very soon.
However I'm not super worried since I have a daily automated run for Watchtower so my server will pick up container updates very soon.
I had an image for guacamole (uses log4j) that isn't updated anymore. So, watch for that since watchtower can't help you there.
I had an image for guacamole (uses log4j) that isn't updated anymore. So, watch for that since watchtower can't help you there.
an your solution was? Also using guacamole here, hence behind a 2FA
an your solution was? Also using guacamole here, hence behind a 2FA
Connecting directly to xrdp for now.
The problem is rather nasty, as it allows for remote code executionin your containers.
The workaround is to disable the function which loads external code and add -Dlog4j2.formatMsgNoLookups=true into the jvm options. But this is only a fix for log4j >= 2.10.
How you do this depends on the container yopu use, but usually there is an environment variable called similair to JVM_OPTIONS.
If the container is not maintained any more, you have to switch to a different container.
I had an image for guacamole (uses log4j) that isn't updated anymore. So, watch for that since watchtower can't help you there.
Indeed, I periodically check if my containers are still maintained.
A vulnerability detector, in case anyone is interested.
Log4Shell only affects Programs written in Java and using the log4j library. The most likely vulnerable spot in an OMV install are docker containers. OMV itself does not use java.
The log-scanner linked abve scans files only (in /var/log). Docker containers write their output to stdout and get collected by the docker daemon, but are not written to a file in /var/log (in standard install).
TLTR: The scanner will not detect attack attempts on containers.
What you need todo is: Check which images you are using with docker image ls
Check the homepage / repository for each of your containers and check.
Keep in mind: The scanner only detects attacks, not vulnerabilities. You have to keep it running constantly.
A "vaccine", in case anyone is interested.
Very interesting! Installed docker scan as per the docker link provided above, logged into the docker environment, registered with snyk and scanned my container images. Apparently I'm log4j safe. However, docker scan found several other vulnerabilities based on outdated, unpatched linux images in some of the containers. One of the downsides of docker containers apparently, especially if they are not updated regularly. Perfectly logical, but I wasn't aware. Learned something...
m4tt0 you can always use Watchtower to update your images regularly. It's not that hard to set up and you're much safer.
As ryecoaaron stated in post #5 above, if the container is not updated... Watchtower isn't going to do anything..
For what it's worth, I was over on the Linuxserverio forum yesterday (since a vast majority of the containers I use are theirs)... and according to them..
https://discourse.linuxserver.…ted-by-log4j-exploit/3690
ZitatThe containers that use java may be affected by this exploit. The only one to our knowledge is Unifi and we released a patch for that image last night.
So if you use mostly Linuxserverio containers.. (I personally do) you should be OK.... Now I just need to check the 2-3 containers I use that are not Linuxserverio.
For what it's worth, I was over on the Linuxserio forum yesterday (since a vast majority of the containers I use are theirs)... and according to them..
Thank you. That information is useful.
The only container I use and it is not from linuxserver is mldonkey. For now I have it stopped, and I don't really know what to do with him.
Another question I have is whether the internal Nextcloud applications use java. I'm not sure how it works or if this could affect it.
Thank you. That information is useful.
The only container I use and it is not from linuxserver is mldonkey. At the moment I have it stopped, I don't really know what to do with it.
Yeah, I remember that container was pretty important to you when migrating from Synology.
I've got a couple I need to test.. but I think they are OK.
A vulnerability detector, in case anyone is interested.
I think that only works for locally installed apps... Not sure it will check containers. I'll have to dig a bit further.
I think that only works for locally installed apps... Not sure it will check containers. I'll have to dig a bit further.
This script does not detect vulnerable systems, but tries to identify exploitation attempts in your log files:
And there are far to many patterns which can be used for this exploit to make this script usefull. And if you look into your web server logs, you will see, that the show has begun. In my logs I have a bunch of attacks among many others. So far the "others" have a much higher volume.
To me it does not make sense to monitor, if someone is trying to attack you, you already know they do.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!