Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Recently Exposed PHP Hole's Official Fix Ineffective

timothy posted more than 2 years ago | from the considered-busted dept.

Bug 240

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."

cancel ×

240 comments

And (0)

colinrichardday (768814) | more than 2 years ago | (#39901349)

Why should I use PHP?

Re:And (2, Interesting)

jhoegl (638955) | more than 2 years ago | (#39901365)

No licensing
stable
no licensing
great track record
no licensing
flexable
no licensing
modules for everything
no licensing

Re:And (-1)

Anonymous Coward | more than 2 years ago | (#39901389)

I don't know much about php, but What I do know about it is that I just dropped a 2-pound mud mamba. Ahhhh, the relief of dropping a big shit. Second to none.

Re:And (0, Funny)

Anonymous Coward | more than 2 years ago | (#39901651)

Ahhhh, the relief of dropping a big shit. Second to none.

This guy seems to know more about PHP than he's letting on.

false - PHP has various licensing (4, Informative)

rubycodez (864176) | more than 2 years ago | (#39901525)

http://php.net/license/index.php [php.net] 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.

Re:And (5, Interesting)

drunkennewfiemidget (712572) | more than 2 years ago | (#39901615)

> No licensing
Wrong [php.net]

> stable
This news post is proof that's wrong.

> great track record
Wrong. [veekun.com]

> flexable
About as flexible as your spelling.

> modules for everything
This is true. AND THEYRE ALL PART OF THE CORE API! ImageMagick, MySQL (THREE TIMES!), Curl, etc .. all in the core API.

PHP is a fucking disgrace and a blight on the world and needs to die a fiery death.

(Spend a few minutes reading the url I linked above at veekun.com for a wonderful break won on why PHP is a heinous pile of horseshit.)

Re:And (0)

drunkennewfiemidget (712572) | more than 2 years ago | (#39901671)

break DOWN, not break won.

Re:And (0)

Anonymous Coward | more than 2 years ago | (#39902195)

You even take dictation errors from yourself. Are you a psycho? And turn off your caps lock idiiioot(left dictations error for ou to correct).

Re:And (1)

DeathToBill (601486) | more than 2 years ago | (#39902535)

God, why do you never have modpoints when you want them? This deserves so much better than '-1, Troll'.

Re:And (5, Insightful)

Richard_at_work (517087) | more than 2 years ago | (#39901821)

Out of interest, what does the "great track record" refer to? The security has historically been consistently horrific, the performance has historically been consistently horrific, the consistency of the language has been consistently horrific, the development of the language has been consistently horrific...

I do miss the documentation, now that was awesome. But I don't miss the rest of it.

Re:And (5, Funny)

Anonymous Coward | more than 2 years ago | (#39902377)

Out of interest, what does the "great track record" refer to? The security has historically been consistently horrific, the performance has historically been consistently horrific, the consistency of the language has been consistently horrific, the development of the language has been consistently horrific...

They do have a great track record at being consistently horrific...

Re:And (0)

l0ungeb0y (442022) | more than 2 years ago | (#39902141)

You can say the same thing about Ruby on Rails

Which has MORE MODULES and a more coherent development community, commandline tools like RAKE that are actually useful and not just have assed scripts put in as an afterthought, an honest to god DBAL/ORM that works as advertised, in fact it works so well people complain it results in coders that have no clue about how a database works, because they are so abstracted from it to the point it becomes almost a magical blackbox to them.

Oh and Ruby isn't constantly pulling the plug on releases -- major PHP5 feature rollback? PHP6 falls on it's face? -- Seriously WTF is wrong with the core PHP team?

Frankly, I spent years doing PHP development and it is clear they have lost their way and such, they have lost me as a developer.
Now days I evangelize RoR for startups looking for a scalable solution

Here's an exercise:

Create an HTML5 website with mobile web version and REST based API accepting and sending both XML and JSON using OAuth for remote authentication. You must support user registration, profile editing with photo uploading with thumbnail generation, a session model for secure sign-in from a web form (for non-api users), a secured content model for shared postings of mixed media (text, photos and video) that only allows edits by the creator, and we want automatic detection of mobile users and to have them stay in the same domain as the non-mobile users, but be given a mobile-friendly UI. You have 1 day -- it doesn't have to look pretty, but it has to be 100% feature complete and work 100%.

If you're doing this with PHP+Zend (or any other PHP framework) you might as well just quit now -- You'll get smoked by RoR.
In fact, I'd confidently say you can't get this done in a week with PHP+Zend, another framework might enable that though.

Re:And (-1)

Anonymous Coward | more than 2 years ago | (#39902249)

Nice advert, shill.

Do you also suck DDH's dick on a daily basis too?

Fuck Ruby. Fuck Rails.

Re:And (0)

Anonymous Coward | more than 2 years ago | (#39902695)

What you're asking for is easily done by simply throwing in one of the many web frameworks available for PHP and a number of plugins or whatever written for said framework. I've no idea why you'd want to do it from scratch, or using the Zend engine. That's just re-inventing the wheel and what the hell is the point in that? It proves nothing.

And Ruby isn't exactly what I'd call a very nice language either. Nor is RoR as awesome as you make it out to be, just look at that recent hijack of the RoR project's hosting itself.

Having said all this, PHP is indeed a horrible language. I've honestly never seen such a horribly incosistent mess anywhere else. Thank god for languages like Haskell, the lisps, and similar.

You shouldn't. Nobody should. (1, Insightful)

Anonymous Coward | more than 2 years ago | (#39901441)

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.

Re:You shouldn't. Nobody should. (0, Interesting)

Anonymous Coward | more than 2 years ago | (#39901521)

This SO hard.

This doesn't even touch on the horrible base code itself that is horribly flawed, errors that will happily continue being processed where any other normal language would scream your face off. (which could get seriously bad when used in exploits)

I think everyone here should have a good hard read of this.
PHP: A fractal of bad design
Long story short, most of the language is inconsistent with respect to most other languages.
Some errors you'd normally expect to be shown in other languages relating to processing data happily continue, no questions asked.
Horrible chains of flags that are dependent on each other that can change program behavior.
Inconsistent variable, array and any other handling of types.
=== is broken. As well as various other operators and access methods ( [] and {} )
Many others.

After using PHP for a while, I would seriously rather use ASP or VB. At least they are consistent. (but don't, really, don't use either)
The language is such a terrible hack of a language.
Use one of the many other far better and robust languages like the ones mentioned in parent.
PHP seriously isn't worth the effort. A language that isn't predictable and requires you to learn a hundred different quirks and hacks is just embarrassing.

Re:You shouldn't. Nobody should. (3, Insightful)

mikael_j (106439) | more than 2 years ago | (#39901569)

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? Well, that's a little tougher but PHP5 is just so much better than VB. As for ASP.NET (using VB or C#), that's a whole other thing. PHP doesn't compare very well to C#.NET or even VB.NET (yes, I know both are .NET and have pretty much the same features, C# is just a more pleasant language to work with).

Re:You shouldn't. Nobody should. (3, Insightful)

mcavic (2007672) | more than 2 years ago | (#39901977)

requires you to learn a hundred different quirks and hacks

I really don't know what quirks and hacks you're talking about. Any language has to be learned, and as long as you escape your strings before passing them to MySQL, sendmail, or another application, PHP is secure. The hole they're talking about here is an escaping problem. Although it sounds like this is actually a flaw in PHP, the method that makes it possible shouldn't be used today anyway. And you're not going to avoid escaping problems in any language that does what you're doing in PHP.

Re:You shouldn't. Nobody should. (4, Insightful)

Just Some Guy (3352) | more than 2 years ago | (#39902181)

as long as you escape your strings before passing them to MySQL

You know, I only hear PHP developers saying stupid shit like that. No one in Python talks about escaping strings (unless they're writing database libraries). Rubyists don't escape strings. Perl monks sure as hell don't escape strings. VB(\.Net)? programmers might escape strings, but we don't really count them. No one escapes strings anymore because it's stupid, error prone, and dangerous.

And yet PHP coderz still do it. Why? Oh, right: because the official docs teach them to [php.net] :

// Formulate Query
// This is the best way to perform an SQL query
// For more examples, see mysql_real_escape_string()
$query = sprintf("SELECT firstname, lastname, address, age FROM friends
WHERE firstname='%s' AND lastname='%s'",
mysql_real_escape_string($firstname),
mysql_real_escape_string($lastname));

// Perform Query
$result = mysql_query($query);

Fucking hell. In 2012, we're still exposing newbies to that idiocy, and when they do it poorly and some kid in Latvia owns a major PHP project as a result, defenders jump out to yell "it's the programmer, not the language!"

Re:You shouldn't. Nobody should. (1, Funny)

mcavic (2007672) | more than 2 years ago | (#39902309)

Of course it's error-prone, but how else can you avoid SQL injection in any language?

Re:You shouldn't. Nobody should. (0)

Anonymous Coward | more than 2 years ago | (#39902353)

Prepared statements with parameterized querys.
 

Re:You shouldn't. Nobody should. (1, Insightful)

mcavic (2007672) | more than 2 years ago | (#39902421)

So do it yourself. Sanitize your variables, prepare your statement, and then pass it. If you're going to use a language, you should be able to use it correctly. And it's really not that much of a chore once you're used to it. Even if SQL wasn't an issue, you still have to sanitize other things like shell commands.

Way to miss the point. (1)

Anonymous Coward | more than 2 years ago | (#39902469)

Reread the parent post again. And again.

Re:You shouldn't. Nobody should. (1)

Just Some Guy (3352) | more than 2 years ago | (#39902525)

So do it yourself. Sanitize your variables, prepare your statement, and then pass it.

You're wrong. Not difference-of-opinion wrong, but factually-incorrect wrong. What benefit do you get from re-inventing a language feature that's already there and (well, hypothetically in the case of PHP) well tested? Do you also write your own for loops with goto because it's more flexible?

And it's really not that much of a chore once you're used to it.

I swear to God, I hope you're trolling. Why make it a chore at all instead of letting the language libraries handle it? In your own words: if you're going to use a language, you should be able use it correctly. 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?

Even if SQL wasn't an issue, you still have to sanitize other things like shell commands.

So keep sanitizing shell commands until PHP catches up to other languages there, but do things the easy and right way in your database logic. You're allowed to use both a hammer and a pliers for different tasks, you know.

Re:You shouldn't. Nobody should. (1)

Stormtrooper42 (1850242) | more than 2 years ago | (#39902579)

Exactly.
And it does exists in PHP.
You can do that with PDO [php.net] for example, which is also database agnostic.

Re:You shouldn't. Nobody should. (4, Informative)

Just Some Guy (3352) | more than 2 years ago | (#39902395)

Prepared statements [php.net] . Even PHP supports them, although they don't emphasize that fact enough (such as by causing calls to mysql_query to segfault, or ideally make the server hosting it catch on fire).

I say that in humor, but I'm actually dead serious about always using prepared statements - in any language - over directly executing concatenated query strings. 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. In that case, you go to heroic lengths to test, test, test that your library is bulletproof. But most people aren't writing client libraries; they're writing apps that use them. Those people should never be manually building query strings. Not "well, not usually but..." or "there are some situations where...". No there aren't. Don't do that or let anyone else around you do it, either.

Re:You shouldn't. Nobody should. (2)

mikael_j (106439) | more than 2 years ago | (#39902461)

There's no need to escape things before passing them to MySQL, just use PDO (or mysqli) prepared statements.

Re:You shouldn't. Nobody should. (0)

Anonymous Coward | more than 2 years ago | (#39901537)

Although I am almost in complete agreement with you, providing links to such libraries and frameworks helps to validate your point. C# is a great language, but on its own may not be the most convincing to a PHP programmer. Bring some insight to your argument.

Re:You shouldn't. Nobody should. (4, Interesting)

rubycodez (864176) | more than 2 years ago | (#39901551)

There is ignorance, all right, between your ears. All languages have security flaws and need constant patches. PHP has robust and well tested frameworks with libraries to sanitise potentially dangerous input. There is nothing that can be done in say Ruby (my favorite language) that cannot also be done well in PHP. PHP now even has closures, lamda, internal iterators....

Re:You shouldn't. Nobody should. (-1)

Anonymous Coward | more than 2 years ago | (#39901581)

LOL! Oh, my. LOL!

Re:You shouldn't. Nobody should. (2)

rubycodez (864176) | more than 2 years ago | (#39901631)

That is your counterargument?

Re:You shouldn't. Nobody should. (-1)

Anonymous Coward | more than 2 years ago | (#39901745)

Dude, there's nothing to argue here. You made a really stupid comment, and laughing at it is the only proper response. The GP has won, my friend. And I'm going to join him in a good laugh at your expense: Lol!

Re:You shouldn't. Nobody should. (0)

rubycodez (864176) | more than 2 years ago | (#39901843)

Tens of billions of dollars a year say you have a foolish point of view that is not held by successful people and business. You post as AC because you are a serial loser, of arguments and life.

Re:You shouldn't. Nobody should. (0)

Anonymous Coward | more than 2 years ago | (#39902407)

It's a good thing that you're using your real name here, rubycodez, and not some sort of an alias. Otherwise, we'd have to think you're posting anonymously.

Re:You shouldn't. Nobody should. (0)

Anonymous Coward | more than 2 years ago | (#39901589)

A good language makes it easy to do things right and hard to do them wrong. PHP makes getting security right hard and leaving you vulnerable easy. THAT is what makes PHP a bad language.

Re:You shouldn't. Nobody should. (2)

rubycodez (864176) | more than 2 years ago | (#39901621)

As compared to say C or C++? Nonsense, proper programming techniques must be done in ANY language for stability, scalability, security.

Re:You shouldn't. Nobody should. (0)

Anonymous Coward | more than 2 years ago | (#39901873)

If you write web-facing code in C (or in any other non-"managed" language), you have it coming.

Re:You shouldn't. Nobody should. (1)

TheRaven64 (641858) | more than 2 years ago | (#39901917)

Yes indeed, C and C++ are the languages I always think of when it comes to web development. Most especially used with the StrawMan++ framework.

Re:You shouldn't. Nobody should. (1, Troll)

rubycodez (864176) | more than 2 years ago | (#39901971)

oh, your company's httpd and its modules are written in a script, and not C? do tell. your web framework language of choice isn't written in C or C++, do tell. Of course YOU DO use C or C++ for web facing wares.

Re:You shouldn't. Nobody should. (4, Funny)

rgbrenner (317308) | more than 2 years ago | (#39902323)

Apache is old news. It's bloated and there are security advisories for it all the time. I can't believe anyone uses that anymore. I, like many other admins, start by writing a webserver using the bourne shell:
http://sprocket.io/blog/2008/03/writing-a-web-server-in-bourne-shell/ [sprocket.io]

Then, all of the web development is done using LISP. LISP is much cleaner to write a CGI program in than the bourne shell. Here's a CGI LISP tutorial that includes a comparison of the two:
http://cybertiggyr.com/lc/ [cybertiggyr.com]

No need to thank me for getting you up to speed on the latest web development techniques... but you're welcome.

Re:You shouldn't. Nobody should. (1)

Stormtrooper42 (1850242) | more than 2 years ago | (#39902627)

When I started reading your comment, I thought you were going to write something serious, about nginx or lighttpd... You got me.

Re:You shouldn't. Nobody should. (0)

Anonymous Coward | more than 2 years ago | (#39902533)

Stop pretending to be stupid. Writing a webserver is not web development.

Re:You shouldn't. Nobody should. (1)

mcavic (2007672) | more than 2 years ago | (#39902015)

Yes, it does make security hard. But I don't think it's the language. I think it's the fact that you're interfacing a web server, a backend script, and MySQL database. Most of the insecurity has to do with the interfacing, not the script itself.

Re:You shouldn't. Nobody should. (1)

SendBot (29932) | more than 2 years ago | (#39902697)

A good language makes it easy to do things right and hard to do them wrong.

Then for your paranoid sake, stay the hell away from Javascript! Actually... you'd better stay away from computers all together. Just back away slowly, and get a friend to unplug it for you. If you don't have any friends, just set the house on fire and you'll make some new ones pretty quick.

Re:You shouldn't. Nobody should. (1)

Anonymous Coward | more than 2 years ago | (#39901613)

Ruby is your favorite language? Oh you poor soul.

Re:You shouldn't. Nobody should. (1)

rubycodez (864176) | more than 2 years ago | (#39901725)

No, I'm quite well paid, thank you very much.

Re:You shouldn't. Nobody should. (4, Insightful)

digitalaudiorock (1130835) | more than 2 years ago | (#39901941)

Yea, this PHP bashing here gets really old. Sure, the fact that it's a high level language attracts some clueless programmers that write bad code, but that's not the languages fault. I happen to be in a position right now where I do most of my coding in PHP. There are in fact things about it that drive me crazy, but the fact is that you can write great stuff with PHP and you can do it very quickly. As far as this exploit goes, who actually uses PHP in cgi mode rather than as an Apache module?

Re:You shouldn't. Nobody should. (2)

History's Coming To (1059484) | more than 2 years ago | (#39902155)

"who actually uses PHP in cgi mode rather than as an Apache module?"

Precisely - I've never heard of anyone doing it that way. And that veekun article has certainly made me think that the billions of PHP based sites that have never had a problem will soon realise their folly! Mwahaetc.

Re:You shouldn't. Nobody should. (1)

Overly Critical Guy (663429) | more than 2 years ago | (#39902611)

You know, every time I see someone on a forum defend PHP, they eventually admit that they write PHP for their job. If you have a vested financial interest in PHP, it's understandable that you'd have a desire to defend your source of income, but it doesn't change the fact that PHP is objectively a terrible language. Just because the PHP bashing is old doesn't make it wrong.

PHP: a fractal of bad design (0)

Anonymous Coward | more than 2 years ago | (#39902031)

PHP: a fractal of bad design [veekun.com] (obligatory).

Re:You shouldn't. Nobody should. (2, Insightful)

Just Some Guy (3352) | more than 2 years ago | (#39902133)

There is nothing that can be done in say Ruby (my favorite language) that cannot also be done well in PHP.

In a theoretical computer science sense, you're correct. In practice, you couldn't be more wrong. In nearly 20 years of development, PHP has never managed to do things the right way on any objective scale. For example, last year PHP had a major crypto bug [slashdot.org] in a released version which failed unit tests. Let me repeat that: PHP's own unit tests failed but they still shipped it, distributing a major security flaw to all users.

PHP is unfit for major software development, and PHP's authors and maintainers are unfit to write and maintain it. Yeah, I said it. Yes, it's "just as good" as Ruby, Python, or other competing problem-space solutions in a strict Turing-completeness way, but in all pragmatic senses it has been a complete and utter rolling disaster.

Yes, it's popular. So are McDonald's hamburgers. That doesn't mean I'd want to deal with either on a regular basis.

Re:You shouldn't. Nobody should. (1)

rubycodez (864176) | more than 2 years ago | (#39902239)

in practice, you couldn't be more silly, you link to article about people who call crypt() with only an md5 salt? what idiot does that? not any wares I've ever written nor seen.

Re:You shouldn't. Nobody should. (1)

Just Some Guy (3352) | more than 2 years ago | (#39902319)

in practice, you couldn't be more silly, you link to article about people who call crypt() with only an md5 salt? what idiot does that?

Your reading comprehension fails. People expect:

crypt('string', 'salt') === 'saQ9i9dEI8LLA';

to return TRUE. Instead, they got:

crypt('string', 'salt') === 'salt';

So if you used the crypt function to hash and store site passwords, you weren't really storing the hash: you were just storing the salt itself. And when it came time to verify that "hash but really just the salt" by comparing it with the user-submitted password that had been crypted with the same salt, the comparison always came back true. Joyous day!

not any wares I've ever written nor seen.

Ah, I think I've found the disconnect. Would you like a lollipop?

Re:You shouldn't. Nobody should. (1)

Overly Critical Guy (663429) | more than 2 years ago | (#39902603)

Are people seriously defending the use of PHP in 2012? You talk about testing when PHP doesn't even pass all its own tests according to the official website.

PHP's creator has publicly stated that he is not a programmer and is not interested in being one, that he didn't set out to create a programming language, and so forth.

When I see people defending PHP, I have the same reaction I get when I see Scientologists defending a religion started by a science fiction author.

Re:You shouldn't. Nobody should. (1)

LVSlushdat (854194) | more than 2 years ago | (#39901585)

Yeah.. I'm gonna listen to a flippin' AC on whether I should use PHP or not... I laugh...

Re:You shouldn't. Nobody should. (-1)

Anonymous Coward | more than 2 years ago | (#39901597)

Ruby? RUBY!?!

You're honestly putting Ruby in the group of languages better than PHP? Are you high?

No one. And I mean no one should be using Ruby. Espeically Rails. Using Ruby is a far more worse decision than using PHP.

Re:You shouldn't. Nobody should. (1, Interesting)

TheRaven64 (641858) | more than 2 years ago | (#39901923)

Ruby's not that bad, if you can manage to avoid having any interaction with the Ruby community...

Re:You shouldn't. Nobody should. (-1)

Anonymous Coward | more than 2 years ago | (#39902061)

The community is the main reason to avoid the language all together. If the other users that you turn to for help are nothing but a bunch of elitist Mac-using hopster pricks, then that's your cue to stay away from that launage at all costs.

Re:And (1)

mcavic (2007672) | more than 2 years ago | (#39901919)

It's very fast and flexible for both Web backends and standalone applications.

the php-cgi receives a processed query string parameter as command line arguments

That's a bad setup anyway, and shouldn't be needed this century.

Cm'on (0)

Anonymous Coward | more than 2 years ago | (#39901355)

Who runs a site in PHP that is worth exploiting?

Re:Cm'on (2)

SolarCanine (892620) | more than 2 years ago | (#39901387)

Facebook, but if the question is "Who runs a site in PHP using CGI mode that is worth exploiting?" then it gets harder to answer.

Re:Cm'on (5, Interesting)

nickdc (1444247) | more than 2 years ago | (#39901539)

The answer is Facebook, and I got a job by using this bug against them! see [facebook.com] ?

Re:Cm'on (1)

19thNervousBreakdown (768619) | more than 2 years ago | (#39901787)

Did they not put a closing tag there just to drive us insane?> Argh!

Re:Cm'on (1)

atisss (1661313) | more than 2 years ago | (#39901929)

Actually it's sane to not put a closing tag, as you might accidentally add newline or space after that, which could in some cases result in invalid response (for example xmlrpc). Especially hard to debug if it's inside some included class and breaks xmlrpc server.

However the real question is - who runs PHP using CGI mode? It's 21 century.

Re:Cm'on (3, Informative)

19thNervousBreakdown (768619) | more than 2 years ago | (#39902049)

Huh, the practice is even recommended by Zend [zend.com] . Isn't PHP great, where a closing tag is a vector for bugs?

Re:Cm'on (1)

atisss (1661313) | more than 2 years ago | (#39902337)

That would be just language specifics if used outside it's purpose.

For generating HTML there is no problems with having leading/trailing spaces, however if your output needs to be strictly formatted, you wouldn't output some unrelated \n just for fun.

Re:Cm'on (1)

DavidTC (10147) | more than 2 years ago | (#39902693)

For generating HTML there is no problems with having leading/trailing spaces,

Uh, yes, there is. 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.

Re:Cm'on (1)

mcavic (2007672) | more than 2 years ago | (#39902073)

Interesting. That has to be intentional, though. It shouldn't happen by accident.

Re:Cm'on (3, Insightful)

hendridm (302246) | more than 2 years ago | (#39901483)

Millions of people.

What is worth exploiting? Anything that you can turn into a node in your massive botnet.

Re:Cm'on (0)

Anonymous Coward | more than 2 years ago | (#39901553)

.... and is not already exploitable in some other way

Extra! Extra! Read all about it! (0, Troll)

drunkennewfiemidget (712572) | more than 2 years ago | (#39901359)

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.

I finally know what PHP stands for. (4, Funny)

DieByWire (744043) | more than 2 years ago | (#39901367)

PHP: Pretty Hard to Protect.

Re:I finally know what PHP stands for. (2)

gstrickler (920733) | more than 2 years ago | (#39901433)

I thought it meant Pointy Haired Programmers.

Re:I finally know what PHP stands for. (0)

Anonymous Coward | more than 2 years ago | (#39901467)

No, you're wrong. "PHP" originally stood for "Personal Home Page", but these days it stands for "PHP: Hypertext Preprocessor".

Re:I finally know what PHP stands for. (0)

Anonymous Coward | more than 2 years ago | (#39901593)

Uh oh... Your check engine light must be on because I assume your sarcasm sensors have gone out! Then again I know many people who have a hard time with sarcasm who would have figured this one out rather quickly.

Re:I finally know what PHP stands for. (1)

MurukeshM (1901690) | more than 2 years ago | (#39901641)

You must be a PHP developer, probably of the team that "patched" this hole.

Re:I finally know what PHP stands for. (1)

jo42 (227475) | more than 2 years ago | (#39901487)

Piled High Poop more like it.

PHP Objected Oriented Programming: POOP.

Re:I finally know what PHP stands for. (0)

Anonymous Coward | more than 2 years ago | (#39901743)

PHP: Headless Patchers

Microsoft Sux! (-1)

Anonymous Coward | more than 2 years ago | (#39901385)

This is just what you expect from Microsoft. If PHP were open source it wouldn't have these problems.

Re:Microsoft Sux! (0)

Anonymous Coward | more than 2 years ago | (#39901439)

Learn 2 troll.

Re:Microsoft Sux! (4, Funny)

sammyF70 (1154563) | more than 2 years ago | (#39901453)

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

Re:Microsoft Sux! (-1)

Anonymous Coward | more than 2 years ago | (#39901627)

This fucking pile of dumb shit is Insightful? Does every last moderator have this guy's tiny dick in their bleeding asshole?

Re:Microsoft Sux! (1)

Yobgod Ababua (68687) | more than 2 years ago | (#39902105)

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

[a href="https://blah.com/blah/blah/[?php echo $page; ?]"]LINK[/a]

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.

Re:Microsoft Sux! (1)

drunkennewfiemidget (712572) | more than 2 years ago | (#39902169)

mod_perl? 2001 called. It wants its web dev back.

Look into fastcgi and catalyst.

Actual Details... (5, Informative)

Anonymous Coward | more than 2 years ago | (#39901405)

Available from the source [eindbazen.net] , 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.

Problem solved (0)

Anonymous Coward | more than 2 years ago | (#39901411)

They should've been using models instead of CGI.

Re:Problem solved (1)

asdf7890 (1518587) | more than 2 years ago | (#39901491)

It is a while since I last used PHP in a shared environment, but last I heard mod_php could not impersonate the owner of the running script for security purpoeses, where running php in cgi or fastcgi modes does allow this option. This has security implications when not all the users on a server completely 1005 trust each other, and even if they do it prevents accidental escalation of bugs/problems in one user's code such that it affects other user's data.

Unless this deficiency in mod_php has been addressed, there are perfectly valid reasons to be running PHP in CGI (or preferably FastCGI) mode.

Re:Problem solved (0)

Anonymous Coward | more than 2 years ago | (#39901789)

Why can people not understand jokes in the comments of this Article?

Training wheels without the bike (5, Informative)

A beautiful mind (821714) | more than 2 years ago | (#39901471)

I think this short snippet from Rasmus is priceless:

The point of the question here is if anybody remembers why we decided not
to parse command line args for the cgi version? I could easily see it
being useful to be able to write a cgi script like:

    #!/usr/local/bin/php-cgi -d include_path=/path

and have it work both from the command line and from a web context.

As far as I can tell this wouldn't conflict with anything, but somebody at
some point must have had a reason for disallowing this.

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:

13-01: Vulnerability discovered, used to pwn Nullcon Hackim 2012 scoreboard
13-01: We discuss the issue with Nullcon admins, find out it is a php 0day
17-01: We contact security@php.net with a full report and a suggested patch
01-02: We ask PHP to confirm receipt, state our intent to hand off the vulnerability to CERT if progress is not made
01-02: PHP forwards vulnerability report to PHP CGI maintainer
23-02: CERT acknowledges receipt of vulnerability and attempts to contact PHP.
05-04: We ask CERT for a status update
05-04: CERT responds saying that PHP is still working on a fix
20-04: We ask CERT to proceed with disclosure unless a patch is imminent
26-04: CERT prepares draft advisory.
02-05: CERT notifies us that PHP is testing a patch and would like more time. we agree.
03-05: Someone posts a mirror of the internal PHP bug to reddit /r/netsec /r/opensource and /r/technology. It was apparently accidentaly marked public.

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.

Just a little reminder (2)

SmallFurryCreature (593017) | more than 2 years ago | (#39901779)

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 [google.nl]

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.

Re:Just a little reminder (0)

Anonymous Coward | more than 2 years ago | (#39902601)

You can set object properties with hash in ActiveRecord. And if you want to set object properties from hash, generated from url, you must use attr_accessible to whitelist accessible attributes or attr_protected if you want to blacklist. These methods were there for ages, and everybody knew about potential dangers. Just github programmers made terrible mistake and now it is big news.

I still think this is not a security bug. Oh well, I must be stupid fanboi.

Re:Training wheels without the bike (3, Insightful)

Anonymous Coward | more than 2 years ago | (#39901835)

I agree this is a pretty pathetic show of professionalism from the PHP team's part.

The bug is serious, i don't know why there was even any discussion of whether or not it is a bug. It's a textbook case of not properly handling user input.

The only thing that dampens the impact of this, is that it only impacts the CGI version of PHP. Most installations that i'm aware off, use PHP in either a SAPI or FastCGI setting, which as far as i'm aware do not use the codepath that contains this bug.

I use PHP pretty heavily in my job, but i'm getting more and more tired of the way the project is ran. The project has some pretty clear issues that all seem to take ages getting resolved. I've often contemplated wether or not it would be worth making a fork of the project (for internal use in the company where i work) just so we could fix some of the major issues that have fouled PHP for ages now. I'm aware of several OSS projects that are attempting the same, but unfortunately none of them appear stable enough to be used for business critical applications, which makes me fear that i underestimate the amount of work that needs to be done to polish this turd.

Now that magic quotes and register globals have finally been killed off after years of working around that mess, i started hoping that someone on the PHP team grew some balls and was beginning to push through some of the glaringly obvious fixes to PHP.

With reasonable namespace support, there's no reason why all of PHP's functions should still be in the global namespace, and segregating them in the appropriate namespaces would finally give them a chance to fix the annoying differences in function naming and argument order, that PHP still has (for legacy reasons). This would clean up PHP tremendously for new users and would only pose a small adjustment on current users. A single configuration directive (disabled by default) could simply recreate the old functions in the global namespace, make them throw a E_STRICT notice (or something similar), and call the appropriate function from its new location.

Many of the older/core PHP functions still use errors or empty return values, whereas all the new stuff uses Exceptions. Many experienced developers tie those together by using things like ErrorExceptions but this should just be overhauled into 1 single style (Exceptions being the most powerful one, those should probably be standardized on).

Ever since version 5, PHP has made good progress moving towards an object oriented style of programming. However since the scalar types (String, integer, boolean, etc) are not considered to be objects, and very different rules are placed on objects compared to non-objects, another conflicting style of programming is presented. Scalar values should be able to be treated as objects (even if they're not on a fundemental level) to unify things like type hinting and passing by value/reference.

It is my feeling that these changes would greatly improve the usability of PHP for both new and seasoned developers. It would simplify the language, and make it more powerful at the same time.

Re:Training wheels without the bike (1)

youn (1516637) | more than 2 years ago | (#39901957)

Any, love you man! I may not agree with all your opinions, but they are often very interesting. We are all waiting impatiently for your forked rewritten version of PHP :p

Re:Training wheels without the bike (0)

Anonymous Coward | more than 2 years ago | (#39901979)

This has been mentioned already in this thread, but if you have not read it you really need to. Also be sure to wade through the comments:

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ [veekun.com]

Re:Training wheels without the bike (0)

Anonymous Coward | more than 2 years ago | (#39902669)

Yes, Rasmus and friends are soooo stupid, and you are soooo smart. That's why they have made and are running the web's biggest script language, and why you are one of the users of the free product.

Ignorant asshole.

htaccess fix and shared hosting is why (2)

colfer (619105) | more than 2 years ago | (#39901557)

My web host pushed this patch into user htaccess for those users clueful enough to be running php as cgi:
    RewriteEngine on
    RewriteCond %{QUERY_STRING} ^[^=]*$
    RewriteCond %{QUERY_STRING} %2d|- [NC]
    RewriteRule .? - [F,L]

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.)

Re:htaccess fix and shared hosting is why (1)

Skal Tura (595728) | more than 2 years ago | (#39901681)

also it seems that lighttpd+php-fastcgi is not vulnerable.

Re:htaccess fix and shared hosting is why (0)

julesh (229690) | more than 2 years ago | (#39902041)

Why on Earth would you want a web-facing page to be able to manipulate files? Correct file handling in a web context is notoriously difficult, and is often a source of security problems (particularly if the files are uploaded). The best thing to do would be to store any data you want to use on a database; then it doesn't matter what UID your scripts run under.

Re:htaccess fix and shared hosting is why (1)

colfer (619105) | more than 2 years ago | (#39902297)

Wordpress. Or any upload system that stores images as files not database blobs! Maybe blobs are a better way, don't know, just talking practically, basic web hosting stuff.

Re:htaccess fix and shared hosting is why (0)

Anonymous Coward | more than 2 years ago | (#39902667)

Thanks for the patch and explanation. You arent upvoted enough.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...