Slashdot Mirror
Month of PHP Bugs Has Begun
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.'"
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
To be honest i'm glad that this month of bugs is happening, after all the previous news items about how the core php / zend team is refusing to colaberate with some ppl who are deeply concerned about php's security (and by this we do mean mistakes/faults in the php engine, not in bad php programming).
:-)
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
To clarify, note that these bugs are related to the PHP core, not the language itself which may result in insecure applications. The statement that 8 security vulnerabilities in PHP and PHP related software is not referring to PHP software such as Wordpress. I mean seriously, I think I saw my dog hacking together a blog the other day using PHP. Everyone uses the language and not everyone has the background to know what they should and shouldn't be doing. In addition to its popularity, the language and its "libraries" make it easy for untrained coders to leave gapping holes in the code. Don't get me wrong, I love PHP (to an extend), I make a living out of it but any attempt at fixing "PHP related software" directly (ie: wordpress,phpbb,oscommerce,etc) would take more than a month.
[alk]
There are so many "Get me a portal, quick" / "I want to create a CMS that will make me rich" websites based on PHP based solutions that this exercise becomes obviously very important. It's surprising how many of such websites are severly insecure.
Beware of the unexpected behavior of a program... it brings joy to hackers all around the world.
"Defective by Design" usually refers to DRM, since that is what the FSF's campaign against DRM is called.
Brought to you by the numbers π, e, and 0x1B.
One of the biggest problems with PHP is the die-hard adherance to backwards compatibility. Functions don't get deprecated, the API doesn't change, it gets overloaded with nearly-the-same but-not-quite methods so that somewhere, somebody doesn't complain about how their website "broke" with the latest release--never mind the fact that by using insecure functions, their sites are already broke.
I've used PHP5 exclusively for over a year, for well-publicized reasons.
My turnips listen for the soft cry of your love
Why UNIX?
It's a legitimate question.
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 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.
- Dynamically-typed variables. Worst code/script idea evar. Yes, I realize PHP is not alone in this.
Basically to me it looks like the *ix version of VBScript. In its favour, it does use curly braces instead of MS' stupid "If something Then doSomeOtherThing End If" syntax.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
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.
Why UNIX?
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.
:/- spoon(_).
Yes, but how many sites get hacked because of PHP and not because of faulty applications?
Not many.
I've found a very similar bug in GLIBC! This code will cause a segment violation!
Shock! Gasp! Horror!
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?
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 the number one rule of secure web programming: All user data is evil. Anything that comes from an HTTP request can not be trusted. Heck, I don't trust it even after it has been stored in a database table or the file system. I would love to see a Perl-ish taint mode built into PHP that tells the programmer "This data has come from an insecure source. Please don't eval() it or unserialize() it or write it to disk. Cheerio."
Since properly coded PHP is still useful in many applications, what would be the best book to use as an up to date reference manual for the most secure method of coding with it?
Why not use a lovely PHP FrameWork then? Like, um, say, Drupal?
- - - -
You can't be ahead of the curve, if you're stuck in a loop.
You can't be ahead of the curve, if you're stuck in a loop.
Month of Shooting Fish in a Barrel
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?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
the freak operators like === are a response to the lack of type safety. Not having stict types can be really usefull, and if you code well, irrelevant to the security or performance of your application.
insight through the mind
I cannot see why I should learn RoR, or Perl, when I have what works.
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.
We can use Ruby on Rails.
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?
Way ahead of you.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
Accessing Oracle from PHP is child's play. What's the mystery? Besides, the comment was about the extensions and capabilities. PHP is great, though perl is better. I don't know of any other languages that are as flexible in that regard.
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 which give PHP quite a speed boost. From Wiki: Most work by caching the compiled bytecode form of PHP scripts to avoid the overhead on every page request of parsing and compiling source code that may never even get executed. For best performance, caching is to shared memory with direct execution from the shared memory and the minimum of memory copying at runtime. A PHP accelerator typically reduces server load and increases the speed of PHP code anywhere from 2-10 times[...]
And yeah, PHP's fast and loose flexibility creates the necessity for things like === however the requirement that one is more aware of how types are handled is easily outweighed by the flexibility it gives the developer and the ease of use.
Correct me if I'm wrong. By my math with APC and assuming a worse case situation of only 2 times acceleration. This means that PHP should execute in 60% the time of Java
I have just analysed the last month's script kiddie attacks on my web server. 71% of them were to php-related URLs. When I first went through this exercise some years ago, the overwhelming majority of attacks were URLs related to IIS. The significance of this change cannot be overestimated.
l
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 nested array
?foo[][][][][]=bar
- quite an unusual structure, you might agree.
The real stinger is that PHP will let this array be as deep as an attacker likes - and it's the same for a POST as for a query string, so there's no practical limit. An attacker can exhaust the space available for the stack, with several adverse consequences. This bug has a lot in common with the gravest bugs in PHP's history, in that it is a mistake in PHP's input processing: in this case, PHP trusts the sanity of user input. According to MOPB, Zend's attitude to this bug is "won't fix".
The arrogance of this attitude is breathtaking. PHP is now the most insecure package on my internet server, probably surpassing the old BIND 8 in the frequency and gravity of its exploitable bugs. I sincerely hope that Zend will get its act together and make security their number one priority. The predominance of PHP on the web is not theirs as of right - if they do not act, then either their product will be forked, or an alternative will take its place.
The nested array bug is described here:
http://www.php-security.org/MOPB/MOPB-03-2007.htm
I for one welcome our new month-of-bug overlords.
Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]
If you want to code well, you're best reading the Camel Book [sic].
Honestly? No.
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 deployment target for Rails.
For smaller, non-Rails projects, Ruby can be a good option if simplicity of deployment is paramount, but as far as I know it's rather uncommon.
Reality is the ultimate Rorschach.
That's not an answer. In fact, it's worse than a non answer. A language should let you create an application as insecure as you want it to be. It's not the job of a language to be secure, it's the job of a programmer to write applications that are secure, and the underlying platform/codebase to do what is says on the tin.
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. The only exceptions are low-level code and absolutely speed-critical code. A dynamic language like PHP is neither, and there is no exccuse for endangering programmers and users by doing things like directly importing C APIs for database access. No other dynamic language is so crazy as to do this.
it can be a trial and error game to escape/unescape strings etc
This is absolutely critical to get right in PHP, or you will most likely be toast. And it is not easy.
Right because not paying attention to security is what every programmer should do. Language doesn't make a secure program the programmer does.
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 market is inexperienced programmers, there is no excuse for the incredibly shoddy design and all the traps it contains that will make your code insecure if you do not know exactly what you are doing, such as the mysql functions which are just imported straight from C. No other language is so crazy as to do that.
java memory allocation is as fast as if not faster then malloc.
enjoy
PHP is the solution of choice for relaying mysql errors to web users.
Never heard of the September that never ended?.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
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.
enjoy
i cant see how that statement can be true. the JRE might be able to allocate at that speed, since it is machine level, but the application cannot, since it has to be interpreted and then the allocation can occur.
thats not my point though. the point is that String s = "abc"; is not as fast as strcpy( s, "abc" ); for obvious reasons.
this could fork off onto a thread all of it's own, but somethings can occur in java faster than in php, as php does not have beans. beans provide a means of loading something common just once, and then it's available for future instances. this could avoid a lot of db calls that php scripts might require.
Why UNIX?
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.
you lie.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. in comparison to copying 1
>>i cant see how that statement can be true. the JRE might be able to allocate at that speed, since it is machine level, but the application cannot, since it has to be interpreted and then the allocation can occur.
it's because of how java manages the heap. it asks for a chunk of memory from the OS on startup, when you want an object, it just marks the memory as used and returns the pointer.
read the article and see some of the clever things the JVMs do now with memory management, it's really cool.
>>thats not my point though. the point is that String s = "abc"; is not as fast as strcpy( s, "abc" ); for obvious reasons.
if it doesn't have to allocate the memory first, then it's faster. modern JVMs make String s = "abc" static anyway since strings are immutable (I believe java 5 & 6 both do this)
I'm not bashing PHP, you just need to be aware that java has changed alot since the shitty applets of 1.0.2.
PHP is the solution of choice for relaying mysql errors to web users.
Why UNIX?
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 shortcomings come from people like you, who never used PHP but are used to hearing about its security problems.
I use the language that's best for a given application. I use Perl to extract data from text files, Python for engineering programs, C for number crunching, PHP for getting user input in web interfaces, SQL to store the data. However, any time I try to explain here in
I really shouldn't reply to this troll bait but I don't even get what you are implying. That I don't know anything about PHP, COBAL, Python or Ruby. Which one????? Oh and yes you are right I don't now anything about COBAL and very little about Python and I think I'll keep it that way.
So the real problem here is inexperienced programmers not the language
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?
Actually yes there is trick it's called a QA department
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.
Thank you for proving my point. It's kids in the basement not the language. Or wait do you fall in to that category
No, it's about not picking the worst language - in this case, PHP.So basically yeah. You are in your parents basement. How can you determine the point I am trying to make? You can make your own point but you can't tell me mine.
Tell you what. Go get a job as programmer in a shop that already has a working product then come talk to me.
So your entire argument is to blame the users instead of the product?
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?
EXACTLY. If you stick a fork in toaster the you get shocked. If you can't program or do security audits, which BTW hardened-php will do if you pay them, then you risk getting hacked.
If you use Windows 95 to browse the Internet you risk your computer being compromised.
Like I said before get a job and you will understand the argument. The quality of the language has nothing to do with the size of the paycheck. If anything it's the opposite because there tends to be less demand for the newest language and newest technologies.
I guess you simply are a hopeless elitist, then. I see no reason to continue the argument.
If indeed you are building Oracle DB support from source, you'll have to use Oracle to install the libraries so you can link against them of course (the only extra step), but that requirement - and the fact that the installer is a complete PoS is of course entirely Oracle's fault. "apt-get install php5-mysql" (or indeed / "cd
I really shouldn't respond to newbie idiots, but here goes: One, you clearly know so much about COBOL that you can't even spell it. Second, it's = it is. Seems you don't know English either.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
PHP is a scripting language that can be run as either a CGI application or as an integrated Web server module. Regardless of its mode of execution, the PHP interpreter has the potential to access virtually every part of the host -- the file system, network interfaces and etc. Consequently, it has the potential to cause a lot of damage. The programmer needs to be aware of everything that can go wrong at any time during the program execution,in order to prevent attacks from adversaries. And yes this is a formidable task. Software getting so complicated very fast. But somehow, ussually knowledge about the weaknesses of a system and the common modes of attack can go a long way toward increasing its security. Same goes to any other piece of software.