In the past two weeks, Log4j has continued to drive security news, with more vulnerable platforms being found, and additional CVEs coming out. First up is work done by TrendMicro, looking at electric vehicles and chargers. They found a log4j attack in one of the published charger frameworks, and also managed to observe evidence of vulnerability in the Tesla In-Vehicle Infotainment system. It isn’t a stretch to imagine a piece of malware that could run on both a charger, and an EV. And since those systems talk to each other, they could spread the virus through cars moving from charger to charger.

Log4j is now up to 2.17.1, as there is yet another RCE to fix, CVE-2021-44832. This one is only scored a 6.6 on the CVSS scale, as opposed to the original, which weighed in at a 10. 44832 requires the attacker to first exert control over the Log4j configuration, making exploitation much more difficult. This string of follow-on vulnerabilities demonstrates a well-known pattern, where a high profile vulnerability attracts the attention of researchers, who find other problems in the same code.

There are now reports of Log4j being used in Conti ransomware campaigns. Additionally, a Marai-based worm has been observed. This self-propagating attack seems to be targeting Tomcat servers, among others.

WebOS Falls to a Snapshot

[David Buchanan] acknowledges that while this is an interesting exploit, there isn’t much utility to it at this point. That could change, but let’s look at the flaw for now. Snapshots are a cool feature in the V8 JavaScript engine. When you navigate to a web page, the JavaScript context for that page has to be generated in memory, including loading all the libraries called by the page. That doesn’t take too long on a desktop, but on an embedded device or a cell phone loading a local interface, this initialization step can represent a large percentage of the time needed to draw the requested page. Snapshots are a great hack, where the context is initialized, and then saved. When the interface is later opened, the V8 engine can be called with that file, and the context is pre-initialized, making the launch of the app or interface appreciably faster. The only catch is that V8 expects snapshots to only be loaded from a trusted source.

On to the WebOS platform itself. Individual apps are sandboxed, but web apps run their code in the context of the WebAppMgr (WAM), their browser based on Chromium/V8. While the individual apps are sandboxed, WAM is not. The kicker is that a web app can specify its own snapshot to load into V8. Loading a corrupted snapshot gave [David] JS type confusion, and an arbitrary read/write primitive as a result. From there, breaking out of running JS and into actual shellcode was fairly easy. This RCE runs as the “wam” user, but this is a mildly privileged account. Notably, wam has access to /dev/mem — direct access to system memory. Escalation to root is …read more

Source:: Hackaday