Log4j vulnerabilities

I saw this on reddit and I found it interesting.

" I know that Android is based a lot around Java, and because of the recently discovered Log4J vulnerability, I’ve been hesitant to use anything that relies on Java unless it’s been recently updated.

Is Log4J even something I have to worry about on Android? If so, how can I tell if an app is using a vulnerable version? "

Thoughts?

The linked answer from Stackexchange explains it quite well: https://android.stackexchange.com/questions/243232/does-the-log4j-vulnerability-affect-android-users

Also the Class loader in Android needs special DEX compiled classes and doesn’t support loading classes from remote locations like the standard java Class loader. It can only load classes from the local filesystem where the app has access to.

2 Likes

I found some vulnerabilities in the fdroid build process though:

[WARNING] /var/www/fdroid/fdroiddata/build/extlib/commons-logging/commons-logging-1.1.3.jar contains log4j files
[WARNING] /var/www/fdroid/fdroiddata/build/extlib/epublib/epublib-core-3.0-SNAPSHOT2.jar contains log4j files
[WARNING] /var/www/fdroid/fdroiddata/build/extlib/epublib/epublib-core-3.1.jar contains log4j files
[WARNING] /var/www/fdroid/fdroiddata/build/extlib/epublib/epublib-core-3.0-SNAPSHOT.jar contains log4j files

Which recipes use those EXTLIBs?

I’ve checked the mentioned libaries. None of them contain the vulnerabe log4j-core.jar.
The commons-logging is only an abstraction which can use log4j when found on the classpath.
The epublib libraries contain only a log4j.properties file, this is a configuration file for log4j, but not the log4j-core classes itself.

3 Likes

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.