Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
PHP Programming Security

Hardened PHP 187

Posted by michael from the start-with-phpnuke-please dept.
Frank Kreuzbach writes "Yesterday the Hardened-PHP Project has announced its existence on the PHP-general mailinglist. It is the first public patch for PHP which adds security hardening features. It is meant as a proactive approach to protect servers against known and unknown weaknesses within PHP scripts or the engine itself. It enforces restrictions on include statements, adds canary protection to allocated memory and other internal structures and protects against internal format string vulnerabilities. It has syslog support and logs every attack together with the originating ip."
This discussion has been archived. No new comments can be posted.

Hardened PHP More

Hardened PHP

Comments Filter:

  • Oops (Score:3, Funny)

    by Doomrat ( 615771 ) on Sunday May 16, 2004 @12:51PM (#9167958) Homepage
    I like how this story is positioned just above the one about WinZip's poor security.

  • Is your PHP hardened? (Score:2, Funny)

    by Anonymous Coward
    Or are you just glad to see me?

  • Phew! (Score:5, Funny)

    by Dark Lord Seth ( 584963 ) on Sunday May 16, 2004 @12:55PM (#9167979) Journal
    adds canary protection

    Is that protection against canaries? Protection with Japanese kunf-fu canaries? Or protection for canaries? I mean, the kung-fu canaries have potential...

    • Re:Phew! (Score:4, Insightful)

      by hattig ( 47930 ) on Sunday May 16, 2004 @01:00PM (#9168008) Journal
      I assume this like how they used canaries to test for gas in mines? If the canary died, then it was dangerous to be in that area.

      So from that, I assume that "canary protection" is actually running a kind of honeytrap for common PHP exploits, and if one is triggered ("dies") then it does some computery equivalent of ("lets get the fuck out of this mine").

      This is all speculation based upon the name though.

    • Re:Phew! (Score:5, Informative)

      by CTho9305 ( 264265 ) on Sunday May 16, 2004 @01:12PM (#9168067) Homepage
      It's a way to protect against buffer overflows. You put some known data on the stack, and before returning from each function call, make sure that data hasn't been changed. Most buffer overflow exploits work by overwriting part fo the stack, and canary protection will detect that the stack has been changed, so the exploit code will not run.
    • Canaries are a relatively small threat, it's the Kung-Fu Shrimp you have to watch for.
    • Is that protection against canaries? Protection with Japanese kunf-fu canaries? Or protection for canaries? I mean, the kung-fu canaries have potential...
      What do you mean, african or european canaries?

  • Already in use (Score:4, Interesting)

    by Noose For A Neck ( 610324 ) on Sunday May 16, 2004 @12:55PM (#9167984)
    I do some development and site administration work for a high traffic porn site, and I can tell you that we've been using Hardened PHP since before the project announcement (I'm friends with one of the developers). It works OK so far, but the server starts to get worn out after a while, after being particularly abused by a day's peak traffic.

    • Re:Already in use (Score:5, Interesting)

      by Ieshan ( 409693 ) <<ieshan> <at> <gmail.com>> on Sunday May 16, 2004 @01:12PM (#9168069) Homepage Journal
      Two Questions:

      1) I've heard some complaints about PHP on "high traffic" sites, is it easier on you guys because you're primarily serving static pages? I mean, I'm not a big porn freak, but it seems to me that most porn sites wouldn't be overly dynamic, since most of the content doesn't change once it's posted. Maybe some of the userauth stuff is PHP based, and maybe a site forum, but I don't really see what else would need to be supar-dynamic.

      2) Maybe this seems like a naive post - and maybe it's offtopic, mods, have your way - but with all the free porn that's constantly bombarding my mailbox and my computer screen with flashing messages, how do you all make money?

      I mean, what's "high traffic"? 20 paying users? Where *are* all these people that don't get the same spams for free porn that I do?

      Maybe the free porn isn't actually free, and that's why people pay.

      • Re:Already in use (Score:3, Interesting)

        by realdpk ( 116490 )
        1) PHP is not all that great for high traffic sites. It's lightyears better than mod_perl - in my experience - but it's still very much worse than static pages. One major problem is people tend to make a site overly dynamic, or don't cache frequently run queries/functions. Zend Optimizer can help, as can the other Zend products, but only to a point.

        2) Try thousands of users (it's not uncommon). Lots of free porn is out there, but the goal is to tease the surfer into pulling out a credit card. There are som

        • Re:Already in use (Score:5, Informative)

          by abulafia ( 7826 ) on Sunday May 16, 2004 @02:11PM (#9168351)
          Weird. I do high-volume sites for a living, and mod_perl rocks. I sometimes fall back to coding something in C when it is called millions of times a day, but in general, mod_perl makes getting close to the iron really easy.

          shrugs.

          Hell, people probably can write fast software in PHP... I can't stand the language, myself, so I've never bothered to learn optimization tricks. Mod_perl kicks ass... as Slashdot knows, not to mention Amazon...

          Can a PHP devotee who also knows web development from a mod_perl standpoint explain why you like PHP so much? I'm honestly curious. I've modified other people's apps, and find the language both cumbersome to use for non-trivial things and overly low level, at the same time.

          • Not likely to get many replies (Score:3, Informative)

            by Anonymous Coward
            Not many folks will qualify as knowing both. From my perspective, PHP was stable (MOD_PERL, several years back, was twitchy) and considerably simpler. Remember that to much of the programming world, Perl is weird.

          • Re:Already in use (Score:5, Informative)

            by nemesisj ( 305482 ) on Sunday May 16, 2004 @03:56PM (#9168886) Homepage
            I'm not extremely familiar with mod_perl, but I do lots of work in PHP.

            The reasons I like PHP better than perl for web development is the fact that you can escape in and out of execution (yes, this can be and is often abused) and I like how PHP wraps some of the more unreadable aspects of perl (like extracting arguments, etc) and has nice session support.

            Also, PHP seems to have a lot of standard web stuff rolled in by default. I know that you can configure perl to be whatever you want it to be, but back before I had access to my own servers whose environment I could control, this mattered a bit more.

            Anyway, just my two cents - it really comes down to personal preference between the two in my opinion - lots of the major disctinctions have gone away in the last couple of years.

          • Re:Already in use (Score:5, Insightful)

            by onlyjoking ( 536550 ) on Sunday May 16, 2004 @04:43PM (#9169099)
            Case in point. I started with Perl, learnt mod_perl then had to switch to PHP for most of my client work because most of them were using hosts which didn't provide mod_perl. This is the biggest drawback with Perl. Great language but brain-dead in the marketing department. Perl has lost ground in the web development sphere because it depends on mod_perl to compete with mod_php for performance. Perl templating engines (Mason, Apache Template, Embperl) allow you to do what PHP can do (and much more) but you're saddled with finding a host who will "risk" offering mod_perl. The authors of O'Reilly's "Practical mod_perl" even went so far as to advise explicitly against offering mod_perl in a shared hosting environment. Hence PHP replaces Perl in shared hosting environments.

            Mention this on comp.lang.perl.misc and you get flamed for referring to Perl as a web developmnent tool. Well, if the Perl community only sees Perl as a tool for large web projects then so be it but they're making a big mistake. There should be a decent Perl templating engine which can run as an Apache module without exposing the Apache API, so that it would just do the one job well. Until this happens PHP will simply wipe Perl off the map in shared hosting environments.

            Hopefully Perl 6//Parrot/Ponie will come up with something to break the inertia as bog-standard Perl CGI is irrelevant these days. Hell, many hosts don't even allow you free reign with installing CPAN modules.

            • Re:Already in use (Score:4, Interesting)

              by TheRaven64 ( 641858 ) on Sunday May 16, 2004 @05:32PM (#9169357) Journal
              The authors of O'Reilly's "Practical mod_perl" even went so far as to advise explicitly against offering mod_perl in a shared hosting environment. Hence PHP replaces Perl in shared hosting environments.

              I'd be interested to know how this is done. As far as I have been able to tell from installing PHP, playing with it, and skimming the documentation there is no easy way of preventing and PHP pages run by mod_php being run as the Apache user. For me, this is not a problem since no one else uses my server. It seems the only way to run PHP pages as the user who owns them is to use the CGI version of PHP which has the disadvantage of loading a 4MB binary every time a PHP page is called.

              • Most hosting environments I've seen with PHP running, it's a CGI, not the mod version.

                PHP is really easy to write poorly. The only reason this doesn't do horrible things more often is servers are powerful enough to handle the amount of traffic that hits them when they're funning poorly written PHP code.

                You can certainly find poorly written Perl, or whatever other language you like, but I think it's more common to find people who really care about granular details, security, coding style, etc. in other la
              • There are two options that I know of, there may be others.

                For 1.3 you can use mod_become [snert.com], but it looks a little scary to me.

                For 2.x you can use mod_suid2 [bluecoara.net]

          • Re:Already in use (Score:3, Insightful)

            by Lando ( 9348 )
            Speaking as someone who is familiar with both mod-perl and php and still does primary work in php, perhaps I can enlighten you.

            The fact of the matter is that before mod-perl, getting perl to run as a scripting language required spawning perl processes for each request made to the server. This causes significant problems. PHP as a compiled in resource could be handled by the apache children themselves and did not suck up extra resources.

            Now, that's not the case with perl any longer, but with any system

          • Re:Already in use (Score:5, Interesting)

            by Yaa 101 ( 664725 ) on Sunday May 16, 2004 @06:02PM (#9169494) Journal
            Perl was invented to scratch a itch on the commandline, PHP is purely invented for apache and this shows... The problem is not PHP being "slow", the problem is wrongly usage of the database, mostly mysql. Some well known PHP programs use more than 30 queries each go, you can understand that of course a high volume site is out of the question... Further there is also the question with both Perl and PHP, that is a smooth configured Apache that can fork and prefork a number instances from itself to serve connections. Mainly PHP is a C like interperter on steroids... The language is very problem solving by nature and very efficient in that it takes a handfull of statements to solve a complicated matter... I think Perl developers see the same with Perl, my impression is that the same solutions take less code in PHP compared to Perl, but the is my private impression... The largest power of PHP is intuitivity, most constructs you think off work in one or 2 go's while in other Languages often you are buried to death with error messges... And not to forget, instant gratification, you can do more than 1000 runs in a hour when developing...

      • Re:Already in use (Score:5, Interesting)

        by a1cypher ( 619776 ) on Sunday May 16, 2004 @01:55PM (#9168271) Homepage
        Actually, I am a PHP developer for some major porn sites. The sites that I work with, however, arent the end user sites that people pay to view, I work with the sites where porn webmasters go to buy their content.

        Surprisingly, it has to be fairly dynamic. Most of the work that my software has to do is in posting the content for the first time. You upload a zip, and the software will extract the zip taking the images makes thumbs and full sized samples with embedded watermarks. From this point on, the software is basically an advanced shopping cart with some extra features like the ability to order individual images out of a particular zip, and instant download.

        The sites that I have setup are surprisingly popular, and within the past year and a half, the sites I work with have sold closs to half a million dollars worth of porn. That may not seem much to a big business tycoon, but it is when theres only a handfull of people making the profit.

        I dont know how well the end user sales are however. I like this hardened php stuff and I think it has great potential. I am waiting for them to come out with a PHP5 version, and then I will jump right on it because all of my newer projects are going to be in php5.

      • Well, I can't speak for the first post, but from my experience at Internet Entertainment Group (ClubLove, went out of biz a few years ago), most of our pages WHERE dynamic. We had several hundred sites that all drew off the same database of picks (stored in a simply HUGE RAID named Cthulhu). Most of the sites where template driven, and heavily relied on generating galleries on the fly based on whatever theme of the particular site (cum shots, MILF, gay, cream pies, whatever...). We server it all off of 9 SG
        • Oh, and we used Perl. PHP was at v. 3 or early 4, not-ready-for-prime-time. I think PHP is now, or will soon give peral a run for it's money as the best server-side web scripting language (insert Perl / PHP flames here...).

        • Re:Dynamic Porn (Score:2, Insightful)

          by Anonymous Coward
          Am I the only that disagrees with your technique?

          I understand that the galleries of pics have to be filtered from a single database for each site, but there is a better way to do this.

          Instead of writing dynamic pages, write an application that produces static pages based on the database. Whenever your content changes, re-run the applications to get fresh static pages.

          Dynamic pages are just way too much overhead for what you're trying to accomplish.
          • This might be good. But really, it you have the computing power, does it matter? But also, for us, our catalog of images was constantly in flux, new galleries coming in, old galleries going out when our licensing expired (yup, major sites do license the material). But then again, I guess we could have set up a nightly cron job...

      • Re:Already in use (Score:5, Interesting)

        by toastyman ( 23954 ) <toasty@dragondata.com> on Sunday May 16, 2004 @02:02PM (#9168295) Homepage
        1) We've got no problem with PHP on a pretty high traffic porn site. Turck_mmcache helps quite a bit by caching the pseudo-compiled bytecode of each script, so it's pretty blazing.

        Basically every page is dynamically generated, even the images go through a PHP script to make sure the right people are seeing the right images.

        We honestly have a bigger problem with the SQL server keeping up than PHP consuming too much CPU. The site listed in my home page URL here runs on 3 servers, one for MySQL, one for most PHP scripts, and one to serve all the images. The two httpd servers handle about 1200 requests per second, and the loads are pretty low. 95% of those requests are PHP scripts.

        2) For the site I'm talking about there, we've got anywhere from 1000 to 5000 people browsing the site at once. Another site I admin [stileproject.com](very NSFW) gets much more traffic than that, and a lot of those visitors are downloading 5-200MB movies for free. There we have two thttpd servers handling most of the static files (videos and images). At times there we're in the more-than OC-12 levels of bandwidth, and they handle the load just fine.

        How do we make money? Some of our sites are subscription based, and we try to have content that you can't get anywhere else. We try to drive the community aspect of our sites, and try not to just be "another generic porn site".

        The first site lets anyone browse for free as much as they want, you just get access to more content if you pay. You also get to talk to the "performers" and a few other perks. The second site I mentioned is all free, it's supported by ads though.

        (trying not to make this spam, just a bit of insight into how porn on the internet actually works. And no, I'm not Stile.)
    • porn site....server starts to get worn out after a while, after being particularly abused by a day's peak traffic.

      Dontcha mean "peek" traffic :-)
    • So do you use Fluffer PHP as an addon to Hardened PHP in the porn industry?
    • I call well-done troll/joke on this one. "Hardened PHP", "server gets worn out after the day's abuse"... Maybe it's just me.

  • Call Me Crazy But.... (Score:4, Insightful)

    by CptSparrow ( 759491 ) on Sunday May 16, 2004 @12:57PM (#9167993)
    From the site:

    to protect your servers on the one hand against a number of well known problems in hastily written PHP scripts

    Wouldn't a better defense be to simply write good code?

  • is this just an excuse to write sloppy code (Score:4, Insightful)

    by burritoKing ( 768156 ) on Sunday May 16, 2004 @12:58PM (#9167996)
    it's certainly a step in the right direction, however as most vulnerabilitiesseem to come about as a result of poorly written code shouldn't the community be trying to educate newer (and some more experienced) PHP users.
    • I couldn't agree more with this poster. I think education of programmers in our Computer science educational instutiutions is lacking severly in teaching new programers about what dangers poorly written code can result in. I did a semester research project on the subject for my masters. (http://www.csee.umbc.edu/~cress1/cmsc791.html) [umbc.edu] All the educators I included in my project had very little if any clue about secure programming issues and after being presented with teaching alternatives were interested to i
      • Uhh, well, they recited a list of disasters caused by bad code at one point, I think.

        But the lecture didn't exactly give us a lot of help in actually doing defensive programming so as to actually *avoid* those errors...

      • Re:is this just an excuse to write sloppy code (Score:4, Interesting)

        by Crayon Kid ( 700279 ) on Sunday May 16, 2004 @03:57PM (#9168889)

        Besides the dangers of bad code in general, PHP is particularly dangerous, with it's very flexible and network enabled features. It only gets worse because it is (apparently) so easy to learn and use and it makes everybody feel like a God of website making in no time flat. [Insert boss saying "hey, secretaries could write PHP without a problem" here].

        The solution would be a very restrictive safe mode, which would freaking MAKE people watch what code they're writing and give up incredibly stupid and at the same time tricky stuff like using variables with globals enabled without any kind of previous cleaning or filtering. And the second half of the solution would be to throw out on their ass all the self-proclaimed PHP programmers who pull stupid stuff like this.

        The first part won't happen because hosting services can't afford to break all the sites using globals and so on. The second half may happen, I dunno.

        Meanwhile, hardened PHP won't mean much, I'm afraid. If a guy doesn't know enough to use an automated filtering class on his $_GET[] he won't know he needs Hardened PHP either, because he lacks severely where PHP security is concerned. You can lead a horse to water but you can't make it drink, right?

    • Re:is this just an excuse to write sloppy code (Score:5, Insightful)

      by mumblestheclown ( 569987 ) on Sunday May 16, 2004 @05:46PM (#9169407)
      i couldn't disagree more.

      as the japanese car makers discovered (or at least the idea came to prominence) in the 1950s, ANYBODY (even people with 93 PhDs) who assembles something makes mistakes occasionally. the trick is to limit the number of modalities that allow for mistakes. a person who is asked to make a wheel fairing in three minutes using simple hand tools will make far more mistakes than one who has a dedicted stamping machine.

      in fact, the japanese cars excelled in quality, worker satisfaction, and in the competitive marketplace for many years in large part that their idea that a) errors are natural stochastic processes b) the rate of errors in an any process is more determined by the design of the process than some inherent quality of the worker and therefore c) when a mistake is made, analyze the process, don't blame the worker as this will lead to d) continuous improvement and also empower workers to speak up.

      even the most experienced PhP programmer can make an error. education helps, but fixing the system is a better idea.

  • Laziness (Score:5, Insightful)

    by kevmo ( 243736 ) on Sunday May 16, 2004 @12:58PM (#9167999)
    From what I can see this project doesn't do much against protect lazy coders. The features listed are easily protected against by writing non-sloppy code.

    I'm not sure that this project is a good thing, as if someone gets used to it and switches to a server without it they might be in trouble.

    • Re:Laziness (Score:5, Insightful)

      by HeghmoH ( 13204 ) on Sunday May 16, 2004 @01:55PM (#9168270) Homepage Journal
      This is a common theme, the "Security problems only occur because of lazy/sloppy/stupid coders, and the solution is to become better coders" theme.

      The problem is that it's complete BS. Even the most wizardly coder will make mistakes. The only way to be secure is to have lots of code reviews, and then things still get through; look at holes in SSH or Apache. Tools like this certainly don't hurt, and they might just help. "Don't make mistakes" is not an option.

  • Bad Coding = Security Holes (Score:5, Insightful)

    by wellard1981 ( 699843 ) on Sunday May 16, 2004 @01:00PM (#9168010)
    I don't think the PHP engine is to blame, it's more of an issue with the PHP script developers to make sure they plug all the holes -- sure that's not always possible, however take PHPNuke as an example of poor PHP scripting, SQL injects are possible though a number of the modules. You have to add a high number of 3rd party patches to make the thing secure.

    This Hardened PHP is just hand holding the developer into a false sence of security.

    • Re:Bad Coding = Security Holes (Score:4, Interesting)

      by Rui Lopes ( 599077 ) on Sunday May 16, 2004 @01:24PM (#9168130) Homepage
      Why protected at an upper level, if you can protect at a lower level? It's more robust to enforce security at a lower level than to rely on good programming practices!

    • Re:Bad Coding = Security Holes (Score:5, Interesting)

      by chegosaurus ( 98703 ) on Sunday May 16, 2004 @01:29PM (#9168158) Homepage
      My PHP site is on a shared host. I do my level best to write secure code, but it's very possible the people who share my server don't. The server gets exploited through one of those, my site gets rmed or defaced, and suddenly I don't look so clever.

      It's so easy to write bad code in PHP that half the world is doing it. Anything that helps ISPs protect users from the shortcomings of their peers has to be good news.
      • My PHP site is on a shared host. I do my level best to write secure code, but it's very possible the people who share my server don't. The server gets exploited through one of those, my site gets rmed or defaced, and suddenly I don't look so clever.

        There are plenty of shared hosts that provide server processes running under separate UIDs, chrooted services, etc. which mean that as well as exploting a PHP script hole, the attacker would have to break the OS kernel protection as well in order to get at your

  • How about fixing safe mode instead? (Score:3, Interesting)

    by moeffju ( 114331 ) on Sunday May 16, 2004 @01:00PM (#9168012) Homepage
    Wouldn't it be a lot more useful if they found an ingenious way to have PHP scripts run properly in a suexec environment, so we can finally get rid of safe_mode and open_basedir everywhere?

    Not that this is not nice; every language should have internal hack/bug protections. But a proper security model would do more, no?

    • PHP *can* run in a suexec environment. But to do that, you have to make your php run as cgi-bin.

      This isn't exactly the greatest thing for performance. Not to mention having to put a !#/usr/bin/php on the top of each file.

      I'm sure some mod_rewrite work could pipe all php file extensions to one script that would do a require on the file, eliminating the need for that string on the top. What a pain in the ass, though.

      So your statement should read: wouldn't it be a lot more useful if they found an inge

  • PHP security all relies on the coder (Score:5, Interesting)

    by bigberk ( 547360 ) <bigberk@users.pc9.org> on Sunday May 16, 2004 @01:00PM (#9168013)
    It's all about how the coder writes his/her software, same with C, or Java, or anything else. I am directly aware of several breakins using PHP, and none of them used buffer overflows or anything so low level.

    The most interesting one I saw used a programming flaw (note: not PHP's fault) to execute arbitrary commands to get the web server to download, compile, and execute a telnetd-like program for remote logins. Once the attacker had gained access via user nobody, they ran one of several trivial Linux local root exploits to get root. Don't kid yourself, Linux ain't all that secure.
    • It's all about how the coder writes his/her software, same with C, or Java, or anything else.

      Java has SecurityManagers, so its not the same as with C or anything else. Its easy to protect against dumb coding.

    • Not quite (Score:5, Interesting)

      by vlad_petric ( 94134 ) on Sunday May 16, 2004 @01:30PM (#9168166) Homepage
      Make no mistakes - in 2001 a security paper claimed that ``it is very hard to write a secure PHP application (in the default configuration of PHP), even if you try''

      ``A Study In Scarlet - Exploiting Common Vulnerabilities in PHP'' [Clowes 2001]

      PHP is probably slightly better these days, but, just like Windoze, simply wasn't designed with security in mind. It's a language grown incrementally, designed to allow you to write websites very quickly. And yes, easy to use means that it attracts people who know very little about programming.

      Conclusion: combination of insecure language plus low-quality developpers equals security disaster.

      • Re:Not quite (Score:2, Insightful)

        by snillfisk ( 111062 )
        While all aspiring PHP-programmers should take the time to read the paper mentioned to understand why and how -- and to guard themselves against doing the same mistakes that we've all grown accustomed to over the years, it should be mentioned that almost all these default attack vectors has been taken care of during the years.

        the default installation of PHP today makes people write a lot more robust code than it used to do. New applications has been able to move away from the 'ugly' things and a general un

      • Re:Not quite (Score:4, Interesting)

        by passion ( 84900 ) on Sunday May 16, 2004 @10:29PM (#9170526)

        The super-global variables were first available in php4.0 beta 4 (released 2/2000), and were upgraded in 4.1 (12/2001), for further information, see PHP's ChangeLog [php.net].

        The biggest change this created was discouraging people from using register_globals - probably the biggest security hazard until that time with writing php. This has been turned off by default since then, but unfortunately I'm still seeing developers rely upon this awful feature.

        This doesn't make php bad, it makes those who write with that feature bad programmmers. Just because you can plow over a pedestrian with your car, it doesn't mean that everyone should have their car taken away... it just means that they're crappy drivers.

        • The register_globals problem isn't likely to go away any time soon. The problem is this:

          1. There are lots of PHP scripts that require register_globals on, as until relatively recently that was the default setting.
          2. Because ISPs need to offer compatibility, most ISPs have register_globals on, so that the scripts mentioned in (1) can be used.
          3. Because most ISPs have register_globals on, there is little point in programmers not using the facility it provides. The insecurity is inherent in it being swit

          • There are lots of PHP scripts that require register_globals on, as until relatively recently that was the default setting.

            Well, it was strongly mentioned as a security issue on 10-Dec-2001 when version 4.1.0 was announced:

            And it was turned off as a default with the 4.2.0 release on 22-Apr-2002 - two years ago.

            Version 4.2.0

            * ATTENTION!! register_globals defaults to 'off' now !!!

            Considering that php 4 was relea

  • This is a Good Thing(R) (Score:4, Insightful)

    by Anonymous Coward on Sunday May 16, 2004 @01:12PM (#9168066)
    Well believe it or not, in a lot of cases, PHP code just cannot be trusted. There may be vulnerabilities outside of PHP that can allow an attacker to place their own scripts on the server. When for instance, the ftp access password is cracked, someone can do just about anything if php hasn't been secured. With extra security measures, your site might be lost, but the server won't be compromised any further than that. For instance, on my server, functions like system and popen are disabled.

    Besides, if everyone writed only really nice code, why would there be RSBAC and PaX?
    Trust is a weakness.
    • "Well believe it or not, in a lot of cases, PHP code just cannot be trusted"

      It would be nice to specify what you think a script's priviledges should be.

      htpriviledges:
      <Files *.php>
      Database: Deny
      Filesytem: allow
      RemoteFiles: allow
      Input-Cookies: deny
      Input-Post: allow
      </Files>

  • Really Now.. (Score:5, Interesting)

    by FuzzyBad-Mofo ( 184327 ) <fuzzybadNO@SPAMgmail.com> on Sunday May 16, 2004 @01:13PM (#9168075)

    From one of "Hardened PHP's" examples:

    include $_REQUEST[$action];
    Which is certainly a good example of what not to do; but if somebody's dumb enough to do something like this, likely no amount of engine protection is going to help them.

    • Re:Really Now.. (Score:3, Insightful)

      by grazzy ( 56382 )
      Well, whoever came up with the idea that include and require could take an URL as argument should be slapped ...

    • likely no amount of engine protection is going to help them.

      Are you familiar with the concept of a sandbox? In Java, you could easily set up security permissions which prevent people doing malicious things like this. Even if the user did blah.jsp?page=/etc/passwd, if the JVM has no permissions to read that directory, all you will see is a security exception being thrown and the page not working as a result.

      I don't see why this couldn't be implemented in a scripting language just as easily as it was im

      • Re:Really Now.. (Score:3, Insightful)

        by Monkeyman334 ( 205694 )
        Believe it or not PHP-Nuke had that exact behaviour about a year ago. The problem wasn't including ordinary files. The problem is with PHP you can include http files. So just make a request action=http://myserver/phpscript.php that had system() calls and you basically had a non interactive shell that could upload and execute files as the httpd user. Which is much closer to an exploit than including a /etc/passwd (which doesn't work in PHP either btw, unless the httpd user has read permissions on that file).

  • Other PHP Hardening Sites (Score:5, Informative)

    by Dozix007 ( 690662 ) on Sunday May 16, 2004 @01:22PM (#9168122)
    I run http://www.uberhacker.com . This site is dedicated to secure PHP programming. It is better to program secure rather than limit coding abilities. Secure programming allows for a wider range of scripts and security.
    • "Webmasters get really mad when their sites are tampered with (not this one, I want you to give this site your best shot). If they really want to find out who broke into their site, they can. Keep in mind, if you are smart enough to break in, you better be even better to become anonymus."

      Plz fix, kthxbye.

  • nice intent but wrong approach (Score:5, Interesting)

    by mabu ( 178417 ) on Sunday May 16, 2004 @01:41PM (#9168213)
    There's a fine line between securing a base system and crippling functionality. I'm all for the Hardened project, but I think ultimately it's the programmer's responsibility to make sure their code is secure.

    A better approach might be to create some sort of code-parser that examines PHP code and warns the programmer of possible bad habits. Of course this should be prefaced with a long disclaimer that such a system isn't foolproof but is a good idea to run on any code to make sure you haven't overlooked any obvious problems.

  • A patch? (Score:5, Insightful)

    by mabu ( 178417 ) on Sunday May 16, 2004 @01:54PM (#9168267)
    After going over the site, Hardened PHP appears to be a patch to the existing PHP. Why don't the authors just petition the folks developing PHP to include these patches in an upcoming version?

    The problem I have with this project is that it's likely PHP-version dependent, and once you implement it, you have two different sources you have to synchronize code for (not unlike Apache+Mod_SSL). I'd rather not have twice as much work to incorporate these features if necessary.
    • 1) Some of these patches may introduce subtle bugs into interactions with 3rd party libraries (that covers pretty much most of the major function()s in PHP)

      2) Some of these patches may introduce performance hits which would not be acceptable for some uses.

      3) If you are running a large hosting company these patches may subtly break scripts being used by customers, tech supportality ensues.

      4) Since this is a fairly new project, not even to a 1.0 release the pace of change may be so fast that it's more t

  • I dont get this (Score:5, Interesting)

    by cyberlotnet ( 182742 ) on Sunday May 16, 2004 @02:31PM (#9168457) Homepage Journal
    Tons of complaints about how php programmers should program better, how php sucks, this and that..

    Yet just the other day people where bitching about Fedora not having SELinux on by default.

    PHP - Hardened PHP
    Fedora - "Hardened Fedora"

    Its really the same thing. Instead of fixing root flaws we through more security over them hoping it will stop then next hacker..

    Linus must really suck at kernel programming if we have to do things like this..

    No he doesn't Linus rocks, I cheer for every single developer that has ever submitted a patch to the kernel.

    Fact of the matter is this..

    WE ARE HUMAN.. TO BE HUMAN IS TO ERR.

    Yes the programmers, be it php exploits or the next kernel buffer overflow make mistakes.. Does that mean they are bad programmers.. HELL NO..

    Are there a lot of bad PHP programmers, yes.. I bet there are a lot of bad C programmers out there as well. We are just lucky they dont get to commit changes to the kernel or we would all be FUBAR.
    • Perseverare diabolicum

      It's human to err, but diabolic to persevere in your errors.

      When I talk with php "developpers" who learnt it by example and without any formal programming background, it's extremely difficult to get past the "but it works very well this way ..."

  • Umm.. (Score:2, Funny)

    by jvollmer ( 456588 ) *

    Wouldn't that make it HPHP?

    If it's not Consolidated Lint, it's just fuzz!

  • Perspective (Score:5, Insightful)

    by cnf ( 96794 ) <frank@nullsens e . net> on Sunday May 16, 2004 @04:16PM (#9168958) Homepage Journal
    I think it is funny how most /. readers demonstrate how they think from a user perspective, and not from an admin perspective.

    Now don't get me wrong, I understand, it's *hard* to think as an admin if you have never *been* one. But when you are an admin on a machine, you don't think "My users will just have to learn how to code secure, then there is no problem."
    Sorry folks, just ain't gonna happen!
    Joe home who wrote a site just to show off his holliday pictures thinks its swell how easy php is, and he doesn't really care about becoming fluent in php, as long as his little enviroment runs!

    Sure, you can try and educate your user, but if you maintain a 500+ user server, security is in YOUR hands. only ONE of your users need make an error, and the whole machine might go down. And the "poor coding is the only reason for security holes" just doesnt cut it there.

    Harden your servers, admins. Make the internet a fun place to be.

  • "Safe programming" ain't that easy (Score:5, Interesting)

    by garyebickford ( 222422 ) <gar37bicNO@SPAMgmail.com> on Monday May 17, 2004 @01:42AM (#9171226)
    I've been working on an article about fault tolerance, which is related to security in important ways. It all comes down to complexity. Computer science is, its essence, the management of complexity. A programming system of the size of PHP must incorporate as much support for fault tolerance at its own internal level of complexity as possible, because the system is too complex itself for any programmer to understand the security implications of all possible interactions between different components of the PHP runtime system, and all the libraries. In short, as several admins pointed out from their own point of view, you can't depend on your own code, much less that of 500 others on the same server.

    Looking at the Documentation Page [hardened-php.net] for Hardened PHP, the project is adding some very good changes to the underlying runtime environment and constraints on programmers. Based on my first glance I would be pleased, and not at all surprised, if some of these are incorporated into the main PHP in some form down the road, once it's been ironed out for a while. I'm glad to see folks actively using it.

    As for the various mod-perl advocates who don't grok PHP, I personally dislike working in Perl, which seems to me to be a collection of all the things that were thrown out of other languages because they promote bad programming practice. That's OK, I understand it has power and flexibility, but Perl code too often looks like sneezing to me. Different strokes, see.

    The security issues raised by this project are certainly matched by many of the same or equivalent ones in Perl. IMHO, both PHP and Perl have become too big. It is a truism that the probability of failure increases geometrically with the size of a system.

Slashdot Top Deals

Someday somebody has got to decide whether the typewriter is the machine, or the person who operates it.

Close