Saturday, November 23, 2024

Warning: Log4j Still Lurks Where Dependency Analysis Can’t Find It

Research shows Log4J still lurks where dependency analysis can’t find it

The best programming practice to include a third-party library in source code is to use the import command. It is the easiest way to do it, and it is also the way that most dependency analysis programs work to determine if a vulnerable library is in play.

Any time code is included without calling it as an external package, traditional dependency analysis might not be enough to find it — including when Java coders use a common trick to resolve conflicting dependencies during the design process.

log4shell
log4shell

Log4J Warning

A new study by jFrog found that 400 packages on repository Maven Central used Log4j code without calling it an external package. Around a third of that came from fat jars — jar files that include all external dependencies to make a more efficient product. The remainder came from directly inserting Log4j code into the source code, including shading, a work-around used when two or more dependencies call different versions of the same library in a way that might conflict.

While 400 may not seem like a lot for Maven Central, where Google found 17,000 packages implementing the vulnerable Log4j library, some of the 400 packages unearthed by JFrog are widely used.

Log4Shell
Apache Log4J

“Some of the packages, we were familiar with. Some are commercially backed, some are maintained by the community. Some were pretty significant,” said Asaf Karas, chief technology officer of JFrog Security Research.

JFrog scanned Maven Central using an in-depth open-source scanner it released on December 28. Karas suggests enterprises apply to their own java applications. Maven Central’s packages may be indicative of how corporations coded their own internal and product software.

Recommended:  No Fix In Sight For Loophole Plaguing a Key Windows Defense

While the 400 packages contain unlisted Log4j, around 70% of the time, they did contain dependencies using Log4j that might light up a scanner (albeit pointing in a different direction).

JFrog has not yet released the names of the potentially vulnerable packages it discovered on Maven Central while it completes disclosure.

“It’s a process where we’re trying to really understand which are the ones that are the most popular and then disclose that information there first,” said Karas

“But we didn’t want to postpone the fact that people should be aware that this kind of threat exists.”

Read more cybersecurity news articles

Bookmark
Please login to bookmarkClose
Share the word, let's increase Cybersecurity Awareness as we know it
- Sponsored -

Sponsored Offer

Unleash the Power of the Cloud: Grab $200 Credit for 60 Days on DigitalOcean!

Digital ocean free 200

Discover more infosec

Steven Black (n0tst3)
Hello! I'm Steve, an independent security researcher, and analyst from Scotland, UK. I've had an avid interest in Computers, Technology and Security since my early teens. 20 years on, and, it's a whole lot more complicated... I've assisted Governments, Individuals and Organizations throughout the world. Including; US DOJ, NHS UK, GOV UK. I'll often reblog infosec-related articles that I find interesting. On the RiSec website, You'll also find a variety of write-ups, tutorials and much more!

more infosec reads

Subscribe for weekly updates

explore

more

security