Slashdot Mirror
PHP Vulnerabilities Announced
Simone Klassen writes "The Hardened-PHP Project has announced several serious and according to them, easy-to-exploit vulnerabilities within PHP. A flaw within the function unserialize() is rated as very critical for millions of PHP servers, because it is exposed to remote attackers through lots of very popular webapplications. The list includes forum software like phpBB2, WBB2, Invision Board and vBulletin. It is time to upgrade now."
And of course, Mac OS X and Mac OS X Server 10.3.7 contain php 4.3.2...
They must be all busy upgrading :)
I can't wait for someone to release a script that I can use to show what a leet haxor I am.
PHP: 10 million newbies can't be wrong.
I read about this yesterday and couldn't find out if mod_security and suPHP are vulnerable to these attacks. With mod_security blocking buffer overflows, "bad" characters, etc. and mod_suphp forcing PHP to run as the user, I don't think that it gives people who run these modules (that) much to worry about.
I think it's about time someone came up with an easier way to upgrade php.
It's so god damned time-consuming to rebuild the entire thing over and over again, especially because you keep having to rebuild all the additional modules (mysql support, gd support, mcrypt support, pdf, the list goes on).
I love how you guys take this all seriously when there is an error in OSS software but when there is 1 little error in ASP.net you call it inherently insecure and a piece of garbage.
Almost every forum / message board out there utilize these scripts... I think a lot of backup-reloading (for those who have them) will take place if a script kiddie toolbox exploiting these vulnerabilites hit the scene...
Forum defacing excepted, is there anything else someone could do using these vulnerabilities?
Eureka Science News - automatically updated
I have a few legacy servers just around for my use and i don't want to pay for the upgrade and downtime..
anyone know of any ensim pro updates or packages someone has continued to build for this setup?
(or possibly redhat 7.3 updates..??)
thanks!
Most of these vulnerabilites come down to checking user input. If you are properly checking user input against a set of known good values and rejecting any input that is not a match, your chances of being vulnerable decrease dramatically.
Yes, I'm a big fan of php, but like any language out there, there are vulnerabilites. PHP had a bigger problem with register_globals being defaulted to on. Not to make light of these vulnerabilities, but if you are checking user input (assuming you're not using a downloaded package) you should be pretty safe.
http://secunia.com/advisories/13481/
PHPBB will affect a lot of websites it appear forums.gentoo.org has gone offline, upgrading early perhaps??
Question:
"Note: Due to a problem with earlier versions of Zend Optimizer, its users are urged to upgrade to the latest version."
I can't seem to find any information on what this problem may be. No release notes or anything. Any clues?
Comment:
PHP.net's download scheme is worse than Sourceforge's if you can believe that. Therefore, here are some unPHP.net-ized URLs:
US2
Belgium
Finland2
You'll find you can actually right-click and save these and they won't prompt you for a filename "mirror" or something useless like the rest of PHP's download links.
http://bugs.php.net/bug.php?id=31104
Has anyone else run into this problem? If so, please vote on this so that it's fixed for 5.0.4 ;)
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
If PHP wants to get serious about security, it needs to stop writing its own libraries for things already available elsewhere, such as GD or MySQL or any number of other programs. It's always going to be difficult to keep the internal and external libraries in sync, better to just use external.
Basically, if the developers spent less time reinventing every wheel in existence (look at the documentation page some time, the index of the "libraries" is astounding) they might have more time to close holes like this.
Their implementation of memory checking seems to be sane and valid for all installs. So why are most of us running vanilla like this?
Just a thought.
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
Vendors usually hear about them with enough time to prepare an update for any relevant products. For example, if you're running RHEL and are a self-respecting sysadmin, you applied this fix last week.
You might be right though: a sec-advisory section might be a good idea.
# $FreeBSD: ports/lang/php4/Makefile,v 1.81 2004/12/16 11:37:23 ale Exp $
#
PORTNAME= php4
PORTVERSION= 4.3.10
And it seems to have compatibility issues. It ended up breaking custom code of mine, as well as Invision Power Board. This was compiled from scratch. Hopefully they'll quickly release a .11.
Write your own code.
PHP is great, but as with anything you install, you have to place a certain level of trust in it. And since web apps are always on to the public you really better trust them. Esp. if you are a n00b, and are installing these apps without knowledge of programming.
I don't like using a pre-packaged PHP app in a public or semi-public location. Then the code is there for all to study and prepare for an exploit.
I prefer to write all my own apps. I might use code examples and classes as a base, but input is filtered and checked. And nobody else knows the code.
Why can't it be Monday? I mean, do the people that make these announcements think we _like_ working weekends?
The poster of this parent comment is simply frustrated that Mac OS X is affected by this vuln (which I didn't know was affected until I read his comment).
If this was an asp.net exploit people would be saying XP, or Server2003 was insecure. Even though IIS isn't installed by default.
Have you ever been to a turkish prison?
While this is true for some, on the whole the major difference is the time between the bug was discovered and when it was patched. MS does tend to take their sweet time.
The unserialize() bug issue is rather serious, though.
It's true that all systems have vulnerabilities, but that does not mean that all systems are equally secure. What you want is a track record that shows good things. Frankly, I'm not all that impressed with PHP's track record so far. The good news is that the PHP developers have been willing to change critical pieces (like turning off globals) to deal with security issues, and it looks like at least some of them are taking security more seriously. But I'd really like to see evidence of serious steps to not just provide a niftier OO model, but provide a programming language where programs are more likely to actually withstand attack. PHP has a lot going for it, but an implementation that can't handle harsh attacks is simply not appropriate for today's network.
I'd like to see Hardened-PHP, or something like it, merged into the mainline PHP. Why is it that only some users will get a PHP that tries to defend against attacks? Does this mean that other PHP users never get attacked? Does this mean that PHP programmers have stopped making common mistakes? Nonsense. There's no reason that there has to be a separate project to modify PHP to be secure against attack; that should be part and parcel of PHP itself. The performance impact is tiny, and much less important than keeping control over your own machine. Why should anyone be impressed at the speed of a system that's about to be controlled by an attacker?
One of the best ways to get a secure setup is to find out what product has the better security track record with evidence of a secure design (modular parts, etc.), and switch to one of them. That's true whether it's OSS or proprietary; OSS is no guarantee of security, it simply makes some kinds of worldwide review possible. Using Internet Explorer or Outlook? Switch to Firefox and Thunderbird. Using Sendmail? Switch to Postfix. That doesn't guarantee perfection, but you're generally better off in the long run. I think you could make a very good case for switching from PHP to Perl or Python or Java. If the PHP folks want to keep their large user base, they need to get on the stick.
- David A. Wheeler (see my Secure Programming HOWTO)
If PGP stands for Pretty Good Privacy, does PHP stand for Pretty Hopeless Privacy?
Oolite: Elite-like game. For Mac, Linux and Windows
You hate the "fanboys" - I abhor the bigots whom fail to recognize and acknowledge the freedom of choice in the F/OSS "world". Try to embrace that freedom - it's good for the soul.
# in a perfect world this would increse my karma
$karma++;
No... that would be "in a Perlfect world..."
This tagline brought to you by 1500 monkeys in just under 17 years.
Or Mono.
Also important here (more important) is good application design.
A hacker cannot get your database information, attach to the database, run arbitrary queries, etc. if your application is properly designed.
You have a front end in a language or environment that provides application level security (Java or Mono -- Python programs running under IronPython or Jython, don't think perl has app level security in any environment, but might be mistaken).
Application level security ensures that if the front end is compromised, its access is limited to only those files, folders or facilities that it has been explicitly granted access to.
Then you connect to a separate server (you can use VM software to run these on a single hardware box, if you need to, or something like User Mode Linux) that has a program that talks to the database.
If you really want to cut off access, you use ssh and require the machine with the database to ssh and then redirect a port back to itself. This is more secure because that machine then accepts no inbound connections (so the web server doesn't need permission to connect out to anything).
You access the database only with stored procedures (yes, this rules out most object relation map software), since the API usually takes an array or collection of parameters, and the API applies escapes, etc. as required automatically.
Stored procedures also have the important trait that they can apply many more and much tighter access requirements than what you usually can apply on a table or view. You can filter records from a result set, etc.
Yeah, it's a lot more work, but a hacker who finds an exploit has a much harder time working deeper, and alot of security is making a system look secure enough that the hacker decides to go after easier prey.
If your code is acting bloated, and is running rather slow, it's likely and predicted that some loops you will unroll.
Just so you realize,
This is a lot of Microsoft's problem. For example, they used libJPEG's code in their JPEG display code. libJPEG had a vulnerability, but many programs used the common code.
And so the problem looked absolutely horrible.
On Open Source, it can be worse. If you look in lib, you'll often see several different versions of the same library (libwhatever-0.0.0, libwhatever-1.0.0), etc. and it is difficult to tell what programs might be linked to what version with what vulnerabilities.
I'm not disagreeing with the setiment, but you have to have good package management and be very careful with what you build by source, or else you can run into problems there too.
If your code is acting bloated, and is running rather slow, it's likely and predicted that some loops you will unroll.
You make a lot of good points, but if you think that and endless parade of security problems is going to make PHP any less popular, you're mistaken.
Like 90% or so of the modules included with the basic PHP distribution are just wrappers around standard libraries, no code is duplicated nor functionality reinvented. The wrapper is there to make the libraries easy to use.
The 2 libraries you mention happen to be bundled with the distribution for convenience, but you are free to use external versions supplied by your OS installation or perhaps yourself.
/greger
PHP needs taint.
evil is as evil does
And after people upgrade to PHP 4.3.10, neither will PHP be vulnerable to such attacks.
Problem solved. Nothing to see here folks.
Steve Magruder, Metro Foodist
Wow, all that flamebait packed into one post. Kudos!
:-)
I mean, you're completely wrong and utterly ignorant, but nice post!
(OK, you're right about PHP. It does suck.)
It's a strange world -- let's keep it that way
Just when I had *FINISHED* upgrading our system to 4.3.9. Seriously, couldn't they choose a more appropriate timing?
:-/
Oh well... here goes another one.
from "The Top 20 IT mistakes to avoid" published by Infoworld
o p2 0_5.html
.Net when developing scalable Web apps are making a mistake by not taking a second look at scripting languages -- particularly PHP. This scripting language has been around for a decade now, and millions of Yahoo pages are served by PHP each day.
http://www.infoworld.com/article/04/11/19/47FEt
18. Underestimating PHP
IT managers who look only as far as J2EE and
Discussion of PHP scalability reached a high-water mark in June, when the popular social-networking site Friendster finally beat nagging performance woes by migrating from J2EE to PHP. In a comment attached to a Weblog post about Friendster's switch to PHP, Rasmus Lerdorf, inventor of PHP, explained the architectural secret of PHP's capability of scaling: "Scalability is gained by using a shared-nothing architecture where you can scale horizontally infinitely."
The stateless "shared-nothing" architecture of PHP means that each request is handled independently of all others, and simple horizontal scaling means adding more boxes. Any bottlenecks are limited to scaling a back-end database. Languages such as PHP might not be the right solution for everyone, but pre-emptively pushing scripting languages aside when there are proven scalability successes is a mistake.
I've done quite a bit of Lisp (and in fact taught it for a semester), and for most practical projects I'd take _any_ of the above named languages over Lisp. Lisp solves a subset of problems pretty well, but as a general purpose programming language you're going to find most people are just trading memory leaks and buffer overflows for stack overflows.
Why?
Pretty swell. Friday after 7pm to Monday 7am means 2x overtime. More announcements of Friday afternoon please. Need that extra money.
... but it taint there!
Yea, it was supposed to be funny.
The obscure we see eventually. The completely obvious, it seems, takes longer. - Edward R. Murrow
The prof I had for my DB class largely hates MySQL with a passion and is an Oracle partisan, but he looked one of the students in the eye and told them to basically shut up when they complained about MySQL versus Oracle. He told the whiner that they should be glad that it worked at all and that they have no right to expect any quality for something they didn't pay for. For some it was a profound statement: MySQL kinda works for you, well guess what, you haven't spent any money on it so who are you to bitch at the guys who work on it... they owe you nothing.
Products from Zend can be expected to perform very well, but not something that is free for public use. The fact that PHP is so high quality, open and free, gives it some leeway that Microsoft's ASP.NET implementation doesn't deserve. People don't have to spend several thousand dollars to setup an environment capable of hosting PHP because it's free, and all of the tools needed to run it are free.
None of this of course negates the fact that security holes in PHP are just as serious in practice as those in ASP.NET and need to be fixed ASAP. The difference is how we should perceive free software bugs versus commercial software bugs. When we actually buy a license for a commercial product, we should be able to expect something reasonably akin to top notch quality. Microsoft is getting better in that regard, but the level of quality they have delivered in the past is abysmal compared to what a commercial entity should be delivering.
By all reasonable expectations, a company like Microsoft should be delivering extremely secure products. They pay very large sums of money to hire some of the brightest minds, and they charge accordingly. Therefore the public has a right to expect extremely comprehensive testing, including OpenBSD-style line-by-line code audits for things like buffer overflows. Does it not surprise anyone that a small project like OpenBSD can find the time and manpower to do that on such a large code base for the manpower present, but Microsoft, a company with probably at least ten times the manpower for just the Windows team cannot?
Click here or a puppy gets stomped!
I would disagree.
I've programmed in PHP for 5 years and have successfully used it to feed my family the entire time.
I haven't had any problem with security vulnerabilities since day 1 (I write all of my own software rather than using any particular package).
It has scaled easily to meet my needs, including an e-commerce site that does $3,000,000+ a year in orders. Granted that is small potatoes for some, but that is irrelevant.
What is relevant is that PHP is fast and easy to develop in, easy to debug, and easy to deploy. It does what I need it to do, and it does so successfully.
In my mind it is well designed for it's intended purpose.
There is no sense picking apart a screw driver and saying what a bad hammer it is. It isn't a hammer. It wasn't designed to be a hammer. It will never be a hammer.
For my purposes PHP is well designed and is the best tool for the job I've found. I've looked into many other tools, but hands down the winner for my needs is PHP. Trust me, if there were another tool that offered the same power AND ease AND was more profitable for me to use overall, I'd be using it. If it exists, I haven't found it. This isn't a religous pursuit for me. I don't care what the "best" programming language is. I'm here to feed my family and PHP serves that purpose well.
Lose Weight and Feel Great with Isagenix
The same could be said of other popular platforms. PHP isn't especially unsecure. All the attacks against it in this thread's comments are really just biased opinions of developers who prefer other platforms.
Steve Magruder, Metro Foodist
Advisory: Multiple vulnerabilities within PHP 4/5
Release Date: 2004/12/15
Last Modified: 2004/12/15
Author: Stefan Esser [sesser@php.net]
Application: PHP4
Severity: Several vulnerabilities within PHP allow
local and remote execution of arbitrary code
Risk: Critical
Vendor Status: Vendor has released bugfixed versions.
References: http://www.hardened-php.net/advisories/012004.txt
4.3.10 contains the fix.
I love how you guys take this all seriously when there is an error in OSS software but when there is 1 little error in ASP.net you call it inherently insecure and a piece of garbage.
FYI, the vulnerabilities were announced on "2004/12/15" (hardened-php). The fix was available since "15 Dec 2004".
Conclusion: Zend took AT MOST 23:59:59 to release a fix for said vulnerabilities.
Compare with Microsoft bugs, where it takes an AVERAGE of 6 months to get a vulnerability bug fixed.
In comparison, Microsoft's software "unpatched and exposed" vulnerability time is about 200 times more than Zend's.
Using FreeBSD 5.3-STABLE, I did:
/etc/cvsupfile
# cvsup
# portupgrade php5-cgi
# portupgrade -f php5-extensions
The latter -f causes all extensions to be rebuilt, which is what I wanted. Voila, upgraded in about 20 minutes on an Athlon XP 2000+.
bananas like monkeys.
PHP sux0rs
ASP r0x0rs.
OK, sounds good. Why did they bother then? All things equal, the more code they include, the more potential there is for vulnerability. What's the point if the code doesn't do anything?
The code does do something. It's a wrapper around the actual library, making it accessible within PHP. Or would you prefer that every single user of PHP had to write his/her own wrappers to do this? That'd be an awful lot of wheels reinvented.
These bugs and many many others have been known for a long time.
Not to sound trollish but the FBI and computer security groups label PHP with more holes than ASP. No joke.
Its nice to see the php team begin to take security seriously. Especially if they want lamp to ever replace Java or ASP on many corporate webservers and intranets.
http://saveie6.com/
Since when did you actually get a stack overflow in Lisp, when there wasn't actually a bug in your program? There's nothing about Lisp that causes stack overflows more often than any other programming language. Are you saying that Lisp doesn't permit the stack to grow as much as other languages? That's silly. Are you saying that because Lisp has recursion? Other languages have recursion too, you know.
The interactive programming envorinment and strong debugging tools make Lisp much easier to program, track down and fix bugs in your programs, than other languages.
Powerful interactive Lisp debuggers have been around for decades longer than languages like Java or tools like Eclipse. C++ debuggers like Visual C++ can't hold a candle to Lisp debuggers.
Ever try to symbolically debug C macros or C++ templates? The debugger falls flat on its face and gives you no help! It's because of the fundamental design flaws of C++, that the tools are so weak. Java tools are better because they left out macros and templates, but Java is a much weaker language because of it.
Lisp macros are much more powerful than C preprocessor macros or C++ templates, and it's much easier to cleanly and symbolically single step through and debug them without any of the pitfalls of CPP macros or C++ templates.
Java wasn't designed to be a good language, it was designed to be just a little better than an absolutely horrible language. The same goes with PHP and Perl.
-Don
Take a look and feel free: http://www.PieMenu.com
Perhaps you haven't built PHP before, but basically, you can build it so it'll either use the internal or external libraries. If the internal library is just a wrapper, how would the external libraries work at all, unless they too had a wrapper? Then, what would the difference be between the two wrappers? That's what I'm trying to get at here.
:)
Works for me!
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
I assume that when you actually do the make, it links the right libraries according to the --with-gd=/usr/lib/gd or whatever. I believe this is the -L directive for gcc. The underlying c code doesn't need to change for this to happen however.
bananas like monkeys.
php arrays are not wishy washy, they are powerful.
In PHP there is no difference between a hash and a numerical array, its the same thing.
try this:
$a[5]="five";
$a[0]="zero";
foreach($a as $k=>$v) echo "$k=$v
\n";
and you'll get:
5=five
0=zero
I like em, a php array is like an ORDERED perl hash, and you may be interested to know that PHP style arrays are regularly requested for perl.
Sam
blog.sam.liddicott.com
ASP.net is free. Not only is there a mono implementation but you can also install it on windows XP, windows 2000, and server 2003. Hell there's even a free and open source web server written by microsoft if you don't want to run IIS. And in 3 years, there's only been 3 security advisories. Can you say the same about php? I see over 1000 security advisories listed on secunia.org security list. Thats some high quality stuff.
Have you ever been to a turkish prison?
Watch out when upgrading!
This code prints 'empty' with 5.0.1, but 'not empty' with 5.0.3.
You must check all your code for the use of empty() with a string!
I wish PHP would warn everyone about this sort of thing.
Here is the man page...nothing said about it: http://www.php.net/empty
Actaully, PHP/MySQL and PHP/PostgreSQL will only process one statement, and while these attacks would be possible if you were passing it to the shell, is not possible from PHP. Each mysql_query() for example will process one query and return one record. Now with a subselect you might be able to do something...
when you see the word 'Linux', drink!
That's a completely empty comparison.
It lists applications that have bugs, not the parsing engines themselves.
It's just Crap.
I have gotten really burnt from PHP security-wise several times. I am a big believer in Zope, which appears to have much better security auditing.
If your debugger can't debug C++ templates, maybe you should get a better debugger.
C macros, on the other hand, are preprocessor macros. They are just text replacements. You shouldn't put code-intensive statements in macros.
There is reason that C and C++ have been popular for so long. They aren't very forgiving as some languages, but they are powerful. Programmers also need to be good programmers to program with them correctly.
. . . I agree. As a former phpnuke user, I can attest to this. After repeated defacements of my php-nuke site by script kiddies from Brazil, I removed Nuke and wrote my own solution. Not one problem since, and the custom solution was more flexible.
Please rate this bug important so that it gets fixed http://bugs.php.net/bug.php?id=31098
Don't you still need to do cftry/cfcatch stuff for the error handling?
the first announcement was on wednesday by stefan esser on bugtraq and full-disclosure. additional info came up later on, PHP 4.3.10 changelist and the according changes in CVS can be seen by everyone since then.
i do not think that any serious system administraton team gets to know this vulnerabilities via slashdot for the first time, the problem is, that compilation of all dependencies and deployment to all systems is a hard job to do from wednesday night to a reasonable end just before weekend.... in a week where lots of companies have their *drinks all inclusive* xmas events and the usual pre-vacation problems occur.
I don't have an account, so chances are no one will ever read this. However, if you are reading this, then I thank you.
This exploit has been known about in select hacker groups since late October. The first script for the kiddies was released last weekend (December 11 - 12) and it most certainly originated in Brazil. The group responsible for the initial wave of terror call themselves "H4ck3rsBr", and most of the defacements were done by none other than the infamous "S8ldier". No doubt he wrote a proof of concept for phpBB right away, seeing as how he's always first to the scene with new phpBB exploits involving PHP.
If you're running forum software that sits on top of PHP, upgrade PHP before it's too late. These guys took out a friend's Linux server because he caught them right in the middle of defacing his clients' websites (just index.html's). They had a rootkit installed and made sure to cause as much damage as possible before being booted off. After backing up the filesystem, re-booting the machine failed, as the partition table was toast and most of the important data sectors had been trashed as well.
I'm glad that the PHP team decided to fix this, but I'm also hopeful that the phpBB, vBulletin, etc. teams will start validating their input a little more carefully.
you just talk about one of the big advantages of PHP - because it _does_ use this amount of external libraries. (and a pain in the ass for thee ones that have to update their special-purpose compilation right now)
/ext/gd of your php sources to see the crossing of bundled vs. external lib.
the wrappers are just needed for the zend engine to know how to map php-function parameters to the exports of any external lib (plus some extra things like constants or not too big abstractions for convenience and error handling).
your examples GD and MySQL happen to address two exceptions for good reasons. the history of GD deveolpment, bug-fixing and reachability of the maintainer just proposed this kind of bundle (e.g. the current gdlib has some build problems on solaris again)
take a look in the config.m4 in
for the bundled MySQL, there are some other reasons, leading from a tight cooperation of MySQL AB, Zend and some core developers.
but "php does not link enough external libs" is absolutely wrong.
Just to let you guys know, I have had two of my phpBB forums hacked (within hours of eachother) from this exploit. This is a very serious issue.
. . . shouldn't they have numbered it 4.4 instead?
Slony for PostgreSQL.
- I don't need to go outside, my CRT tan'll do me just fine.
the 'less than' sign got filtered out. It was supposed to read 4.3.10 < 4.3.9
I have posted before that I think the PHP install process should be simplified. Many of the "features" that require configuration options should be moved to PECL. I would much rather run "pear install mysql pgsql sqlite" than make sure I include them when configuring PHP. It could be that using pcntl is something we decide to do after configuring the server. Why not just "pear install pcntl"? Instead we would have to re-compile PHP. That is something the PHP group should seriously consider. There was a lot of talk about moving extensions into PECL instead of including them in the PHP releases, but then when core developers create packages like SimpleXML, SQLite, etc all of the sudden we have to deal with more bloat in the install.
./configure --help, but they don't tell you to run it through a pager because there is going to be too much to view on a screen. Much of it is important, but the extensions just add complexity.
The official PHP documentation says that to install PHp on a UNIX system you should runn
Why is it that only some users will get a PHP that tries to defend against attacks?
One of the things that PHP has going for it is that it's easy to write. The downside is that it's easy for people who don't know programming or security designs to write code, and that they've written some big, popular applications which Hardened-PHP breaks, hence why it hasn't been merged in.
If you were a hot dog, and you were starving, would you eat yourself?
This is what REALLY fucks me off about PHP. Today I _have_ to upgrade - I have no choice as some of my hosted customers will be using vulnerable apps.
The problem is that during point releases, they change functionality so you're stuck between the devil and the deep blue sea - fail to upgrade and your server gets owned, but if you do upgrade you break customer applications and lose business.
PHP as a development platform might be great (although, you could argue that point too!) but as a platform to support for customers it's a steaming pile of shite!
Well if you ask prospective employees more about why manhole covers are round than about why it is bad to use a function such as gets() which can cause a buffer overflow what do you expect to happen?
Just because it CAN be done, doesn't mean it should!
PHP is a good web language, well, good enough in that it performs the job, I've been using PHP for a couple of years (before that, Coldfusion for a few years).
But to say it's well designed is not in any way valid, PHP for the most part is a monolithic hacking togethor of things, lots of inconsistency (function names etc), little modularity (after compilation), many unexpected results (for example try working with recursive references sometime, one mistaken return by value and you end up with two identical copies of the object completely silently, very frustrating).
Like many projects PHP started out small and gradually new things were hacked onto it. It's not well designed at all, heck, it's hardly designed period.
But, it does work well enough to do it's job and for now that's OK. But for me it's place in the world is only secured while it's the most popular web language - I think that if mod_mono can get some traction then it might be in for a run for it's money.
NZ Electronics Enthusiasts: Check out my Trade Me Listings
Err, that's a bug in your code ($a is not an object, -> is an object reference), if you write buggy code then don't expect PHP to give you anything close to expected results, let alone consistent ones.
NZ Electronics Enthusiasts: Check out my Trade Me Listings
For my purposes PHP is well designed and is the best tool for the job I've found. I've looked into many other tools, but hands down the winner for my needs is PHP. Trust me, if there were another tool that offered the same power AND ease AND was more profitable for me to use overall, I'd be using it. If it exists, I haven't found it. This isn't a religous pursuit for me. I don't care what the "best" programming language is. I'm here to feed my family and PHP serves that purpose well.
I could have written your entire post myself, and almost did. I have written projects of every size from very, very small to large projects (~70,000 lines to date) and PHP has been stable, easy, and plenty fast.
I update all servers monthly unless (like with this one) there's a serious security issue. Big problems are rare. I'll have all 15 servers I manage done tonight; it will take about 3-4 hours. (I have build scripts to automate the nasties and make it easy, so I copy in a tar file, edit a settings file, and run the script)
PHP just fits in lots of places. mod_php is great on apache. php/cli is a wonderful scripting tool for system administration. php-gtk (with glade) is a wonderful tool for rapid construction of client-side programs that works on Windows, Mac and Linux together.
PHP is something like VB and ASP rolled together, only cross-platform - a powerful combo!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
good call, good call
I'm a big retard who forgot to log out of Slashdot on Mike's computer! LOOK AT ME.
I find installing something like suse linux on a few thousand machines with entirely different hardware configurations costly.
Costly in time.
Change is certain; progress is not obligatory.
I heard something similar when people made the switch from PHP3 to PHP4
Change is certain; progress is not obligatory.
The fact that PHP is so high quality, open and free, gives it some leeway that Microsoft's ASP.NET implementation doesn't deserve technically, ASP.Net is free too. so perhaps holding asp.net to a higher standard than PHP is unjustified, IMO. the windows / linux debate is another story.
Automatically share the housework in a fair way http://www.chorebuster.net/
Point 1. Open source != Security Point 2. ASP > PHP
>Does it not surprise anyone that a small project like OpenBSD can find the time and manpower to do that on such a large code base for the manpower present, but Microsoft, a company with probably at least ten times the manpower for just the Windows team cannot?
Microsoft has incomparably greater resources but incomparably different incentives.
Mass-market decision makers aren't putting security first. Until they do, a market-driven company won't put security first either.
What happens when a Fortune 500 CIO says "I need symmetric multiprocessing, not a 'line by line audit', whatever that is"? Microsoft will deliver what the customer will pay for. The OpenBSD team would say, in more or less polite terms, "so what?". (Yes, I know they got SMP in recently).
Paying for something doesn't entitle you to demand security *unless you make it part of the deal*.
poor guys
ascii art
JM
Oink, Oink!!
Free as in beer - not free as in speech.
So would an error be too much to expect? I expect the language to help me out a little, and not just blindly run nonsense.
People often whine that Red Hat doesn't upgrade often enough and has too many patches in their RPM's. This is why. Taking a conservative approach, RH back-ports security changes to older releases rather than forcing users to upgrade to potentially incompatable new upstream versions.
Those who want to live on the bleeding edge are free to selectively build and install their own RPM's for the latest versions.
(Now if they'd just get some RPM's turned out to address this issue....)
Meanwhile, here's a bugzilla link to track.
In coldfusion we have a tag when building dynamic SQL statements called CFQUERYPARAM. Basically what it does is allow you to say that this parameter is this type and what not. You can also assign a max value to the tag. So you can tell the SQL engine that this variable is a VARCHAR of 255 maxlength. The beauty about this is that if the variable doesn't meet the criteria, it throws an error. This is another step in preventing SQL injections.
/* code to display error message and abort */ }
Well, it isn't exactly hard to do input validation in PHP, either. You just put a set of rules at the top of your script somewhat like this:
<php
function err ($msg) {
if (!is_numeric($HTTP_GET_VARS['foo'])) err ('foo must be a number');
if (strlen($HTTP_GET_VARS['bar']) > 255) err ('bar must be 255 characters or less');
?>
I tend to use regular expressions to validate input, as they're quite handy for doing so, and there's just about nothing that can't be appropriately validated with them.
The other thing that has ALWAYS bothered me about PHP is the error handling. I can't tell you how many sites I have gone to and seen just page of php error throughout the entire page.
PHP error handling is highly configurable. This is just a case of lazy application authors leaving the default error handling in action. The same capability as your <cferror> example can be achieved with the following (untested, so may need a little debugging, but I doubt it) php code:
<php
function mail_error($errno, $errstr, $errfile, $errline, $errcontext) {
mail ("address@wherever", "Error $errno in $errfile", "$errno: $errstr in $errfile at $errline $errcontext");
}
set_error_handler ("mail_error");
?>
Frankly, I'm not all that impressed with PHP's track record so far.
What *does* have a good record? PHP is the most commonly used web language for external websites. Thus, hackers target it first. I am sure J2EE is full of fun holes, but hackers tend not to bother because if they find a problem there are less sites that they can use newfound exploits on. In other words, PHP is the IE of web languages. Hack the most common to do the most damage.
Table-ized A.I.