LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityDebian and SuhosinA recent proposal for Debian to stop shipping PHP with the Suhosin security patches has been controversial. There are a number of reasons behind the proposal—manpower, sticking to the mainline, performance, and more—but others responding in the thread consider the security mitigations that Suhosin provides to be very important for the web application language given its less than stellar security track record. What most would like to see is that those protections make their way out of the Suhosin patches and into the PHP mainline, but that does not seem to be in the offing. In the meantime, users may find that the PHP protections they have depended on will disappear from Debian. Debian PHP maintainer Ondřej Surý posted a message to several lists noting that the Suhosin patches have been disabled in the unstable repository and tries "to summarize the reasons why I have decided to disable suhosin patch" in the message. Over time, he has changed his mind about Suhosin, so he is documenting the reasons and looking for other opinions. The Debian PHP team is evidently understaffed, and the work to add in the Suhosin patches (and module) eats up some of that time. Surý is not convinced that the extra time is necessarily well-spent because PHP has "improved a lot". By shipping only a Suhosin-enabled PHP, Debian is diverging not only from the mainline, but also from what other Linux distributions do. That means that users coming from other distributions (like Fedora which doesn't ship Suhosin or openSUSE where it is optional) may run into problems they don't expect. In addition, he said, bugs reported upstream from the Debian version are often met with a request to reproduce it in vanilla PHP. There are also performance and memory usage impacts from Suhosin that some find excessive. Suhosin grew out of the PHP hardening patch that was developed in 2004. The basic idea is to add protections against bugs in the PHP core (aka Zend Engine) by making proactive changes for things like buffer overflows or format string vulnerabilities. It also tries to protect against badly written PHP applications, of which there are seemingly countless examples. Suhosin has two parts, a patch to the PHP core along with a PHP extension that implements additional hardening features. The core patches are what try to protect against buffer overflows by adding canary values to internal data structures so that the overflows can be detected. In addition, the pointers to destructors (i.e. functions that are called when an element is freed) for internal hash tables and linked lists are protected as they can be a vector for code execution if a buffer overflow overwrites them. Format string vulnerability protection and a more robust implementation of realpath() round out the changes to the core. The extension provides a whole host of other kinds of protections, largely against dodgy PHP programming practices. For example it protects against either remote or local code inclusion, which is one of the worst problems that has plagued PHP applications. It can disable the eval() call, prevent infinite recursion by putting a limit on call depth, stop HTTP response splitting attacks, filter uploaded files by a variety of conditions, and on and on. While it obviously can't prevent all badly written PHP from running amok, it's clear that the Suhosin developers have looked at a lot of common problems and tried to address them. While most of the features are configurable, they are all going to impact performance in one way or another. That's a tradeoff that many seem to be willing to make, especially in shared hosting facilities where a vulnerability in a particular customer-installed application (or the version of PHP itself) might have serious repercussions for other customers. As the project's "Why?" page notes, it comes down to a question of trust:
If you are using PHP only for your own server and only for your own scripts
and applications, then you can judge for yourself, if you trust your code
enough. In that case you most probably don’t need the Suhosin
extension. Because most of it’s features are meant to protect servers
against vulnerable programming techniques. However PHP is a very complex
programming language with a lot of pitfalls that are often overseen during
the development of applications. Even PHP core programmers are writing
insecure code from time to time, because they did not know about a PHP
pitfall. Therefore it is always a good idea to have Suhosin as your safety
net. The Suhosin-Patch on the other hand comes with Zend Engine Protection
features that protect your server from possible bufferoverflows and related
vulnerabilities in the Zend Engine. History has shown that several of these
bugs have always existed in previous PHP versions.
But there is an additional reason for dropping Suhosin mentioned in Surý's posting: "Stefan's relationships with PHP upstream (and vice versa) isn't helping very much". He is referring to Stefan Esser, lead developer of Suhosin. Surý's statement is borne out in the thread, as there seems to be a fair amount of animosity between Esser and other posters in the php-devel list. But beyond the personalities involved, there is a more important question: if the hardening features in Suhosin are truly useful, why haven't they been pushed upstream? A footnote in Surý's post refers to a section of the Suhosin FAQ that outlines the project's reasons for staying out of the mainline. It mentions the performance impact of the patches and that some PHP developers are not interested in adding code to protect against badly written applications. It also notes that by staying separate from the core, the project can make a statement about what it sees as deficiencies in security handling in PHP. But there seems to be more to it than that. Various people have encouraged Esser to create RFCs for the features in the patch that he thinks should go into the mainline, but he largely dismisses those messages with statements like:
I am not interested in pushing Suhosin into PHP mainline. Why in hell would I want that. If Suhosin gets absorbed by PHP.net then I would have to start a new project, because there are tons of mitigations I can think up that will be implemented at some point in time and will never make it into PHP mainline.
With Suhosin existing I am free to implement as many security mitigations I like and do not have to beg the PHP developers to consider adding something. Esser clearly believes that all of the Suhosin changes should go into PHP without going through the RFC process. As Stas Malyshev pointed out, though, that's part of the collaboration process:
Some people call "begging" collaboration and consider it a normal way to
develop software with teams bigger than one person. Of course, being part
of the team is completely voluntary. I think it is clear that Stefan is not
interested in doing this. If somebody would want to take on himself working
as part of PHP team on getting some features from Suhosin to PHP, he's
welcome.
Malyshev also notes that it is hard for Esser to complain that the PHP developers aren't cooperating when he is unwilling to join with the project and follow its processes. But Esser is convinced that it would be a waste of his time:
I know for sure that whatever will be the outcome of it, it will be a compromise (if at all) that will not be sufficient for my personal taste.
So in the end from my point of view people have to use Suhosin anyway. Why
also waste time merging 5 features of 100 if I can do something more useful
in the time and give my Suhosin users 20 more new mitigations.
Esser is also concerned that PHP developers are not paying enough attention to security overall. He pointed to a fix that recently went in to address problems in the HTTP response splitting protection, where, even though it is a security-related fix, there was inadequate review of two different attempts to fix the flaw. The first fix for the bug (bug #60227) went directly into PHP 5.3 back in November. Esser's complaint is strongly worded, but does point to a real problem:
And that my dear readers is exactly what would happen to the code of
Suhosin if it gets merged into PHP. It would be patched by people that do
not know exactly what they are doing. And it would be broken. And if I
would not sit on every single commit to PHP this would happen, because
obviously inside PHP no one cares about reviewing security patches.
And with Suhosin outside of PHP, there is a secondary protection layer around PHP that would have [caught] this problem: also known as defense in depth. We've heard those kinds of arguments before in a slightly different context. The grsecurity/PaX patches for the Linux kernel have been around for quite some time, but have always been maintained as out-of-tree patch sets. The pseudonymous "PaX Team", who maintains the PaX patches, made many of the same arguments about why those patches have not been submitted. It is certainly attractive to be able to go your own way, without having to coordinate or convince anyone outside of the project, but it does have its costs as well. One of those costs is a reduction in the audience because distributions and others may shy away from non-mainline code. Even if the maintainer of an out-of-tree patch set does a perfect job (impossible, of course), there is a cost associated with using a non-standard tool, whether it's a programming language or kernel. That cost is borne by the distributions and some may be unwilling to start (or continue) bearing that cost. One thing to note, however, is that Suhosin has been pretty effective at avoiding various PHP bugs along the way. The recent PHP remote code execution vulnerability found by Esser was thwarted by a suitably configured Suhosin. The HTTP response splitting problem was also solved in Suhosin long ago. On the other hand, certain (likely buggy) applications cannot run under Suhosin which also makes it difficult to adopt. There is a fundamental problem, at times, connecting upstreams and security researchers. Free software encourages folks to scratch their own itch and that's just what Suhosin and grsecurity/PaX have done. But if the changes never make it to the mainline of the project, users may be suffering from bugs that could be avoided. The "all or nothing" approach is not likely to work with any project, but it is true that security issues are often not given the attention they deserve in those upstreams. It's a difficult problem to solve, but projects would be well-served by finding a way to cultivate more security-oriented developers into their communities.
Brief items Security quotes of the week
I believe in paying money for products that earn it. I do not believe in a pricing and distribution model that still thinks it's 1998. And I really don't believe in censoring the internet so that studio and label executives can add a few more millions onto their already enormous money pile.
-- Paul
Tassi in Forbes (worth a full read)
Treat your customers with respect, and they'll do the same to you. And that is how you fight piracy.
VeriSign said its executives "do not believe these attacks breached the
servers that support our Domain Name System network," which ensures people
land at the right numeric Internet Protocol address when they type in a
name such as Google.com, but it did not rule anything out.
-- Reuters
reports on previously unreported breaches at Verisign in 2010
The service performs a set of analyses on new applications, applications
already in Android Market, and developer accounts. Here's how it works:
once an application is uploaded, the service immediately starts analyzing
it for known malware, spyware and trojans. It also looks for behaviors that
indicate an application might be misbehaving, and compares it against
previously analyzed apps to detect possible red flags. We actually run
every application on Google's cloud infrastructure and simulate how it will
run on an Android device to look for hidden, malicious behavior. We also
analyze new developer accounts to help prevent malicious and
repeat-offending developers from coming back.
-- Google's Hiroshi
Lockheimer introduces "Bouncer"
Critical PHP vulnerability being fixed (The H)The H is reporting that a critical remote code execution bug has been found in PHP that was caused by the recent fix for the widespread denial of service via hash collisions vulnerability. "The cause of the problem is the security update to PHP 5.3.9, which was written to prevent denial of service (DoS) attacks using hash collisions. To do so, the developers limited the maximum possible number of input parameters to 1,000 in php_variables.c using max_input_vars. Because of mistakes in the implementation, hackers can intentionally exceed this limit and inject and execute code. The bug is considered to be critical as code can be remotely injected over the web."
PHP 5.3.10 released with critical security fixThe PHP 5.3.10 release is out; it contains a fix for a remote code execution bug introduced recently by another security fix. Anybody running 5.3.9 should probably upgrade as soon as possible.
Langley: Revocation checking and Chrome's CRLOn his blog, Adam Langley writes about plans for removing online certificate revocation checking in the Chrome/Chromium browser. Instead of OCSP and CRL checks, Google will be pushing lists of revoked certificates to the browser. "While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks are slow and compromise privacy. The median time for a successful OCSP check is ~300ms and the mean is nearly a second. This delays page loading and discourages sites from using HTTPS. They are also a privacy concern because the CA learns the IP address of users and which sites they're visiting. [...] On this basis, we're currently planning on disabling online revocation checks in a future version of Chrome. (There is a class of higher-security certificate, called an EV certificate, where we haven't made a decision about what to do yet.)"
New vulnerabilities apache: multiple vulnerabilities
condor: denial of service
ghostscript: PostScript code execution
kernel: denial of service/code execution
moodle: many vulnerabilities
php: remote code execution
polipo: denial of service
tomcat: multiple vulnerabilities
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||