PHP Flaws
Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: PHP Flaws

  1. #1
    AO French Antique News Whore
    Join Date
    Aug 2001
    Posts
    2,126

    PHP Flaws

    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/
    -Simon \"SDK\"

  2. #2
    Priapistic Monk KorpDeath's Avatar
    Join Date
    Dec 2001
    Posts
    2,628
    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!!!!
    Mankind have a great aversion to intellectual labor; but even supposing knowledge to be easily attainable, more people would be content to be ignorant than would take even a little trouble to acquire it.
    - Samuel Johnson

  3. #3
    Senior Member
    Join Date
    Mar 2003
    Posts
    452
    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
    Like this post? Visit PuRe\'s Information Technology Community. We\'ve also got some kick ass Technology Forums. Shop for books and dvds on LiveWebShop.com

  4. #4
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

  5. #5
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

  6. #6
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    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.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  7. #7
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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.

    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.

    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

  8. #8
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    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).

    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.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  9. #9
    Senior Member
    Join Date
    Mar 2003
    Posts
    452
    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
    Like this post? Visit PuRe\'s Information Technology Community. We\'ve also got some kick ass Technology Forums. Shop for books and dvds on LiveWebShop.com

  10. #10
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •