PHP Flaws

Quote:

---

Two software updates have been released to fix critical flaws that could allow an attacker to compromise servers using PHP, a programming language for Web pages.

The PHP Group, a software developer community, issued versions 4.3.10 and 5.0.3 of PHP this week to remedy the problems in the major versions of the Web page-processing program.

"All users of PHP are strongly encouraged to upgrade to one of these releases as soon as possible," the group advised on its Web site.

Arguably the most critical vulnerability is in a function used to compact data for storage. By exploiting the flaw, an attacker could take control of the Web server that runs a vulnerable version of the PHP: Hypertext Preprocessing (PHP), according to the Hardened-PHP group, which found the flaw.

Originally known as Personal Home Page, PHP consists of a server-side scripting language that can be embedded in Web pages to generate dynamic content, and the processing program required to act on the commands. Many blogging programs and content management applications are written in PHP.

The language can be used to control the content of a Web site, by interacting with a database to create pages in response to a visitor's clicks. Typically, a Web page holds snippets of PHP code that are run whenever a visitor requests that page. The code triggers the content displayed on the page, often pulling it from a database that holds articles, graphics and personalized settings, for example.

As a programming language, PHP is flexible enough to accomplish a variety of tasks. A Web server has to run the PHP processor program to interpret any pages containing the language.

In addition to the critical flaw, the Hardened-PHP community found six other vulnerabilities in PHP, according to an advisory released by the group. It also develops its own, security-hardened version of PHP, and has released its own fully patched version of the system with additional security features.

The PHP Group's updates, which fix those vulnerabilities and several smaller bugs, have been posted to the group's Web site.

---

Source : http://news.zdnet.com/2100-1009_22-5496086.html
Advisories : http://www.hardened-php.net/advisories/012004.txt
PHP Site : http://www.php.net/

Are you freakin' kidding me?!!! Life with PHP sucks? I'm just starting out and I have to update a PHP CRM system? This sucks, bookstore here I come!!!!

Quote:

---

Originally posted here by KorpDeath
Are you freakin' kidding me?!!! Life with PHP sucks? I'm just starting out and I have to update a PHP CRM system? This sucks, bookstore here I come!!!!

---

PHP is the bomb, once you learn it. What CRM are you updating? I think out of 4 different programming languages I've messed around with, PHP is the easiest to learn.


--PuRe

My feeling is that most PHP apps will not be vulnerable to these flaws.

In order to trigger them, you need to unserialise() some of the user's data. This is not something that any sane PHP application does.

But then again, with the likes of "PHPNuke" around, that is definitely not a sane application. However, it's got a huge amount of security holes in already.

BUT the unserialise() bug allows you to compromise the host, not just the app. This is bad.

List of PHP apps to avoid running
- PHPNuke
- Postnuke (hardly better)
- PHPBB
- oscommerce
- MANY, MANY others

The quality of open source PHP apps is mostly extremely low. They're written by people who don't understand security at all. Also they often don't work very well and/or are extremely inefficient.

The recent PHP analysis showed several bugs in safe_mode. safe_mode is helpful for hosts who want to run the above apps without their server being compromised. But the again, it's not that safe.

Generally speaking, people with write-access to the web area will be able to gain shell access to the host - unless safe_mode is on, but even then, I wouldn't guarantee that they can't.

If they can use a local root exploit, they can then compromise the host.

Slarty

I've evaluated PHP 4.3.10 and my conclusion is that it's completely unusable in its current state.

Several bugs have been introduced causing core PHP language constructs to crash the PHP interpreter - specifically, using object-oriented programming is pretty much guaranteed to crash.

I've no idea what sort of test cases they have, but not enough.

Hold off 4.3.10 - that's my advice.

Slarty

Erm, I have 4.3.10 on a box here without any problems Slarty. You sure it isn't install-sensitive?

Oh, and serialize() and unserialize() *ARE* done quite frequently in "sane PHP apps". They serve a VERY specific purpose, but are generally one of the most efficient ways to ensure your PHP app is load balancable. Then again, I'm not talking about rinky dinky little blogging scripts, so for your uses it might not be an issue.

Quote:

---

Originally posted here by chsh
[B]Erm, I have 4.3.10 on a box here without any problems Slarty. You sure it isn't install-sensitive?

---

No I'm not sure it isn't install-sensitive, but many other people have reported it.

Apparently it's something to do with object-oriented programming - I haven't investigated it very much, needless to say, PHP 4.3.8 built with the exact same configuration runs my app fine, 4.3.10 crashes repeatably and definitely on every page.

Quote:

---

They (serialisation functions) serve a VERY specific purpose, but are generally one of the most efficient ways to ensure your PHP app is load balancable.

---

I am aware of their purpose. They're also used to store session variables etc. However, that doesn't mean that the user can exploit them, as they'd need access to the serialised data typically held in files or a database.

Quote:

---

Then again, I'm not talking about rinky dinky little blogging scripts, so for your uses it might not be an issue.

---

My applications are NOT "rinky-dinky" little blogging scripts, I'll have you know. They are serious business apps which need to work (which is why I'm not running 4.3.10 on production). And yes, I do use serialisation inside my apps.

I am relying for the time being, on the fact that exploits for these bugs remain largely theoretical. I'm not to the best of my knowledge running any app which calls unserialize() on user-supplied data. I hope they publish an actual working version of PHP before any real exploits come out.

Slarty

Quote:

---

Originally posted here by slarty
No I'm not sure it isn't install-sensitive, but many other people have reported it.

Apparently it's something to do with object-oriented programming - I haven't investigated it very much, needless to say, PHP 4.3.8 built with the exact same configuration runs my app fine, 4.3.10 crashes repeatably and definitely on every page.

---

I'm running Horde on a 4.3.10 box and it doesn't seem to have any problems. Granted, it's more of a development environment that it sits in, I use 5.0.3 for production (now anyway).

Quote:

---

My applications are NOT "rinky-dinky" little blogging scripts, I'll have you know. They are serious business apps which need to work (which is why I'm not running 4.3.10 on production). And yes, I do use serialisation inside my apps.

---

I've seen people employ serialization to cookies, and while not IMO an ideal idea isn't necessarily insane as long as you treat it as untrusted input and sanitize it properly. As long as you avoid such stuff you should be safe using a version prior. No situation springs to mind where PHP would automatically unserialize data for you.

There's plenty of things you can do to improve the security of an open-source php application. The beauty of having it open-source is so that you can examine the code for yourself, and update potential security flaws. Honestly, I can't see anything wrong with that. Maybe that's why PHP is just the fastest growing programming language.

I also think that poor application security doesn't fall on any one programming language, it comes from the application developers. There's poorly written applications for any programming language, not just PHP.


--PuRe

Quote:

---

Originally posted here by PuReExcTacy
[B]
I also think that poor application security doesn't fall on any one programming language, it comes from the application developers. There's poorly written applications for any programming language, not just PHP.

---

This is a bit more up for debate.

Most programming languages enable programmers to write secure and non-secure programs easily.

PHP seems to ENCOURAGE bad practice at all angles. Many of the examples found on the web (not necessarily on PHP's site itself) contain glaring security problems. Nobody seems to mind.

Ugly hacks like register_globals and magic_quotes, whilst no longer on by default, are still used by a large proportion of deployed applications - these cause security problems and data corruption.

There is of course no reason why you can't write secure code in PHP. It's just that lots of people don't. Even widely used apps - PHPBB springs to mind - contain heaps of holes or potential holes.

And the fixes recommended are usually symptom fixes for an individual hole, rather than a change of practice to make them less likely to get created in the first place.

Slarty

Quote:

---

I've evaluated PHP 4.3.10 and my conclusion is that it's completely unusable in its current state.

---

Out of curiousity, how did you do that? Also, could you list the 5 most common mistakes in PHP programming, and a way to circumvent that?

I'm not trying to make you prove your point here, I'd just like to learn from someone who seems to have the knowledge I lack.

Quote:

---

Originally posted here by Guus
Out of curiousity, how did you do that?

---

How did I evaluate 4.3.10 ?

I installed 4.3.10 on my development / testing server, and the fact that my main application I'm currently developing caused it to crash immediately, lead me to believe that it's unsuitable for production use :)

I used the same configuration of everything for 4.3.8 and the same web server - that works fine and I've rarely (if ever) seen it crash.

I tried the latest nightly snapshot too with the same results.

I believe these are known issues - if you go to bugs.php.net and search for "reproducable crash" bugs in 4.3.10 you'll see there are several.

Quote:

---

Also, could you list the 5 most common mistakes in PHP programming, and a way to circumvent that?

---

