Kauft das PHP-Sicherheitsbuch!Links Tag cloud@christopherkunz
|
Friday, November 11. 2005How to increase PEAR security (and give admins a fuzzy feeling)
The latest PHP worm (lupii) attacks systems that are vulnerable to a remote code execution hole in PEAR::XMLRPC (or phpxmlrpc). It can only propagate on systems whose administrators have neglected to update PHP (or PEAR) in the last 3 months. Those three months have seen 4 PHP version bumps alone in the PHP4 tree, and anyone who hasn’t brought his PHP up to scale is probably a moron anyway. However, at least for PEAR, this might be easily fixable. What if the PEAR project would introduce a flag for packets, say, “-security” and modify the PEAR installer accordingly. That flag should only be used for pure security fixes, without feature or BC breakage, so that it won’t break anything at all (apart from the exploits). A new action for the installer, say, “pear upgrade-security” could then be introduced. It would enable admins to run pear in a nightly cronjob, only fetching security fixes and installing them in a fully automated way. Comments, everyone - is that feasible? Does a similar concept already exist? Comments
Display comments as
(Linear | Threaded)
There is normal upgrades, we could add a critical level information, but those can includes other fixes than security fixes.
That said, you are maybe lucky that I read your blog, you know our installer list pear-core@lists.php.net? do you? 
In theory packages should be fully BC. However in practice there are mistakes of course so we could have a PEAR security channel where security releases are published.
We have experienced backward compatibility breakage on PHP minor version upgrades too.
(That’s why I don’t view people who don’t have their PHP4 up to date as morons, either )
I am not sure if this is feasible. Most of the pear installations i have seen aren’t actually installed using the pear installer. They were bundled with the software. Maybe this will change one day, but currently this security feature won’t help most of the pear xmlrpcs out there. Nevertheless i like the idea
I think we are treading risky ground here. The problems at hand are:
- a few security problems have recently been discovered - users don’t upgrade In general, the gut reaction of developers is to come up with a technical solution to a problem, as this feels right (and often is right). However, in this particular case, I don’t think we will find that a technical solution is best. In fact, what needs to change is the way releases are handled. Providing strong publicity to scare people into upgrading is the best course of action, and then backing that up with strong QA to fix problems that are found in the upgrade. I think it is fair to say that the 2 security vulnerabilities in packages (XML-RPC, PEAR) that reside at pear.php.net do not justify a separate channel. Why? First of all, allowing a channel to be split into new channels introduces a security vulnerability. Channels are not just download sites, they also enforce namespaces, such that channel://example.com/PEAR cannot be used to upgrade channel://pear.php.net/PEAR. Even relaxing this slightly introduces several layers of complexity that would 1) increase the risk of a security vulnerability in the PEAR installer exponentially 2) require lots more code and consequently lots more QA I am not opposed to implementing a necessary feature with the necessary amount of code, but this just doesn’t qualify when we have existing robust mechanisms in place for doing security releases. In addition, if the security vulnerability is in the design of the package, it may be absolutely necessary to break BC, as keeping BC would simply keep the security vulnerability. Users who do not upgrade run the risk of having a known vulnerability open on their site. This is obvious. Users who do upgrade run the risk of a brief period of breakage, usually immediately apparent. In addition, downgrading via the PEAR installer is simple, fast and quite effective until the bug is found and fixed. Anyone running a critical site will have a full offline duplicate server that all changes can be tested on prior to upgrading the live site, and this further insulates end-users against problems with upgrades. In essence, upgrading is a FAR better alternative, and by making it more complex (“Do I get the latest version from pear.php.net, or security.pear.php.net?”) just won’t make anything more secure. |
Christopher Kunz varpaði á borðið fínnri hugmynd um að koma með nýjan rofa í pear tólið, upgrade-security, sem væri hægt að keira í crontab, t.d. einusinni á dag. Það sem þessi rofi myndi gera væri að ná allar öryggisuppfærslur af uppsettum PEAR pökkum
Tracked: Nov 13, 03:25