back to article Two years on, 1 in 4 apps still vulnerable to Log4Shell

Two years after the Log4Shell vulnerability in the open source Java-based Log4j logging utility was disclosed, circa one in four applications are dependent on outdated libraries, leaving them open to exploitation. Research from security shop Veracode revealed that the vast majority of vulnerable apps may never have updated the …

  1. mikus

    I recently ran into this with mremote-ng, a windoze software client for ssh and remote desktop use, so like something mostly system administrators would use was still using an ancient vulnerable log4net, a variation of log4j with the same vulnerabilities. My FortiClient EPP software noticed it to alert, luckily I had some enterprise security to do so, but how many others do not?

    Looking up the software project's github to post an issue, someone else with the same alert from FortiClient told them years ago, and they closed it, telling someone to get the "nightly" version vs. the ancient and non-updated main app from the website that you know, 99% of people including myself would just download to use. I opened a new ticket asking them patch the main version ffs too, and finally did after some nagging and public shaming, but by this point I already uninstalled it, cursed having to use anything like that on windoze in the first place.

    Anything on windoze, particularly 3rd party software I imagine is all a rats nest of vulnerable dependencies that never get updated. I use windoze for anything as little as possible for that reason alone, usually only keeping it around as my visio runtime.

    1. Ahosewithnoname

      Yes, it is of course Microsoft's fault.

      1. anonymous boring coward Silver badge

        Historically, yes.

  2. tiggity Silver badge

    No surprise really

    Some orgs will be on top of things and use tools that will alert them to the vulnerability issues & help resolve them

    e.g. whitesource AKA provide some good commercial tools*, and there's plenty of free tools that can help.

    Unfortunately lots of orgs don't do that (even though, with open source its easier to keep on top of things as ultimately you have the code and can update dependencies etc.)

    There are nasty areas where issues can creep in with many dependencies and code vulnerabilities.

    If you use product X, that has a dependency on product Y (amongst many other products),

    Lets say product Y has a nasty vulnerability, that is fixed in version 6.0

    Your product X, uses Y 5.8

    Y6.0 has some breaking functionality changes compared to 5.8 e.g. removes some decrepitated APIs that X uses.

    In this scenario its not just the easy fix of get Y 6.0

    You also need either the developer of X to change their code to be compatible with Y6.0 (or rearchitect it to not need Y) or, worse case, you need to make changes to product X codebase yourself.

    Breaking changes across versions preventing the "easy fix" of just grabbing patched version of product at fault (& typically a patch only been done in a newer release and not back ported to older versions with different APIs / functionality) is one of the main causes I have seen of code with known CVEs still being used as the fix is non trivial.

    You can easily find products with a large number of dependencies on other products (which is sensible in a way, e.g. why reinvent the wheel and write lots of code to export your data to CSV when you can use product M to do the hard work and you just make a few lines change to call to it (saving you time and effort) - but the issues of non maintained products, breaking chnages can come back to bite.

    For the many, many faults of MS, they have been reasonably good at keeping breaking changes to API / method calls to a minimum, this is not always the case in *some* open source projects, where APIs /methods can often change a lot across versions.

    * Lots of commercial tools out there, just mentioned based on having actually used some of their tools

  3. Claverhouse Silver badge

    Too Simple

    The larger issue at play isn't just the failure to apply patches. According to Sonatype, the number of Log4j downloads containing vulnerable versions just in the last seven days stands at 26 percent of a total 3.7 million.

    Wouldn't it be simplest to block and remove all vulnerable versions on download sites in the first place ?

  4. sbegrupt

    reload4j is the answer

    The blessed fix – migrating to log4j2 – is a large undertaking. And I would recommend migration to slf4j anyway. Not to mention that you need access to the source code of your app for either of them.

    However, one of the original creators of log4j1 created a drop-in replacement It also works if you have software that is out of support – a single JAR could be replaced.

    Many people didn't know this fix or didn't trust it because they weren't aware who created reload4j.

  5. BPontius

    Tip of the iceberg

    Lots of "talk" about securing America's infrastructure and businesses, yet little else is actually being done as evidenced by the hacks and infections in the news. Until IT security stops being done on a shoe string and is more than just a catch phrase, it will only get worse from here. Six years on WannaCry still infects unpatched systems as 40 year old SMBv1 lingers on in use. SMBv1 a relic from the DOS era, along with the counterpart API NetBIOS that Microsoft clings to despite knowing how insecure they are over 20 years ago. The Apache Strut vulnerability that allowed the Equifax 2017 hack had a patch released two months prior. The Government recently had breaches on their servers due to unpatched software.

    1. RedGreen925

      Re: Tip of the iceberg

      "Until IT security stops being done on a shoe string and is more than just a catch phrase"

      Until failure of IT security becomes a criminal offense with decades in jail for the CEO and the other morons involved nothing will change. And the corporate death penalty imposed for the business who fail at it too, that will get the scumbags who control the IT security in industry to pay attention to it.

      1. Pixel Green

        Re: Tip of the iceberg

        Unfortunately the additional layers of law and litigation will only make it prohibitively more expensive to start up, or run a small business.

        And likely do little to curb the greed of IT illiterate shareholders. And in large enough organisational structures, there's a limit to how much you can hold higher ups to account where a single mistake or omission may have been made by the boots on the ground.

        But I do agree with the sentiment that something must be done, I just don't think law alone is the best way to do it. Just look at all the GDPR non-compliant cookie implementations about...

  6. Pete Sdev Bronze badge

    Unified notification for security patches

    It's an idea I've had before, but what I'd like to see is a standard way of publishing security warnings for software, including libraries.

    To track all the dependencies of a project I currently have to sign up to various mailing lists (problematic in itself), some Google groups, manually check the news section of the library websites, etc.

    I'm thinking of RSS with an extension. Human and machine readable, autodiscovery, etc.

  7. Leeo

    Incorrect headline

    While it is true, that 1 in 4 (or 1 in 3 / 38% according to the cited Veracode article) apps rely on vulnerable versions of Log4j, the vast majority (32 of the 38%) rely on version 1.2.x is not vulnerable to Log4Shell. This version is vulnerable to three other related vulnerabilities (CVE-2022-23307, CVE-2022-23305, CVE-2022-23302) which also allow for RCE but are a lot less severe as they require specific configurations which are not the default (CVE-2022-23305, CVE-2022-23302) or the use of a specific graphical tool (CVE-2022-23307). Of course the fact that 1.2.x is EOL since 2015 should be reason enough to avoid this version and its widespread use is mind-boggling.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like