Four million outdated Log4j downloads were served from Apache Maven Central alone despite vuln publicity blitz

There have been millions of downloads of outdated, vulnerable Log4j versions despite the emergence of a serious security hole in December 2021, according to figures compiled by the firm that runs Apache Maven's Central Repository. That company, Sonatype, said it had seen four million downloads of exploitable Log4j versions …

[b0llchit]

If the update is so important (it is), then maybe they should force auto-builds to fail by renaming the vulnerable versions to something the scripts do not find for auto/scripted downloads. You can also poison the vulnerable versions at the source and having them bail out on first call with a log-message "please update".

These would be (very) hard measures, but it may be necessary for the long tail to become shorter.

[Joe W]

And I even feel that I saw some type of this behaviour a few years back - maybe with the ssl stuff-up?

[RichardBarrell]

Yeah. Withdrawing known-dangerous packages from availability is pretty common practice. Varies by community, though.

[Clausewitz 4.0]

Just hope a nuclear reactor safety procedure isn't using an automatic fetch / build of this version.

Or a missile launcher.

Or an industrial chemical plant.

[DS999]

Or backport the fix

If you're going to leave the older versions up, don't leave vulnerable older versions up!

[b0llchit]

Re: Or backport the fix

You can patch the older version, but it has the same problem/advantage as poisoning the package. The hash of that specific version changes. That should let some build systems fail if they have previously seen that package. IMO, if it is (mostly) the same behavior in the build, then you should pull the old package and force a fix of the build scripts.

[DevOpsTimothyC]

Re: Or backport the fix

You can patch the older version

No, you can create a new patched version of the older version eg 2.12.2 becomes 2.12.2-1 and the original 2.12.2 gets pulled. As soon as you start switching the content of the versions, and relying on the hash you in a very bad place.

The hash is there so you can ensure the package was not tampered with in transit it was not there to paper over what should be immutable

[spireite]

I know this will be an unpopular viewpoint, but why not just yank the bugged versions?

Oh, injetc into said buggy versions a banner/print/whatever.....

[Warm Braw]

Eh, what?

If this estimate is anywhere near accurate, that would be more than one download for every four professional software developers in the world.

Are there are a lot of ill-considered build scripts out there hammering the repositories or are there really that many unsuspecting users simply cutting and pasting the URLs from the installation instructions for the packages that make use of Log4j?

[Anonymous Coward]

@Warm Braw - Re: Eh, what?

Nah, they're developers. They can't be bothered with such mundane stuff like security. Remember, they're the one who got us in this sh$%t in the first place by adding that marvellous feature.

[Penguin Of Evil]

Re: @Warm Braw - Eh, what?

Their management probably told them to add features and in unrealistically short time. Their management didn't have a security policy or didn't enforce it. Their lawyers didn't have a reason to make sure they did. If your house falls down it's not usually down to the bricklayer.

In a properly run environment it is the case that

a) You have accurate and complete mainfests. When a vulnerability or flaw is identified you immediately know what is affected. When it's hardware this happens. In the exploding battery saga vendors rapidly produced lists of affected serial numbers. In the exploding motherboard story this month the same. In a well run business the question "what uses log4j" is answerable with a couple of database lookups. In software and related services it's handled by running around like headless chickens and then writing scanners because nobody knows.

b) You have change control. When a third party package changes the build gets stopped because it has the wrong secure hash, or better yet you keep the approved copy local. Even basic open source tools like RPM have been doing this for many years.

[yoganmahew]

Re: @Warm Braw - Eh, what?

c) You don't have cheapest-bid contractors cutting and pasting old versions from SO. Even after log4shell is known.

d) Your corporate security department isn't stuffed full of promotion seekers because it's a cushy number pushing paper around.

[Anonymous Coward]

"We could have used that to SPY on the Americans! Bad tech company! Bad!"

-- Chinese Government

[Penguin Of Evil]

And we are surprised because ?

Even supposedly "serious" businesses like Microsoft have subsiduaries still shipping OpenSSL 1.1.0e 16 Feb 2017 (Microsoft Zenimax Elder Scrolls Online)

Give em another decade and they might get around to log4j

Until these big corporations can be meaningfully sued for bad software and services nothing will get fixed

[Anonymous Coward]

Unlikely to happen. They have hundreds of millions to pay lawyers with.

We can't find enough funding for all the OSS developers and projects to be paid enough to eat based on their labors.

And if you can "meaningfully sue" Microsoft over an OpenSSL vulnerability, you can bet they'll sue the OpenSSL developers and official project organization over it, regardless of the terms of the license. Big organizations don't just eat their court losses; they do their best to pass the buck down the feeding chain.

[shodanbo]

Yea these downloads are probably automated so I'm sure all the tremendously witty comments provided here will make an actual difference.

[Anonymous Coward]

Absolutely

I'm sure most of these are accounted for by instances of binary managers like Artifactory that clone Maven Central frequently

[DevOpsTimothyC]

Re: Absolutely

Why would you ever have something like artifactory set like that. One of the major selling points of artifactory, nexus and similar is that they "protect" the company by ensuring that they have local copies of what was used to build the software. The only time a library is pulled form public repo's should be when it's first introduced to the code base.

[Anonymous Coward]

"downloads of pre-2.15 versions of Log4j from the Maven central repository was oddly high"

Threat actors and wannabes, downloading the unpatched version to test & refine their weapons ? Seems that it will still be a while before the patch mostly applied

"Unlikely to happen. They have hundreds of millions to pay lawyers with."

Developers can all go for their extended holiday off grid & work. Corp will have to pay for overtime and holiday pay to get this looked into and, perhaps, working again. But, as it is , in the long term, anyone trying this could risk having their roles outsourced to another country.

[FireBurn]

Dependency Hell

When I was rebuilding some packages after bumping the log4j2 version numbers in pom.xml, I found quite a few examples of the old versions being downloaded by other dependencies