Does FOG use or install the log4s?
-
Hey guys,
I think the answer to this is no, however I need to make certain. Under a vanilla install of FOG (Ubuntu), as the title says, is log4s installed/utilized? Should we be concerned about our FOG server running this exploit.FWIW - We don’t see any trace of it on our server.
-
@robertd Since we are talking about a security concern, only believe in what your eyes and experience tells you.
I want you to look at these two links: https://launchpad.net/ubuntu/+source/apache-log4j2
and: https://www.cyberciti.biz/faq/apt-get-list-packages-are-installed-on-ubuntu-linux/
Now if you combine the two into this command:
sudo apt list | grep log4j
and/orsudo apt list | grep apache
You will need to run these from the FOG server linux console. Look through the output and see if any of log4j packages are installed.Now with that said, FOG programming doesn’t use Java at all. FOG is PHP based. Again don’t listen to a dude on the internet prove it to yourself.
-
log4j is a java library that is sometimes packaged with a program without it being installed on it’s own, so it doesn’t have to show up in the apt list to be present. that said, george is right that fog doesn’t use java, so you don’t have to worry about it there.
-
@Junkhacker Good point.
@RobertD You might still want to make sure. Search the whole disk:
find / -iname "*log4j*"
-
The “log4net.dll” is used by fog client Will the fog client be updated to fix the issue?
Thank you -
@seribe said in Does FOG use or install the log4s?:
Will the fog client be updated to fix
There are two things here, but let me post the banner part first.
FOG is not susceptible to the log4j vulnerability.- log4net.dll is not vulnerable to the log4j vulnerability. This has been discussed on other forums. The issue with log4j is specifically the jndi protocol. The J in jndi is for JAVA. FOG does not use java for either the server or fog client. The fog client uses dot net libraries. Don’t take my word for it google “is log4net affected by log4j vulnerability” The very top returned article spells it out (trust but verify).
- The version you sited 1.2.13.0 is not in the vulnerable range even if it was log4j issue. The issue is log4j version 2.0 to 2.15 are vulnerable. There is some discussion around 2.15 where 2.16 or later should be used for your mitigation issue.
Edit: Here you go, a bit more detail than from some guy on the internet: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 Its at the bottom of the first paragraph.
Edit2: Thinking about this a bit more, my previous statements are still accurate, but maybe log4net is vulnerable to something else than the log4j vulnerability. There might be a heightened awareness around log4xxx series of files. Does your scanner software state the specific CVE that triggered this alert?
I do see two CVE alerts from 2018 and 2006 regarding log4net: https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-7281/Apache-Log4net.html The one from 2018 indicates version prior to 2.0.10 have a configuration file vulnerability https://nvd.nist.gov/vuln/detail/CVE-2018-1285 You would need to access the logging config file to trigger this flaw from what I understand. Which the version you indicated would fall into that category. It looks like 2.0.14 is the most current release of log4net ref: http://archive.apache.org/dist/logging/log4net/binaries/ -
@george1421 said in Does FOG use or install the log4s?:
Again don’t listen to a dude on the internet prove it to yourself.
“Think for yourself, question authority.” -Tim Leary
-
@george1421 said in Does FOG use or install the log4s?:
I do see two CVE alerts from 2018 and 2006 regarding log4net
Thanks George for bringing this up. We might look into updating or even removing log4net from the fog-client.