Slashdot Mirror
Recently Exposed PHP Hole's Official Fix Ineffective
wiredmikey writes "On Wednesday, a remote code execution vulnerability in PHP was accidentally exposed to the Web, prompting fears that it may be used to target vulnerable websites on a massive scale. The bug itself was traced back to 2004, and came to light during a recent CTF competition. 'When PHP is used in a CGI-based setup (such as Apache's mod_cgid), the php-cgi receives a processed query string parameter as command line arguments which allows command-line switches, such as -s, -d or -c to be passed to the php-cgi binary, which can be exploited to disclose source code and obtain arbitrary code execution,' a CERT advisory explains. PHP developers pushed a fix for the flaw, resulting in the release of PHP 5.3.12 and 5.4.2, but as it turns out it didn't actually remove the vulnerability."
Why should I use PHP?
Who runs a site in PHP that is worth exploiting?
PHP is a pile of shit and its authors don't have the slightest concept of what they're doing.
Next up on the news: water is wet.
More at 6.
PHP: Pretty Hard to Protect.
Never shake hands with a man you meet in a fertility clinic.
Available from the source, not information week.
The info I was looking for:
- FastCGI installations are not vulnerable
- can only be exploited if the HTTP server follows a fairly obscure part of the CGI spec. Apache does this, but many other servers do not.
They should've been using models instead of CGI.
Learn 2 troll.
The only reason to use PHP is ignorance. There have always been far better options available, and anyone who wasn't a fucking idiot used them.
There's no valid reason to use PHP today. None at all. Python, Ruby, and even Perl are far better languages, and they all have extensive and robust libraries and frameworks for developing web apps. Java and C# are two other options, and in some ways are much better than Python, Ruby and Perl, especially for larger apps worked on by many developers. Then there are numerous other frameworks for less-common languages like Haskell, Erlang, Smalltalk, and Scala, as well.
PHP's numerous and fundamental security problems shouldn't be an issue for anybody, since nobody should be using PHP in any way.
I generally don't feed your kind, but if PHP was from Microsoft it would be left unpatched for Windows Server 2003, Windows Server 2008 would get a temporary patch blocking most of the functionalities and there would be an announcement that, due to technical restrictions, everybody needs to upgrade to Windows Server 2013 (release date : late December 2015) to get an actual fix. People running iis on XP, Vista or Win7 wouldn't get a patch at all. Of course, anybody running another server than iis would be left in the cold too.
On the positive side, it could be worse ... Apple would just ignore any mention of security problems and systematically erase any posts on their message board refering to them.
That being said : you might want to steer away from PHP anyway. it's a stinking pile of donkey dung
Cheers
"DRM is like the Ford Pinto: it's a smooth ride, right up the point at which it explodes and ruins your day."-C.Doctorow
I think this short snippet from Rasmus is priceless:
Yeah, passing arguments with full shell expansion to the bloody binary from the unsecure web sounds like a brilliant idea! Who would want to disallow that?!
It was pretty funny so far, but then I've seen this:
The PHP security people sat on this 0day remote code exploit for four months, ignoring multiple attempts to get them to fix this serious vulnerability. That makes me feel angry, sometimes incompetence is just not funny anymore.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
http://php.net/license/index.php PHP has a license which must be respected by law. Certain parts of it have various licenses too. These are Open Source licenses, and as such have many benefits. Nevertheless, there are licenses.
My web host pushed this patch into user htaccess for those users clueful enough to be running php as cgi: .? - [F,L]
RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|- [NC]
RewriteRule
Shared hosting at this ISP, a well-regarded one, disables normal PHP's ability to write files unless you open up directory permissions (777). Last time I checked, other users could also read files unless you used 600. Two problems, hence, they support php-cgiwrap if you know enough to want it.
Running PHP as cgi is the only reasonable choice at shared hosts like this, with a robust, but essentially legacy, Linux structure.
Seems crazy. CloudLinux does segregate users (nothing to do with a cloud, by the way), and other Linuxes can be protected various ways (FutureQuest has done shared hosting right for a long time.)
https://www.google.nl/search?client=opera&rls=en&q=massive+security+hole+ruby&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest#sclient=psy-ab&hl=en&safe=off&client=opera&hs=7y2&rls=en&channel=suggest&q=security+hole+rails&oq=security+hole+rails&aq=f&aqi=&aql=&gs_l=serp.3...11909.11909.2.12120.1.1.0.0.0.0.171.171.0j1.1.0...0.0.M8PkiUtwDPo&psj=1&bav=on.2,or.r_gc.r_pw.r_cp.,cf.osb&fp=81cfb75de4601914&biw=1725&bih=1037
READ the snippet google gives for the first result.
Back then, every rails fan tried to wave the massive by default security flaw as being unimportant. This PHP thing only affects those running CGI which is pretty are and BAM, it is a massive flaw and the end of the world.
Pieces of software and hardware are sometimes design with the wrong assumptions, it happens. Follow the industries best practices, or become a fanboy and burry your head in the sand when it is your pipelines turn to be ridiculed.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
PHP: a fractal of bad design (obligatory).
You had me up until the last two sentences, which appear to be merely unsubstantiated and provocative.
I highly appreciate (and agree as Insightful) your analysis of what the response to some other software vendors would be to this sort of incident.
What would *you* write your inventory database front-end in? PHP makes it work without unacceptable overhead.
I preferentially use Perl for straight scripting work, but mod-perl just hasn't proven itself to hold up against PHP on the performance front for web-based apps, and the hooks aren't as convenient. The ability to say something like
is actually amazingly concise and powerful. (angle brackets turned to sqare after fighting /.s editor too long and not remembering the required dance this early in the morning)
And, for the record, I tried to use this to co-opt my PHP-based sites and... nothing happened.
mod_perl? 2001 called. It wants its web dev back.
Look into fastcgi and catalyst.
Reread the parent post again. And again.
PHP now even has closures, lamda, internal iterators
Just because the latest stable version of PHP has a feature doesn't mean that the version of PHP installed at your current web host has that feature.
There have always been far better options available
Even without switching hosting companies?
There's no valid reason to use PHP today.
What free software do you recommend as an alternative to phpBB? As an alternative to MediaWiki?
Reposted from OSS-Security: http://www.openwall.com/lists/oss-security/2012/05/04/18
Hi,
I guess most of you have heard of this one already, yet it should be in here as well. The original issue was tracked as CERT VU#520827, CVE-2012-1823. PHP 5.4.2 and 5.3.12 were released with an incomplete fix, and apparently CVE-2012-2311 refers to that incomplete fix issue.
http://www.php-security.net/archives/11-Mitigation-for-CVE-2012-1823-CVE-2012-2311.html
http://www.kb.cert.org/vuls/id/520827
http://www.reddit.com/r/PHP/comments/t3pr8/how_serious_is_this/
http://www.reddit.com/r/netsec/comments/t4lxw/phpcgi_query_string_parameter_vulnerability_leads/
http://www.metasploitminute.com/2012/05/cve-2012-1823-php-cgi-bug.html
http://www.opennet.ru/opennews/art.shtml?num=33765 (in Russian)
Alexander
We canned PHP for our corporate systems many years ago. It was an expensive re-write but we've not found any loss of function, and after re-writing into languages that matched our other processing components, integration became seamless, instead of a bunch of wrapper hacks and the occasional (gak) fork to a shell. PHP. The domain of script kiddies.
Well, PHP has many flaws and all but I've had to maintain plain ASP/VB websites and PHP5 is miles better than that. PHP3 or ASP/VB?
That's like saying PHP is better than a poke in the eye with a sharp stick. Although true, it's irrelevant to the quality argument. I'll admit I have 3 PHP installs on my many websites mainly due to them not being the core of my revenue stream. One of these days I'll expunge the last of the PHP. Anyone know of a GOOD blogging software package that does not use PHP?
You cannot send headers after sending any output.
Which means include files (Which are obviously often run before code that sends headers.) cannot have such extra space.
That and the whole "byte order mark" garbage (0xEF 0xBB 0xBF) that some text editors insist on inserting into UTF-8 encoded text files.
What benefit do you get from re-inventing a language feature that's already there
Because the feature to pass a PHP array as the right side of SQL operator IN isn't already there, at least not in MySQLi. I invented this once, as a function that takes a MySQLi database object and an array and returns an escaped string appropriate for use with operator IN, and reused it throughout my employer's PHP-based products.
All modern languages provide facilities for doing things the right way, so what possible motive would you have for deliberately and painstakingly doing things the wrong way?
PHP is up to 5.4, but a lot of hosting providers aren't even up to 5.3.
It's one thing if you're the person writing the DB interface library that everything runs through and the database itself doesn't provide some kind of facility for helping you. [...] Not "well, not usually but..." or "there are some situations where...". No there aren't.
In cases I've seen, the alleged "some situations" arise from specific missing features in "the DB interface library that everything runs through" such that the application developer ends up having to write what amounts to an extension to the library, and this extension will involve escaping. So yes, there are in fact "some situations".
create a function that loops through an array and calls "bind param", or whatever MySQLi prepared statments use, for each value in the array.
As I understand it, $stmt->bind_param() is not designed to be called in a loop. It is a variadic function designed to be called once per call to $db->prepare(), with one string designating the type associated with each placeholder in the statement and one additional parameter passed by reference for each placeholder in the statement. If I were to try to bind one parameter at a time, the first call would raise an error that the parameter count does not match, in other words, that I didn't bind all the parameters in the first shot. From the documentation: "The number of variables and length of string types must match the parameters in the statement" (my emphasis on "number of variables").
If you arent running PHP under SuPHP you are a fucking moron anyways.
you are already using a programming language which is surely more capable than a stupid POSIX shell! (If not, you REALLY need to switch languages.)
Which is exactly the point: one needs to switch languages because according to the "fractal of bad design" essay all PHP has is a counterpart to system(), not a counterpart to exec*() or spawn*(): "There is, as far as I can tell, no way to safely spawn a process. You can ONLY execute a string via the shell." This goes double for Windows, where pcntl_*() is not implemented and escapeshellcmd and escapeshellarg have completely incorrect behavior. Even under Linux and FreeBSD, --enable-pcntl is turned off by default; PHP must be recompiled to turn it on.
Doesn't using mod-cgi require all your files to be in a folder like cgi-bin?
Not necessarily. I haven't set it up myself in a while, but the recipe involves SetHandler none, AddType to give PHP a content type, and an Action for that type that points to the PHP CGI binary.
All the free hosts I've used /seemed/ to use the Apache mod
I was under the impression that executing PHP programs as the owner of the program's file required CGI, not the module. The module can execute them only as Apache, which creates permissions problems for anything that writes to the file system, such as a file upload script or an SQLite database.
WTF are the dates written as DD-MM?
For some reason, Americans like to write MM-DD-YYYY just to screw up the sort order, but I've never seen anyone write DD-MM until today. That's just retarded.
In a multinational setting, YYYY-MM-DD is the preferred option. If the year is understood, then EVERYBODY (even Americans) agrees that it should always be MM-DD.
tl;dr: Only retards and trolls write dates as DD-MM.
... ship it!
@html.actionlink("link","blah", new { Page = Page });
More concise, and much more resilient to route changes.
Thankfully, almost everything using the MSVC runtime or the same algorithm it implements, which means you don't have to worry about how bad it is usually, but it's still a disaster.
Python for Windows has correct MSVC command escaping. PHP for Windows does not, I'm told. Therefore, you still "REALLY need to switch languages."
Hey arrogant twat, the rest of the civilised world writes it as DD-MM. Nobody, except Americans, thinks it should ever be MM-DD.
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
Is there a compelling reason to continue using cgi or have people just never changed to fcgi/mod_php?
I did a quick search for the term "string" in the Java bug database... Here's what I wound up with: http://search.oracle.com/search/search?search_p_main_operator=all&start=1&group=bugs.sun.com&q=string
This is 1 page I wound up with using "asp.net bug" with Google: http://threatpost.com/en_us/blogs/microsoft-release-emergency-patch-aspnet-bug-092710
Here's a list of Python bugs... http://bugs.python.org/
I would say that Ruby has bugs, but they're keeping their cards close to their chest with that one as you can't even see what they've acknowledged: http://bugs.ruby-lang.org/
C# obviously has bugs... http://msdn.microsoft.com/en-us/library/cc713578.aspx
Meet the new complainer, same as the old complainer... PHP isn't going anywhere anytime soon. Might as well get used to it. :.)
There's a LITTLE problem with your pronouncement (besides the unbecoming heat). It ain't so. China, Korea, Iran, Japan, Hungary, Lithuania, and Belize also put the month first. In addition Canada, Nepal, South Africa, Austria, Portugal, Sweden, Norway, Denmark, Philippines, and Saudi Arabia have mixed usage regards DD-MM/MM-DD. Where's your consensus now?
Actually there IS a true international consensus in the form of ISO 8601 International standard, which is YYYY-MM-DD. As of ISO 8601:2004, no component may be left out or truncated on either end. Unlike your favored format, this has the following advantages:
1) It is COMPLETELY unambiguous and requires no cultural agreement to interpret.
2) It sorts left-to-right just like any number or alpha string.
2a) Therefore when used as a part of a filename, files are properly sorted in a an alphabetical directory listing.
Face it, both US (MM-DD-YYYY) and other provincial conventions are stupid. Even if the US convention is a little more stupid than the (most of) European because it sorts NEITHER left-right nor right-left, they are BOTH stupid, There is absolutely NO reason whatsoever not to use ISO 8601 for ALL date specifications.
No, dipshit.
We write YYYY-MM-DD or DD.MM.YYYY