1. Failing to validate data correctly - this is the main one really. Not checking that positive values are positive. Not checking that values selected from a drop-down, really are ones which were in the drop-down in the first place. Attackers can modify the form so they can enter values which aren't present in a drop-down, so you can't rely on it (not to mention, if the drop-down is dynamically generated, the options may have changed by the time the person submits it)

2. SQL injections - this topic has been done to death elsewhere.

3. Thinking they can prevent SQL injections by just being really, really careful. You can't. You can only prevent SQL injections by using techniques which aren't vulnerable to them, for instance, prepared statements or a query builder like DB_DataObjects

4. Trusting stuff sent via the browser - specifically cookies. Nothing, whether it's a hidden field, or a cookie etc, should be trusted, regardless of whether it's been sent via HTTPS to an authenticated client etc. This is really an extension of 1.

5. Misunderstanding the security implications of various PHP options - specifically, register_globals (can cause serious security problems), magic_quotes (can cause data corruption), allow_fopen_url (Can cause some compromises). All of those three should be OFF in any new application intended to be secure.

Slarty

I'm not sure how 1-4 are PHP specific. Most of the things you are mentioning, are things that the developer, not the programming language has to be mindful of. You could code c or c++ and not validate input properly. It doesn't make a difference which language you use, you shouldn't trust user supplied input. I think you list deals more with common developer mistakes, then actual php specific. C'mon, sql injections are not specific to php and they only exist because developers don't validate input properly, not because the language itself is flawed.

In your list, the only thing that I really see as a specific fault of php was registered globals, which now comes turned off by default. I think that the 1-4 list, is mis-leading because they are supposed to be php specific issues, not developer issues, which those are. I think it would be a programming issue if there wasn't a means for the developer to fix the issue.

Lastly, with PHP growing so rapidly, and especially in the Enterprise, I can't see how PHP isn't production ready.

Great discussion guys.


--PuRe

With PHP growing more and more rapidly as each day passes, it's to be expected that bugs, crashes, and other Bad Things to be found. You don't create a good product without finding these things out. Apache did not get to be the #1 used web server overnight and definitely not because it had flawless code. As long as code is written by people, it will always be flawed and even if machines wrote it, it still has the human factor in it somewhere and that's been proven to be flawed, exploited, bypassed, corrupted and bribed and all of these way before the advent of computers. They spent years building the Great Wall of China and how did it get circumvented? Bribing the guards. You see where this is going.

Never trust user input, never trust validated user input, never trust what the program *thinks* a variable has, never use variables without a default declaration, always limit your variable input data to sane values, error check everything and then do it again to make sure, the list goes on and on and on. Living by these fundamentals, a programmer can take any language and create good applications. VB is notorious for being inefficient and unstable but I know several developers who make some seriously sick progs with it.

Vorlin, very well spoken.



--PuRe

Fair comments, Pure, that these are not PHP specific problems.

To be quite honest my main gripe with PHP these days is that the authors don't seem to have a clue what character encodings *are*. They think they do, occasionally, but they don't really. Therefore I cannot recommend PHP for applications which need to be localised into non-western languages, as it really doesn't have any easy way of supporting Unicode properly.

I would not expect PHP releases to be without bugs. All software has bugs. But I sort of expected 4.3.10 (which is "stable", after all) not to crash as soon as it took one look at my application :)

Slarty

I'm not sure how employing utf8_encode() is difficult, so perhaps you could elaborate on that?

Agreed, slarty, but how is that any different than any program's use of unknown or non-standardized methods (read: IE's proprietary html "standards" versus W3C's standards...as an example)?

I also agree that it's a lot harder to write localized programs that use non-western languages and character encodings. However, I wouldn't put the failing with php so much as I would the developers. In line of your program failing, is there a definitive reason as to it's crash? What error's given? I really am interested as I've never had php really "crash" on me.

http://www.php.net/ChangeLog-4.php#4.3.10
nothing in there related to anything in the zend engine so language constructs wouldnt be effected so im going to go with install specific

http://bugs.php.net/search.php?searc...ail=&bug_age=0

only shows up 10 bugs and there is only 1 crash in what could be considered core php and htats with overloading of objects under specific conditions

Quote:

---

Originally posted here by PuReExcTacy
PHP is the bomb, once you learn it. What CRM are you updating? I think out of 4 different programming languages I've messed around with, PHP is the easiest to learn.


--PuRe

---

A custom built job that doesn't always work the way it should, but to make up for that shortcoming the layout is bad and it runs slowly.

;)