Now it's PostgreSQL's turn to have a bogus CVE

PostgreSQL and cURL aren't the only ones. Someone is faking security alerts for numerous open-source projects.

Recently, the popular open-source command line copy tool, cURL for transferring data via URLs, was given a jaw-dropping 9.8 Common Vulnerability Scoring System (CVSS) critical security violation mark. There was only one little problem with this National Vulnerability Database (NVD) CVE-2020-19909 report: It was bogus. There's nothing wrong with cURL. Now, the same kind of crap security report has shown up for the open-source SQL database, PostgreSQL.

This time, according to the PostgreSQL Security Team reports, just like with cURL, whoever the unknown reporter was didn't bother to tell them that was a security problem. Had they done so, the security team would have told them the same thing they told the NVD crew: There was no problem.

The "issue," CVE-2020-21469, claimed that PostgreSQL 12.2 allowed attackers to cause a denial of service by repeatedly sending SIGHUP signals. SIGHUP, which dates back to the days when we connected terminals over serial port connections, is a kill-the-process signal.

That would be bad news. It would well deserve the 9.8 score it was branded with.

However, there's one little, itty-bitty problem. Ordinary users can't send SIGHUP signals. In fact, they can't kill PostgreSQL processes, period. SIGHUP can only be sent by a PostgreSQL superuser; a user with pg_reload_conf instructs PostgreSQL to reload its configuration, access, or the root user. In short, anyone who could use this "flaw" to kill PostgreSQL could use any ordinary method to terminate it without this nonsense.

Or, to quote the PostgreSQL Security Team, "THIS IS NOT A SECURITY VULNERABILITY."

They've got that right!

Mind you, as they'll tell you should update from PostgreSQL 12.2 because of these actual CVEs and other bug fixes. After all, PostgreSQL 12.2 is over three years old. That makes it a dinosaur of a release.

But, there's a bigger problem going on. Why are these crap security releases appearing in the first place? And, why are they being blindly passed on to the public without any attempt to see if there is anything to them? In both cURL and PostgreSQL cases, simply asking the developers would have revealed there's "no there, there."

These aren't technically sophisticated bug reports. They are "Are you kidding me?" bug reports.

Alan Coopersmith, an Oracle Solaris engineer, speculated on Twitter that since "Both the PostgreSQL & cURL CVEs were part of a batch of 138 new CVE's for 2020 published on the same day last week - gotta start wondering how many of the rest are bogus too?"

This brings up another point. It's 2023. Usually, a CVE is given the year it's reported as part of its designation. That, combined with over a hundred of them all appearing on the same day, should have raised red flags.

As to where they all came from, Dan Lorenc, CEO and co-founder of Chainguard, a software supply chain security company, speculated, "The curl commit had 'integer overflow' in the commit message. This Postgres one says 'buffer overflow' in it. I'd bet $1,000 this is someone running a script on grepping old commit messages for things like this and auto-filing CVEs."

No bet.

In a LinkedIn post, Lorenc expanded on his theme. "All of these CVEs link out to bug or patch entries on repos or mailing lists, all were filed without maintainer interaction, and all contain an obvious "vulnerable sounding" string in the commit message or issue. Something like 'use after free,' 'denial of service,' or "buffer overflow.'"

In short, these are garbage.

Lorenic said this flood of junk CVE " is literally going to DOS triage teams, the NVD itself, and open source maintainers stuck dealing with the fallout. Stop doing this!" He's correct.

The CVSS process itself is broken. Of course, we must take security seriously, but taking anonymous, poor complaints as Gospel security truth about critical projects only gets in the way of improving security. What we see with these nonsense reports doesn't help security, it only makes the process harder than ever.

Stop it! Stop it now!

Noteworthy Linux and open-source stories: