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.
That's all you gained from reading this? Did you not even see that the Debian repo was tainted as well? Which has notning to do with PHP.
You all or nothings are serious idiots that are ruining the world for the rest of us.
the debian tools are written in python so suck on that
Vulnerabilities in software highlight the possibility of vulnerabilities in software. When that software is part of infrastructure, they highlight vulnerabilities in ... Infrastructure.
This article could have been summed up in two sentences with links to the incident reports.
Microsoft also had vulnerabilities in it's update infrastructure before, and those highlighted the same thing.
Prove Python is more secure. Anyhow PEAR is a library, not a language.
Table-ized A.I.
More insecure code? Developers caught napping? Just wait til your dad gets home you worthless bitches
The point is larger than PEAR by itself obviously but I accept your pedantic correction. I wasn't talking about PEAR, I said PHP. I don't have to prove Python more secure, the numbers alone do that.
Prove me wrong if you can find some that contradict me.
No.
They highlight that engineers have come up with a decent solution for rapidly distributing the inevitable security updates that will occur.
My aptget malware command suddenly stopped working.
Exactly. What a vapid article. Not to mention PEAR is ancient PHP tech at this point.
You are thinking of Fedora and DNF.
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.
Python by sheer number of users without significant issue is proof alone.
PHP with its sheer number of users and WITH significant issue is just gravy on top.
PHP is a horrific language. Most people that use it don't know how to secure it. Fuck, the developers themselves didn't know how to and they build the fucking thing! The core developers are somehow worse than the users! Some of them, for years, didn't even know how their own === comparison worked vs the == comparison. One of them didn't even see the point! LOL I sure hope they aren't still contributing.
Nobody should use it. No, not even current versions. It's still broken. It has a long way to go to become even slightly secure enough for regular use.
Every single time I hear about network tech exploits, I am not even remotely surprised PHP was at fault somewhere. I'm almost expecting it. I get surprised when it is other languages.
I can't even count the Wordpress hacks that have happened in recent years. Holy Hanna Barbara Batman!
Running PHP is like running WinXP on the internet. It could be done, just requires considerable thought put in to it so you don't get 20 worms on your shit. That is way more than most developers can give. (see Wordpress, again.)
> 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...
I'm sorry that PHP was too hard for you to learn in order to discuss it intelligently.
You can write insecure, shitty code in any language. Python, PHP, Java, perl, etc. they can all be used to write dreadfully bad code.
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.
No, the vulnerability in APT was a remote code execution vulnerability as whatever user executed apt-get upgrade, usually root.
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.
How is Debian bad for society?