Do Debian APT and PHP Pear Patches Highlight Vulnerability In Package Management Infrastructure? (eweek.com) 48
"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.
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.
Re: (Score:1)
Prove Python is more secure. Anyhow PEAR is a library, not a language.
Re: (Score:1)
Python has package managers as well - PIP, Anaconda, etc. Same with Node JS and its package manager NPM.
Both Python and Node JS had vulnerabilities with their package managers in the past.
This is not a language issue. This is the ol' easy vs. secure issue. The easier you make something, the more prone to security issues it is.
Re: (Score:1)
Bring 'em on.
Coding standards exist (Score:2)
PHP is a horrific language. Most people that use it
...haven't read JavaScript: The Good Parts. PHP and JavaScript have a surprising number of pitfalls in common, such as difficult-to-memorize rules for == comparison. True, there are problems with PHP that are very annoying to work around, as Eevee pointed out in her famous essay [eev.ee]. But as with JavaScript, there are also a few common-sense coding standards [pineight.com] that make the worst problems less likely.
Nobody should use it. No, not even current versions. It's still broken.
Do you block Wikimedia sites and other sites using MediaWiki software?
Re:Coding standards exist (Score:4, Funny)
I have. Both pages, in fact.
Re: (Score:2)
Then you must have a different edition, as my copy is ISBN 9780596517748 with 160-some pages. Did yours have a quick reference card?
Re: (Score:3)
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.
Apt vulnerability (Score:5, Informative)
Max Justicz original blog post with example exploit https://justi.cz/security/2019... [justi.cz]
Same problem as certificate authorities. (Score:1)
Your HTTPS connections are only as trustworthy as your CA, divided by your browser vendor, divided by your OS vendor divided by your OS source divided by your hardware maker and your hardware source, and finally by the security of your own home.
In the end, who watches the watchmen, must always be YOU. No way around it.
And you need to be competent enough to tell if you are competent too. And do all the above too!
Everything else is just trust, justified or blind. But not certainty.
Software pipeline security (Score:5, Informative)
> 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 (Score:5, Informative)
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: (Score:2)
I will say my one-line summary was incorrect, it's a bit trickier, but the end result is executing the normal install process of an untrusted, unsigned .deb file. The protections are there, but defeated by the mistake.
Scripting language package management is however accurate, not much in the way of signing and further not particularly reviewed packages.
Deb/Ub packages and signing (Score:1)
Note that apt for both debian and ubuntu are all signed packages by default as well.
Well, there is signing, but in a roundabout way. You have .DEB files, which are listed (with checksums) in the "Release" file. It is the "Release" that is signed:
* https://wiki.debian.org/SecureApt#Signed_Release_files
There are no signatures contained with-in .DEB packages, and there are no signatures for individual .DEB files either.
Re: (Score:2)
> Note that apt for both debian and ubuntu are all signed packages by default as well.
If you have a reference for that, I'd be really interested. Most of what I've read indicates that Debian and Ubuntu packages themselves are not signed, only checksummed (which is why this vulnerability exists to begin with). Only the package metadata is signed.
https://wiki.debian.org/Secure... [debian.org]
Re: (Score:2)
When working properly, as far as I understand it, the checksums of all the packages are signed in the repo. Correct that rpm can carry a signature directly, though in practice you won't use dpkg directly just like using rpm directly is unusual.
Yes rpm direct can verify signatures and dpkg direct cannot, but apt can verify signature of the file that has all the cryptographic checksums.
This vulnerability is a way to trick apt into operating on a payload as a deb that shouldn't have been a deb. Sure, if debs
Re: (Score:3)
> 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 th
Re: (Score:2)
> Of course Debian and Ubuntu sign their packages
https://blog.packagecloud.io/e... [packagecloud.io]
I downloaded several packages at random and extracted them with "ar". There was no "_gpgorigin" file in any of them, indicating (as far as I can tell) that the *packages* aren't signed.
The package metadata is signed, but in that case the Release file contains an md5sum for the Packages file, which contains several checksums for the packages. That chain is only as secure as its weakest link. If you create a Packages file
Re: (Score:2)
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.
Signatures are just checksums that have been signed. If you could find a sha256 collision (good luck) then signing packages would also be useless. Releases contain the cryptogrophically solid checksums of packages and then it in turn is signed, establishing a chain to valiate.
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.
I thought that at first as well, but upon deeper exploration, his trick in practice was to sneak a .dpkg file into the contents of a pem file and induce apt to process that pem file as a dpkg...
yum is secure against those attacks.
And with a fix, apt is also secure agai
Re: (Score:2)
> If you do not add foreign repositories, then there is no malware issue
I don't see anything in the research that indicates that this only affected "foreign" repositories. This appears to affect all repositories, because debian packages aren't signed, directly. They're checksummed, and the checksum list is signed. All well and good, but when the redirect was able to inject a header indicating a checksum of the attacker's choosing, that measure was defeated.
As per usual, No. (Score:1)
It highlights that there is a highly effective system for distributing patches and security updates.
Also one might amuse oneself by raising the question that the submitter seems to want to imply, that package managers should be considered some kind of vulnerability. As if NOT having a package management system would somehow improve the situation, because we all know how secure and up to date the average Windows system and its various installed applications usually are... LOL.
Are only morons and retards subm
Re: (Score:2)
Are only morons and retards submitting stuff these days?
As per usual, the answer is "yes". Slashdot has been useless for quite some time now.
The APT v. Pear vulnerabilities are interesting... (Score:2)
After 'fixing' the PEAR problem to no longer have a vulnerability, PEAR's security becomes as strong as APT while afflicted by this cited vulnerability.
APT's vulnerability was to bypass the signature checking, while PEAR doesn't even have it in the first place.
Re: (Score:2)
Yes, but the mechanism was through getting apt to install a deb that bypassed all the signing. The package contained malicious scripting that was executed in the configuration phase of the install.
The vulnerability was basically sneak a deb into the 'don't care' portion of a gpg file, trick apt into treating that gpg file as a deb to install, which then discards the 'don't care' part that is the gpg signature and does a normal install of the file that should have not made it through the signature validatio
Balance the benefits vs risks (Score:2)
Do Debian APT and PHP Pear Patches Highlight Vulnerability In Package Management Infrastructure?
It's a matter of benefits vs risks: keep standalone installer relying on the user to update all softwares individually or use open source package managers, that while can contain security issues (being inspected by experts and fixed few hours later), can keep all the softwares updated including security updates. Well, at least this is valid for APT, no sure for Pear as PHP has experimented with several different package managers during the years.
Anyway, NIH is the modus operandi in PHP: never contribute or
at some point, you have trust someone else (Score:2)
As said, at some point, you have trust someone else. The other way is: code your OS and all its features yourself.
25 years of trust (Score:4, Interesting)
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