Do Debian APT and PHP Pear Patches Highlight Vulnerability In Package Management Infrastructure? (eweek.com)

"Time and again, security experts and vendors alike will recommend to organizations and end users to keep software and systems updated with the latest patches," reports eWeek. "But what happens when the application infrastructure that is supposed to deliver those patches itself is at risk?" That's what open-source and Linux users were faced with this past week with a pair of projects reporting vulnerabilities. On January 22, the Debian Linux distribution reported a vulnerability in its APT package manager that is used by end users and organizations to get application updates. That disclosure was followed a day later, on January 23, with the PHP PEAR (PHP Extension and Application Repository) shutting down its primary website, warning that it was the victim of a data breach. PHP PEAR is a package manager that is included with many Linux distributions as part of the open-source PHP programming language binaries....

In the Debian APT case, a security researcher found a flaw, reported it, and the open-source project community responded rapidly, fixing the issue. With PHP PEAR issue, researchers with the Paranoids FIRE (Forensics, Incident Response and Engineering) Team reported that they discovered a tainted file on the primary PEAR website... Both PHP PEAR and Debian have issued updates fixing their respective issues. While both projects are undoubtably redoubling their efforts now with different security technologies and techniques, the simple fact is that the two issues highlight a risk with users trusting updating tools and package management systems.

Comments

Apt vulnerability

[ISayWeOnlyToBePolite]

Max Justicz original blog post with example exploit https://justi.cz/security/2019...

Software pipeline security

[MSG]

> Do Debian APT and PHP Pear Patches Highlight Vulnerability In Package Management Infrastructure?

Yes.

The security of the software delivery pipeline is something that Red Hat stresses, and is one of my top reasons for using their platforms. Universally signed packages is a significant security improvement over other systems.

You should definitely be concerned about the security of unsigned code, regardless of whether you get it through docker, pip, pear, gem, or other means where signatures are not present and verified by default.

Re:Software pipeline security

[Junta]

Note that apt for both debian and ubuntu are all signed packages by default as well.

Here the vulnerability is that the HTTP reply can just claim a hash and cause apt to assume the given hash is correct without calculating it itself. A huge mistake that defeats the package signiing but a mistake that may be patched.

You are right with pip, pear, gem, npm, and cpan, most of the language specific repositories are security nightmares (not just general lack of signing, but the 'anyone can publish' model means that even if signed, you generally don't have much of a chance to manage your trust relationships anyway).

Basically the major linux distros take package signing seriously but the scripting languages don't and can not.

Re:Software pipeline security

[MSG]

> though in practice you won't use dpkg directly just like using rpm directly is unusual.

That's true, but I'm not sure what point you're making. yum (or its replacement dpkg) validates the packages it downloads using a cryptographic signature, which makes it a more secure system than apt.

I'm not comparing rpm with apt or dpkg. I'm comparing yum with other package management systems.

> Yes rpm direct can verify signatures and dpkg direct cannot, but apt can verify signature of the file that has all the cryptographic checksums.

As far as I know, dpkg can verify signatures. The problem is that Debian and Ubuntu don't bother to sign their packages.

Checksums aren't secure. All an attacker has to accomplish is to generate a file with some garbage data in order to match the checksum. In other words, they only need to find a hash collision.

> This vulnerability is a way to trick apt into operating on a payload as a deb that shouldn't have been a deb.

No, it was a way to provide a package that didn't match the checksum, with the addition of a header that said that it did.

> so too would https as a default pretty much made this not exploitable

https would prevent against a man-in-the-middle, but it's still vulnerable to an attacker who gains control of the mirror you're using. A malicious mirror could have used this vulnerability or a hash-collision to push malicious packages.

yum is secure against those attacks.

Re:Don't be a PHP monkey.

[Junta]

Note in the context of this particular thread, the question would be whether pypi is secure, and the answer is not really.

In fact, one could describe the apt vulnerability as degrading apt security to pypi/pear/gem/npm security on their *best* day.

25 years of trust

[bigtreeman]

So in 25 years has the Debian repository ever been compromised using this vulnerability in the apt system, that has been promptly patched ?
Motto of the story, I trust Debian

Re:Coding standards exist

[Hognoxious]

...haven't read JavaScript: The Good Parts.

I have. Both pages, in fact.