Google Security Blog statement on Log4j vulnerability as of 2021-12-17:
Android is not aware of any impact to the Android Platform or Enterprise. At this time, no update is required for this specific vulnerability, but we encourage our customers to ensure that the latest security updates are applied to their devices.
Original Answer/Background info for context:
Q: What is the Log4j vulnerability (also known as Log4Shell)
JNDI is the Java Naming and Directory Interface. It is not an app, but a library/service allowing for runtime configuration. Log4j is a common library used in server applications. Certain strings when used with the v2.x version of the Log4j library can invoke the JNDI API which can result in leaking of sensitive information and thereby facilitate other attacks. Basically this a variation of input sanitization, except in a logging utility which for reasons had a useful but dangerous feature enabled.
Q: Input Sanitization?
You probably heard of so called SQL injection attacks where some specially crafted string can modify the commands given to the database engine. Example:
Robert '); DROP TABLE Students; -- can be inserted into this query
insert into Students (id, name) values (42, $name). When the software directly substitutes
$name with the name, it becomes this query/command:
insert into Students (id, name) values (42, Robert '); DROP TABLE Students; --) (insert, and then drop the table, everything else is commented out).
Developers need to sanitize the input, that is, check for every possible dangerous value. Developers can for example escape the
' in the name before substituting. Alternatively developers using SQL can use prepared statements, where no substitution is even done.
In the case of the Log4j vulnerability, developers were expecting the Log4j library to record application/server values, including input strings, with the expectation that those strings were plaintext and not able to invoke APIs.
Q: Is Android OS vulnerable?
A: Not by this particular vulnerability - Android OS while parts are written in Java uses its own logging library. Android OS also doesn't use JNDI protocol/service and isolates each app in its own sandbox. While this means that this particular JNDI exploit can't be used on Android, history has shown that Android is not without bugs and exploits, resulting in more security with each version.
Q: Are Android Apps vulnerable?
A: Depends - Android apps can either only exist on device OR serve as the front end of a cloud service. Android apps undoubtedly have their own bugs. On older devices apps could access the global logcat where poorly written apps may output username/passwords/other keys which while useful for debugging isn't good in a production app. As of Android 4.1 Android apps can only access their own logs.
The servers which the mobile apps depend upon is a different story as noted in the media.
Q: But what about Android Apps which use Log4j
A: On device a developer would really need to put in effort to add in Log4j separately. As seen here Log4j out of the box needs Java classes which Android doesn't support. And while there is a port for Android it is based on Log4j version 1.x which is EOL, it seems that version had it own problems which would dissuade Android developers. Alternatively an Android developer may use slf4j for Android or other actively developed logger shims on top of Android framework's native logging facility.
What is JNDI? What is its basic use? When is it used?
Comic strips by xkcd: № 327