December 14, 20214 yr As someone who is far from and unRAID expert or a Dev in general, I thought I'd ask on behalf of all the others like me if there are any major concerns or steps that should be taken re: Log4Shell. I was a little surprised not to see any other posts about this, or something pinned from Limetech somewhere, given the magnitude of the problem. Perhaps that means there's little to worry about, but I'd rather ask anyway than be bitten. If there are any Containers or Plugins that could be a concern, is it not worth collating those somewhere central such as a post like this? Edited December 14, 20214 yr by nametaken_thisonetoo Clarity
December 14, 20214 yr 25 minutes ago, nametaken_thisonetoo said: Log4Shell. I assume that you mean the log4j vulnerability? Is so then this will not affect standard Unraid as it is a problem in Java based applications and Unraid does not have Java support installed. It could be a problem if a container uses Java and under that the log4j component I guess - no idea if any meet that criteria.
December 14, 20214 yr Author 5 hours ago, itimpi said: I assume that you mean the log4j vulnerability? Is so then this will not affect standard Unraid as it is a problem in Java based applications and Unraid does not have Java support installed. It could be a problem if a container uses Java and under that the log4j component I guess - no idea if any meet that criteria. Glad to hear the OS isn't impacted. Is there way to test different containers to make sure they are not vulnerable?
December 14, 20214 yr 1 hour ago, nametaken_thisonetoo said: Glad to hear the OS isn't impacted. Is there way to test different containers to make sure they are not vulnerable? The obvious simple test is to open a console session into a running container and see if Java is even installed in the container. If not then that container (and I suspect that will be the vast majority) cannot be susceptible to this issue.
December 15, 20214 yr Yes there are some containers affeced like openhab. Please thake that as a serious risk. You have too add some extra parameters to that containers running services based on java. -e "EXTRA_JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true"
December 16, 20214 yr For what it's worth, I wrote a quick guide on testing your Unraid server + Docker containers against the log4j/log4shell vulnerability if you want to independently verify. Log4j for Dummies: How to Determine if Your Server (or Docker Container) Is Affected by the Log4Shell Vulnerability The guide is still very much a work in progress as the situation is evolving, but when tested against a container with known vulnerabilities, it flagged it as such. In the interest of getting a guide in yall's hands as soon as possible, I prioritized testing and writing the guide. As a result, I have not yet created any templates for Community Apps (let me know if anyone would like to collaborate with me) and so you'll have to deploy the scanner container manually. Any feedback or additions anyone would recommend to the guide would be very much welcome. -TorqueWrench
December 16, 20214 yr 31 minutes ago, T0rqueWr3nch said: For what it's worth, I wrote a quick guide on testing your Unraid server + Docker containers against the log4j/log4shell vulnerability if you want to independently verify. Log4j for Dummies: How to Determine if Your Server (or Docker Container) Is Affected by the Log4Shell Vulnerability The guide is still very much a work in progress as the situation is evolving, but when tested against a container with known vulnerabilities, it flagged it as such. In the interest of getting a guide in yall's hands as soon as possible, I prioritized testing and writing the guide. As a result, I have not yet created any templates for Community Apps (let me know if anyone would like to collaborate with me) and so you'll have to deploy the scanner container manually. Any feedback or additions anyone would recommend to the guide would be very much welcome. -TorqueWrench Is it not worth mentioning that you can first check to see if you even have Java installed in the first place? If that is not present then you do not need to go any further.
December 16, 20214 yr 8 minutes ago, itimpi said: Is it not worth mentioning that you can first check to see if you even have Java installed in the first place? If that is not present then you do not need to go any further. It's a good starting point so I should probably at least mention it, thanks. By itself though isn't completely accurate and thus not sufficient to check for vulnerability: Quote Not true - applications can come with their own JRE, you don't have to have installed Java on your system to be running Java applications. – mfinni 2 days ago Source: ubuntu - How do I check if Log4j is installed on my server? - Server Fault Edited December 16, 20214 yr by T0rqueWr3nch
December 16, 20214 yr 7 minutes ago, T0rqueWr3nch said: It's a good starting point so I should probably at least mention it, thanks. By itself though isn't completely accurate and thus not sufficient to check for vulnerability: I must admit I had not thought of applications providing their own JRE Maybe just make the point that it applies to applications programmed using the Java language?
December 16, 20214 yr 6 minutes ago, itimpi said: I must admit I had not thought of applications providing their own JRE Maybe just make the point that it applies to applications programmed using the Java language? It's an excellent point. Unfortunately, I don't think there's going to be anyway around checking in layers since none of these checks are going to be absolutely foolproof. There's just too many that the library can be hidden/obfuscated. That's why I recommend following it all up with the scan at the end even if the other tests come back negative. If it's positive, then you know you're affected, and if it's not you can at least be reasonably confident that you aren't. And then you're also not relying entirely on the developer/Docker maintainer that may not even be aware of the dependencies they're using themselves. Can I get your opinion on something? I am considering replacing step 1 ("the quick and easy way") with an even quicker and easier way that has a few more automated checks. The problem is that it uses a remote script: wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - | bash I trust the remote script, it's clearly visible what it's doing and it's basically doing the same checks (but automated and includes your Java install check), but what is your opinion on recommending this to other Unraid users? Would you yourself be comfortable with it?
December 16, 20214 yr Since this is about security it is a good idea to be a bit paranoid How about giving two links - one to view the script and the other to download it. That makes it easy to check it out before downloading it. If the script ends up being simple you could even include it in its entirety within the documentation.
December 18, 20214 yr I found this tool from Docker: https://github.com/docker/scan-cli-plugin#how-to-build-docker-scan Haven't installed it or know if its applicable to Unraid.
December 18, 20214 yr 31 minutes ago, a_n_d_y said: I found this tool from Docker: https://github.com/docker/scan-cli-plugin#how-to-build-docker-scan Haven't installed it or know if its applicable to Unraid. As far I know docker scan is not available on Unraid.
December 18, 20214 yr I would suggest using docker-in-docker to play around with scan. docker pull docker docker run --rm -it --entrypoint /bin/sh -v /var/run/docker.sock:/var/run/docker.sock docker should get you into a temporary container with the docker cli installed and connected to the daemon on unRAID. Then use the instructions on the github page https://github.com/docker/scan-cli-plugin#how-to-build-docker-scan to install the cli plugin in the container. (replacing curl with wget). And you should be able to scan.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.