Month of PHP Bugs Has Begun 165
An anonymous reader writes "The previously announced Month of PHP Bugs started three days ago, and already lists 8 security vulnerabilities in PHP and PHP related software. From the site: 'This initiative is an effort to improve the security of PHP. However we will not concentrate on problems in the PHP language that might result in insecure PHP applications, but on security vulnerabilities in the PHP core. During March 2007 old and new security vulnerabilities in the Zend Engine, the PHP core and the PHP extensions will be disclosed on a day by day basis. We will also point out necessary changes in the current vulnerability management process used by the PHP Security Response Team.'"
Defective by Design? (Score:5, Interesting)
We see a lot of people use the phrase "defective by design" when talking about Vista and in that instance I'm pretty sure the use of the term is correct.
Having never used PHP but heard of its many security problems I'm wondering: Is PHP defective by design? If so, why so and how would Slashdot seek to fix it?
Simon
Re: (Score:3, Interesting)
Not entirely joking. I use embedded perl for my own dynamic sites, and keep track of the lists, and can't recall any serious known flaws with that implementation.
The vulnerabilities that keep popping up (and the fact that I already know and am comfortable with perl, have CPAN, can develop quickly especially now that I have my own base modules set up, etc) are one reason that I never really looked into PHP.
Re: (Score:1)
Use perl instead :)
Not entirely joking. I use embedded perl for my own dynamic sites, and keep track of the lists, and can't recall any serious known flaws with that implementation.
The vulnerabilities that keep popping up (and the fact that I already know and am comfortable with perl, have CPAN, can develop quickly especially now that I have my own base modules set up, etc) are one reason that I never really looked into PHP.
the problem with perl is that i tend to use it for system administration purposes rather than making websites. php is just better for making sites as it is generally setup OOTB, almost a de facto for apache. the programmer should be aware of general problems, the magic_quotes implementation was designed to help programmers, but i think it introduced more code paths.
Re:Defective by Design? (Score:5, Informative)
It was. A lot of work has been done in the last couple of major versions to fix this, but still a lot of installations are crippled in the name of backward compatibility.
Most of what we're seeing here though is just run-of-the-mill sloppy coding. Create a lot of references to a variable and overflow its (16-bit) reference count? Please. That should never have happened.
Fortunately, it seems most of the bugs released so far don't affect the majority of installations. We have a number of 'executing arbitrary PHP code can let somebody own your web server' -- well, most of us don't let random people run arbitrary PHP code anyway. We have some 'deserialising arbitrary data can let somebody own your web server' issues too, but then there has been a long-standing warning that PHP's deserialise function isn't secure anyway, so that shouldn't affect anyone who's been paying attention. We have some issues with the Zend Platform, but I'm not sure how many people have that installed. So far, the only issue to affect me, is the phpinfo XSS vulnerability -- and that just meant I had to delete my phpinfo.php file that I kept in the root of each domain I host.
Re: (Score:3, Interesting)
And phpBB is just one of many popular applications that do it...
Re: (Score:3, Insightful)
No, I wasn't. One more reason not to use phpBB, I guess.
Re: (Score:1)
Re: (Score:2)
Doesn't mean calling unserialize on untrusted data is a good idea. Unserialized data may be of any class, and code may be automatically executed in it during the unserialization process. This means an attacker may be able to execute code you were not expecting to be executed, potentially leading to any of a number of exploit scenarios. Unserializing untrusted data in PHP (and many other dynamic languages) is a bad
Re: (Score:2)
But they do $inputHash == $hash, and you can use the serialized syntax to make $inputHash = true;, which means that it will == any non-zero-length string. Very annoying gotchas like this can make PHP a nightmare.
Re: (Score:2)
But they do $inputHash == $hash, and you can use the serialized syntax to make $inputHash = true;, which means that it will == any non-zero-length string. Very annoying gotchas like this can make PHP a nightmare.
Strange, I'm looking at the code for phpBB2 v2.0.22 in my editor right now, and there is no occurrence of code like you mention. That sort of problem was cleared up well over a year ago, when it was first revealed to be a problem. In every case where unserialize() is used, its output is assigned t
Re: (Score:1, Informative)
Is PHP defective by design?
It was.
It still is. Security is not a property of software, or even software design. It's a property of the development process, and it's something that the core PHP developers have failed to get time and time again.
It's true, they've fixed some glaring problems over the past couple of major versions. But they've done it because they've been nagged and shamed into doing so. They still don't have proper processes in place, they still don't get it, and I'm pretty sure th
Re:Defective by Design? (Score:5, Interesting)
How I wish we could just junk the language and start again with something else; unfortunately, market pressures being what they are, I'm afraid we're stuck with it, at least for the time being.
Re: (Score:1)
Re:Defective by Design? (Score:5, Interesting)
Re:Defective by Design? (Score:5, Insightful)
It may never completely go away, but there are alternatives to using it.
Re: (Score:3, Informative)
It may never completely go away, but there are alternatives to using it.
Not really. Most of us in the off-the-shelf web package software development industry are constrained to develop in whatever's available on the servers our clients are likely to choose. An informal survey suggests that of 5 popular hosting providers in my local area, only 1 offers anything other than PHP or Perl/CGI in their basic level package. With this kind of support
Re: (Score:2)
Re: (Score:2)
I don't know about Ruby, but I do a lot of programming in Python. Let's see:
#!/usr/bin/python
a = 1
b = 1.
if a == b: print "they are the same"
if (a / 3) != (b / 3): print "they are not the same"
Oh, come on, where's that '===' operator when one needs it???!
Re: (Score:2)
would fix this for you if it really bothers you.
Re: (Score:2)
A major problem for PHP is still it's configureware mentality. No other programming language has a configure file. PHP started with it because it's also a web framework; which is somewhat understandable. However, they then proceeded to abuse the configuration file for all sorts of semantic behaviors, and the end result is that it's very HARD to program securely and portably at the same time. Make a configuration change, and tha
Re: (Score:2)
*ducks*
Re:Defective by Design? (Score:5, Informative)
if you left an open phpinfo() on your server (giving potential attackers access to filepaths, module version numbers, configuration options, apache server configuration options), you have a lot more to worry about than a little XSS.
unfortunatly, you're not alone [google.com].
Re: (Score:2)
Its bloody helpful.
Re: (Score:2)
Heh... guess I'm not the only idiot that does that. :) Even though I'm running 5.x and that bug doesn't affect me, I've known it was a stupid idea for a long time but laziness prevailed. You and the PHP bugs project have just given me the motivation to fix that!
Re: (Score:2)
Yes; I have set up my server to reject requests with GET/POST variables that have unrecognised names. The '[]' would trigger that rejection.
Re: (Score:1)
Defective by Design == DRM (Score:1)
The simplest fix (Score:1, Interesting)
Re: (Score:2)
Parent isn't flamebait (Score:2)
I just started using PHP a few months ago for a few utilities on one of my websites. There are a ton of things about the language that seem half-assed. In particular I'm thinking of:
- The entire mysql library, which I have to use right now because mysqli apparently isn't enabled by default in PHP 4 and my current host won't turn it on or upgrade to PHP 5. Why is the default behaviour to force the use of SQL injection-vulnerable code?
- There is no equivalent of a "contains" method
Re:Parent isn't flamebait (Score:5, Interesting)
strpos() return FALSE when it can't find the 'needle'. http://us2.php.net/strpos [php.net] Use a proper test (===) and you'll have all you need in a single statement.
Some people really LIKE dynamically-typed variables. It's not a bug or a problem. It's a design choice.
Your flamebait at the end (vbscript) does nothing to enhance your argument. Leave it off next time.
Re: (Score:1)
There is no equivalent of a "contains" method for the string class, with strpos() being the recommended alternative. strpos() returns 0 if a string doesn't contain the specified substring... or it contains it at position 0. So to do a true "does this string contain some substring?" check requires using both strpos() *and* a separate check between the substring and a new substring made from the original string but chopped off at the length of the substring you're checking for.
Use === with your comparison. Yes, dynamically typed variables can be a pain but only if you don't understand how to use them. Look at the following example:
//This does NOT evaluate to true because 0 is NOT === false //This WILL evaluate to true and echo happens because 0 == false
$inputstring = "This is my PHP script";
if(strpos($inputstring,"This") === false) echo "Not found in inputstring";
if(strpos($inputstring,"This") == false) echo "Not found in inputstring";
So your criticism of dynamically-typ
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
I've seen atrocious code where you can tell that just because the coder knows how to do a for loop in BASIC it means it can become the next Bill Gates.
Re:Defective by Design? (Score:5, Funny)
Re: (Score:2)
Re: (Score:3, Informative)
Also, using something like GRSec [grsecurity.net], or SELinux can further restrict what people could do if they did end up with a shell on your webserver. Although whether it's worth the effort to set up for everyone is another question.
You have never used PHP (Score:2)
You would hear of the many security problems of any language that's widely used in the internet. It's not that PHP is so insecure as that, the problem is that it's more exposed, so it needs to be more secure than other languages.
Part of the problem with the public image of PHP is that it's a purely "commercial" language, it lacks the nerdy appeal of Ruby or Lisp, for instance. Most of the comments you'll see here in Slashdot bemoaning PHP's sh
Month of bugs, will it change things for better? (Score:4, Interesting)
On the other hand, i bet a fair few of the released vunerabilities will be applicable for many websites that the company i work for hosts, and i know corperate policy doesn't include frequent updates to their envirioment, there's just to many sites, to many badly supported applications by/for customers, and just to damn many servers to work with easily, i can't imagine were the only such company with such problems... And it really makes me wonder if this will mean that many hundreds of our hosted websites will from now on be easily hackable by scriptkiddies
Should prove to be interesting times, and who knows maybe it will teach our admins to use yum/rpm's for their servers instead of compiling their own apache/php combinations
Re:Month of bugs, will it change things for better (Score:1)
Just in case.. (Score:4, Interesting)
Also version 4 predominates (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
In a shared-hosting situation, I can see why these would be a much bigger problem.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
http://toba.ath.cx:724/~eastein/ser.html [toba.ath.cx]
vulnerable (Score:1)
Typical (Score:3, Informative)
I more and more get the feeling that the PHP developers themselves do not properly understand the vulnerabilities any more, which leads to improper and I even dare to say incompetent handling of reports and fixes (many of which simply get applied somewhere down the road without proper announcement or mentioning anywhere in the CHANGELOG) as well as seemingly ignorance regarding more complex vulns that are just as relevant as the glaringly obvious ones but simply not as mass-exploitable by script kiddies.
And *this* is the big problem that PHP is facing today regarding enterprise support. Maybe Jon Doe's blog installation is not as mass-exploitable by a script kiddie any more as it used to be some years ago, yet Big Company's CMS is still vulnerable to complex attacks by an experienced attacker who might use published attacks that security experts know about, yet end users do not.
Re: (Score:2)
Yes, in a shared host environment it potentially allows users to bypass safe mode and open basedir restrictions, however information on how to properly secure PHP for a shared environment has been around for a LONG Time. Not one person on the development team you go so far as to call
Re: (Score:1)
Was there ever a proper back-port to PHP4 or proper announcement of this bug? I'm not exactly an expert on PHP internals but I imagine there might be possibilities to remedy this situation if desired.
Yep, you kinda got me there. This might be very, very hard to exploit by using other attack vectors like improper input handling or decoding by PHP itself. Although one mustn't forget that this
Re: (Score:2)
I believe serialize() [php.net] preserves references -- it certainly does in PHP5 -- and (as mentioned elsewhere [slashdot.org] in the discussion) several PHP applications unserialize() remote data (notably phpBB).
Now, since the bug is apparently PHP4 only (gigabytes worth of references notwithstanding), the Big Question is whether or not the PHP4 unserialize() restores references.
Re: (Score:2)
Don't beleive it (Score:1)
Not many.
Re: (Score:1, Troll)
And how many PHP applications are NOT FAULTY?
Not many!
-Don
Oh Nose! (Score:4, Funny)
I've found a very similar bug in GLIBC! This code will cause a segment violation!
Shock! Gasp! Horror!
Re: (Score:1)
Re: (Score:3, Informative)
Re: (Score:3, Informative)
I've observed that a lot of complaints about modern PHP derive from the fact that it's a dynamic interpreted language, but that in many ways it behaves like a compiled, angry, shoot-yourself-in-the-foot language, like C.
PHP will segfault, just like C, if you recurse too far on the stack, but almost every other scripting language has a mechanism for catching a stack overflow as an exception and then letting the programmer handle it. PHP in this case just crashes; even C allows you to register a function to
Re: (Score:2)
I've found a very similar bug in GLIBC!
int main(){
main();
}
This code will cause a segment violation!
Shock! Gasp! Horror!
Now you know why web pages aren't generally coded in C. There's a reason people use higher level languages for such tasks, and one of them is that you can NOT crash the server via
PHP taint what it should be (Score:2, Insightful)
Maybe. PHP is a wonderful interpreted language that makes creating a web application easy. The biggest problem with PHP are the entry-level programmers who don't understand the beast that is web programming.
Many PHP programmers don't understand th
Re:PHP taint what it should be (Score:4, Interesting)
Be Prepared? (Score:2, Insightful)
Best book to learn from (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2, Insightful)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
That depends on your application. I use Python for a lot of stuff, it's in fact the language I use most of the time.
But when you are coding a dynamic html site, there is no better alternative to PHP, at least not one that's so quick and easy to code. PHP performs admirably for the one task for which it was designed. It was designed in the same spirit of Python, that simple things should be easy and difficult things should be possible.
Being eas
Why not use a lovely PHP FrameWork then? (Score:1)
Why not use a lovely PHP FrameWork then? Like, um, say, Drupal [drupal.org]?
- - - -
You can't be ahead of the curve, if you're stuck in a loop.
Next Month... (Score:2)
Seriously, when does the Month of Oracle Bugs make its return? Or did the Month of Bugs folks simply chicken out when Larry Elison showed up at their house with a samurai sword?
Re: (Score:2)
http://www.xkcd.com/c225.html [xkcd.com]
Is there an alternative? (Score:1)
perl is very good at text processing as well.
Are there any PHP-to-C++ translators? If the bugs are sitting in the PHP interpreter itself, it might be safer to translate and compile the code.
"Only perl can parse Perl" - but maybe there are alternative PHP parsers/interpreters?
Why MOPB Matters (Score:2, Interesting)
Yes, a lot of the problems are sloppy coding, but too many are in the PHP core. How many web pages use the PHP-array-specific query-string
?foo[]=bar
- not many, you might think. How many use a PHP neste
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
I expect many of us have some heavy patching to do this month. PHP devs refused to take the opportunity to break BC and fix the language/runtime with PHP5.
When will OpenJDK be usable serverside? I think I'd prefer to spend the month converting a bunch of PHP apps to Java instead of applying patches.
not everything will benefit from the conversion. some objects take much time to construct in java, and generally things will perform worse. there are some things that can benefit from being a bean though. loading a huge array, of perhaps loginids statically would perhaps save some database work. it's hard to say. but for most people i would estimage 6-12 months for the conversions.
Re: (Score:1)
enjoy [ibm.com]
Re: (Score:2)
Because it is painfully obvious that you have no idea what you are doing, and thanks to PHP's lack of secuirty measures against inexperienced programmers, you are very likely creating tons of highly vulnerable programs.
Other languages tend to have much more secure APIs, letting you get away with not paying as much attention to security. Do yourself a favour and switch to one of them.
Re: (Score:1)
Because it is painfully obvious that you have no idea what you are doing, and thanks to PHP's lack of secuirty measures against inexperienced programmers, you are very likely creating tons of highly vulnerable programs.
Or it could be due to an existing code base. I for one do not wish to randomly hire new programmers and convert over 50000 lines of code. Just like I'm sure my bank is going to go ahead and convert all it's COBAL code to Ruby or Python one of these days.
Other languages tend to have much more secure APIs, letting you get away with not paying as much attention to security. Do yourself a favour and switch to one of them.
Right because not paying attention to security is what every programmer should do. Language doesn't make a secure program the programmer does.
Re: (Score:2)
So it is totally pointless for Java, or for that matter PHP, to protect against buffer overflows in the language? That is a utterly idiotic argument. Of course you can write insecure code in any language, but that doesn't mean it doesn't matter that it's much easier to accidentially make code insecure in one language than it is in another.
Especially when PHP's biggest
Re: (Score:2)
So do you have a trick to make all programmers suddenly experienced? No? Well, how about we have programming languages try to catch their worst mistakes in the meanwhile?
Re: (Score:2)
Yes, lots of people writing code in their parents' basements have a QA department. Brilliant idea.
Let me guess you are C hater
I have written hundreds of thousands of lines of code in C. It is one of my favourite languages.
My original point is that it's not just a matter of picking the "best" language.
No, it's about not picking the worst language - in this case, PHP.
Re: (Score:2)
And I am ignoring your "existing codebase" blathering because it is quite frankly not an interesting discussion in any way. So you're already stuck in the bog due to making a bad decision at the start - what does that have to do with the merit of one language over another?
Re: (Score:2)
Re: (Score:2)
This is true of C, and no other langauge. It is very much the job of the language to take the burden of security off the programmer and implement as much as possible of it automatically. Th
Re: (Score:2)
This is absolutely critical to get right in PHP, or you will most likely be toast. And it is not easy.
Re: (Score:1)
Re: (Score:1)
Next, 120% slower under [undisclosed] circumstances. Browser rendering, network setup, capabilities of server/client, will impact things.
Additional, and this also relates to your 3rd point, there are are wide variety of PHP accelerators [wikipedia.org] which give PHP quite a speed boost
Re: (Score:1)
Re: (Score:2)
And I did a lot of testing in my company that showed that programming large html sites with database content in java is 5000% slower than in PHP.
No, I don't consider it fun either. OTOH, it's very quick and trivially easy, so that makes the lack of fun doing it irrelevant.
Re: (Score:2)
i did a lot of testing [ emphasis added - due skepticism displayed ] in my company that showed that creating large html forms from database content in php is 120% slower than in java.
While the VM's used won't have identical performance in all areas, and neither will the database libraries, your claim does not count for a hill of beans, not least given the following:
ever tried to access an oracle db from php? not fun
I don't find doing "./configure --with-oracle=/opt/path-to-oracle/" or indeed just copying a module across (if the hooks are already there) all that hard TBH.
in comparison to copying 1 .jar file to the server accessing oracle from php is not quick.
The only part that's any difference is having to install the Oracle libraries is if you are compiling support into PHP from scratch (i.e. with '--with-oracle='), othe
Re: (Score:2)
The really big thing that PHP gets right - and it's so big that people often don't even see it - is that deployment is really, truly, brain-dead simple. Write some code, drop it in a folder, and it just works. You *really* can't say that about Rails, where you can about, say, CakePHP. This is mainly because Rails isn't internally thread-safe, but that's only a problem because mod_ruby uses a single instance of the interpreter for all requests. That makes mod_ruby a distinctly unpopular dep