Slashdot Mirror
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.
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.
Prove Python is more secure. Anyhow PEAR is a library, not a language.
Table-ized A.I.
Max Justicz original blog post with example exploit https://justi.cz/security/2019...
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.
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.
> 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.
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 submitting stuff these days?
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. But as with JavaScript, there are also a few common-sense coding standards 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?
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.
XML is like violence. If it doesn't solve the problem, use more.
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.
XML is like violence. If it doesn't solve the problem, use more.
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 improve any existing library, always create a different one from the ground.
As said, at some point, you have trust someone else. The other way is: code your OS and all its features yourself.
I gave up with the idea of an useful sig...
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
Go well
Bring 'em on.
Table-ized A.I.
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 validation. Normally that portion of the install didn't expect to have to worry about signature verification (it was supposed to be handled before then), so arbitrary deb gets to be installed with malicious payload put to disk and/or configuration payload that executes at apt execution time.
XML is like violence. If it doesn't solve the problem, use more.
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.