"customer freedom over rigid rules" security wtf



  • "customer freedom over rigid rules" security wtf

    So last night I was doing some work for a client's website, and noticed in their public_html directory a file named php.ini.  Seems like a rather odd place for it!  So I downloaded the file to have a look.

    At the very top, a customized banner appears which looks like this (paraphrased):

    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;;  CrappyHostingCompany(TM) Suggests     
    ;;  ----
    ;;  If you wish to make changes to your php
    ;;  configuration, alter this php.ini and
    ;;  place it in all directories and subdirectories
    ;;  where you have php files.
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    (continued by lots of default php.ini settings)

    I thought to myself, "I can understand if CrappyHostingCompany wants to grant their users the ability to customize their PHP installation.  But it seems rather unconventional to instruct the client to place the file in multiple locations within public_html."

    Then I decided to satisfy my curiousity and went to http://www.clientcompany.com/php.ini -- and I was surprised and ashamed to be plainly viewing the contents of the php.ini file right there on the server.  Why aren't requests for this file denied as are all files matching "^.ht" ?
    So last night I was doing some work for a client's website, and noticed in their public_html directory a file named php.ini.  Seems like a rather odd place for it!

    I became excited and self-righteous and called their tech support (there's no email address on CrappyHostingCo's website, naturally) to announce this egregious security flaw.  Surprisingly, I spoke with someone who actually knew the functionality of the php.ini but admitted he didn't know much about Apache (which I didn't expect).  He encouraged me to submit a ticket using their cPanel software, so I did.

    I wrote a ticket explaining all the reasons it was bad to hand over the contents of a php.ini file to any client that requested it, including the fact that the php.ini has lines in it for Verisign Payflow Pro, Ingres DB and other items.  I certainly don't even trust my graphics-designer boss to NOT put either the client's FTP or MySQL authentication information in this file, and felt this could only give malicious attackers additional information on how to exploit code on a given system/site.

    I really thought I was doing the right thing.  I even provided them with the lines they could put in their httpd.conf to return a "403 Forbidden" response code for all requests for php.ini files.  I closed my email by asking them to "protect your clients from attacks, protect them from themselves".

    By now you've read enough stories on this site to know how it turned out.  I got an email back this morning:

    We are fully aware of the viewability of php.ini. As a company, we tend to prefer customer freedom over rigid rules, granting coding security responsibilities to the customers for obvious reasons. Most all of our customers never even touch php.ini files, or if they do, it's merely to enable ioncube or register_globals. A very small majority ever add anything sensitive to their php.ini files, and the act of doing so is generally frowned upon, especially considering the existence of the function ini_set().

    You are already fully aware of proper .htaccess settings to take to block access to php.ini, feel free to implement it.

    If you have any additional questions or concerns regarding this ticket, don't hesitate to reply.

    Shawn
    Support Level 2
    CrappyHostingCo.com
    866.555.5555


    So, to summarize:  Most people don't touch php.ini, so this isn't a problem.  You don't have a problem either since you know how to fix it.  The emperor has no clothes!

    Being a grizzled veteran (9yrs+) of web development and dealing with dozens of moronic hosting companies should have been enough to stifle any remaining idealism.  But naivete won over, and thus another small piece of me died this morning.

     [Additional rants:  register_globals and other items can be modified directly through .htaccess files.  And why in the bloody hell would someone need different php.ini settings in each of their directories to justify copying the entire file to each directory instead of using .htaccess or prepending a php file with the ini changes?]



  •  I would like to see this attitude in other industries as well. Take the gas company for example. What kind of nazi said those gas pipes should have such a rigid architecture?  Why don't they have an opening or two along the way, complete with valves. If I want to get gas directly from the line for my experimental flame-thrower who are they to deny me?



  • @DOA said:

    I would like to see this attitude in other industries as well.
    I wish Visa would publicly share their full FTP access credentials, then maybe I could afford a blow-up doll house.



  • Shared hosting companies are usually braindead.  Still, I wonder why the php.ini would have to be put in every directory instead of just the root.  Is it likely you're going to need separate settings for every single directory?  Ick. 



  • @morbiuswilters said:

    Shared hosting companies are usually braindead.  Still, I wonder why the php.ini would have to be put in every directory instead of just the root.  Is it likely you're going to need separate settings for every single directory?  Ick. 

    Heh. One job I had made me call customer support for their hosting company to ask if they had a J2EE container. I knew it would go bad, but I didn't expect for the poor sod on the phone to confuse JavaScript with Java. Ow.

     Heh, now enabling customers to enable register_globals is a hack waiting to happen...



  • I would generally prefer my hosting company to just give me a big box that I have full control over. If I shoot myself in the foot, so be it. I love their smartass response telling you to go implement your own .htaccess rules.

    And why in the bloody hell would someone need different php.ini settings in each of their directories to justify copying the entire file to each directory

    That sounds like a dumb approach, but.... do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.



  • do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.

    Actually, I think you and I are agreeing on this one. Personally I feel it would make the most sense to permit the client to control just ONE php.ini file perhaps placed in /home/clientname. And for any directory-specific customizations, they can add ini-related directives to a directory's .htaccess file. I agree, duplication would be a bad thing, and directory-specific controls should contain ONLY the ini directives that are different from the master/global configuration.



  • @Kozz said:

    do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.
     

    Tip of the day: Just highlight the text in his response and press the quote button.



  • @MasterPlanSoftware said:

    @Kozz said:

    do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.
     

    Tip of the day: Just highlight the text in his response and press the quote button.

     

    Coming up next, the new hit series MasterPlanSoftware: Forum Police. 



  • @bstorer said:

    Coming up next, the new hit series MasterPlanSoftware: Forum Police. 
     

    Yep, I can give a friendly piece of advice, and like clockwork I will have 5-10 people flame the hell out of me and this thread. Oh well.  At least I try.



  • @MasterPlanSoftware said:

    @bstorer said:
    Coming up next, the new hit series MasterPlanSoftware: Forum Police. 
     

    Yep, I can give a friendly piece of advice, and like clockwork I will have 5-10 people flame the hell out of me and this thread. Oh well.  At least I try.

     

    @bstorer said:

    Filed under: The Atlantic Ocean cannot stop curses, Relax. It's a joke.
     

    Relax.  It's a joke.  I really don't have anything against you.



  • @bstorer said:

    Relax.  It's a joke.  I really don't have anything against you.
     

    I know. That is why I agreed with you.



  • @MasterPlanSoftware said:

    @bstorer said:

    Relax.  It's a joke.  I really don't have anything against you.
     

    I know. That is why I agreed with you.

     

    And I now direct both of your attention to the irony of this argu-*ahem* discussion:  I started the thread being the guy who knew what was right and told someone in an attempt to help.  I was basically told "sod off".  It's the irony of our personalities and the professions we've chosen:  to be the guy who knows his stuff... and the usual amount of ego and hubris that goes with it.  In the end, our digressions lead us far from the original topic. ;)

    And I thank you, MasterPlanSoftware, for pointing out the tip.  I do actually appreciate it. :)  (long-time lurker, first-time poster, as it were) 



  • @Kozz said:

    And I thank you, MasterPlanSoftware, for pointing out the tip.  I do actually appreciate it. :)  (long-time lurker, first-time poster, as it were) 
     

    You are welcome. Welcome aboard.



  • @MasterPlanSoftware said:

    @bstorer said:

    Coming up next, the new hit series MasterPlanSoftware: Forum Police. 
     

    Yep, I can give a friendly piece of advice, and like clockwork I will have 5-10 people flame the hell out of me and this thread. Oh well.  At least I try.

     

    bstorer has 5 to 10 people using his account?  Shouldn't you be doing something about that, Forum Police?



  • @vt_mruhlin said:

    bstorer has 5 to 10 people using his account?  Shouldn't you be doing something about that, Forum Police?
     

    Right. You are late, and you still didn't get it.

    Good job.



  • @Kozz said:

    And I now direct both of your attention to the irony of this argu-*ahem* discussion:  I started the thread being the guy who knew what was right and told someone in an attempt to help.  I was basically told "sod off".
     

    Is that what this post was about?  I didn't actually read it, because it was long and I am lazy.  Instead, I posted a joking crack at MPS, which I now regret because some troll is probably going to come along, quote my post, and add his own slam against MPS, all the while missing that mine was a joke.



  • @bstorer said:

    Instead, I posted a joking crack at MPS, which I now regret because some troll is probably going to come along, quote my post, and add his own slam against MPS, all the while missing that mine was a joke.
     

    Too late, been there done that. Don't worry though, happens no matter what.



  • @MasterPlanSoftware said:

    @bstorer said:

    Instead, I posted a joking crack at MPS, which I now regret because some troll is probably going to come along, quote my post, and add his own slam against MPS, all the while missing that mine was a joke.
     

    Too late, been there done that. Don't worry though, happens no matter what.

     I'll start.  MSP is a D - Bag



  • @pig_vomit said:

     I'll start.  MSP is a D - Bag
     

    Excellent, you abbreviated my name, and STILL fucked it up... Three letters still too much for you?

    What a retard.



  • Did you guys think my response wasn't a joke, or am I misinterpreting?



  • @vt_mruhlin said:

    Did you guys think my response wasn't a joke, or am I misinterpreting?

     

    I have no idea if it is or isn't. I used to assume people were mostly joking on this forum, but then I got corrected a dozen or so times.

    Apparently, you are not joking unless you tag it as such, and state your intentions to make a joke in 36 point, bold font, in triplicate.

    I know, I was surprised too.



  • I generally like to apply the rule that anything I say which doesn't seem to make sense if taken seriously is a joke.  It's a good general rule of thumb, but the added bonus is that it prevents me from appearing to be wrong the few times that I actually am.



  • I believe if you are running php as a cgi module, then all state info (session) is stored by apache and php execution is entirely stateless.  php has no concept of a public_html directory or anything, it is simply an interpreter.  So putting the file in every directory where php is executed from is the only solution other than making the changes to the main php.ini file (which is not possible on shared systems).

    As for maintenance, 'find -type d -exec cp /path/to/php.ini {}\;' is not the most elegant way of handling the problem but not really a nightmare.



  • @javaweeny said:

    So putting the file in every directory where php is executed from is the only solution
     

     I would contend that most users will be making only a few changes when compared with the php.ini and that for them it would be better to state those changes in their .htaccess file with multiple lines of

    php_value PHP-variable value

    And that's that. But then again, we're dealing with (at hosting companies) are "salt of the earth... you know, morons".

    In any case, I believe the real WTF is that they would encourage this kind of usage and then NOT want to block php.ini from being served up like any other webpage.



  • @Kozz said:

    @javaweeny said:

    So putting the file in every directory where php is executed from is the only solution
     

    I would contend that most users will be making only a few changes when compared with the php.ini and that for them it would be better to state those changes in their .htaccess file with multiple lines of

    php_value PHP-variable value

    And that's that. But then again, we're dealing with (at hosting companies) are "salt of the earth... you know, morons".

    In any case, I believe the real WTF is that they would encourage this kind of usage and then NOT want to block php.ini from being served up like any other webpage.

    If PHP was running in CGI mode, then nothing else could be served out of those directories.  Also, the .htaccess tricks wouldn't work since there is no mod_php to interpret the values.  Also, nobody in their right mind runs PHP in CGI mode on Apache.

     

    The path for the php.ini is determined at compile-time so this is something specific to the hosting company.  It makes no sense and is completely stupid.  Actually, this is making even less sense to me now...  mod_php only reads the php.ini when Apache is started..



  • @MasterPlanSoftware said:

    @Kozz said:

    do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.
     

    Tip of the day: Just highlight the text in his response and press the quote button.

    @MasterPlanSoftware said:

    @Kozz said:

    do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.
     

    Tip of the day: Just highlight the text in his response and press the quote button.

    @MasterPlanSoftware said:

    @Kozz said:

    do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.
     

    Tip of the day: Just highlight the text in his response and press the quote button.

     Hmm, doesn't seem to make any difference whether you do highlight it or not first...

    Oh, wait a minute, did you mean just highlight some of the text in his post?@MasterPlanSoftware said:

    @Kozz said:

    do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.
     

    Tip of the day: Just highlight the text in his response and press the quote button.

    @MasterPlanSoftware said:

    @Kozz said:

    do you need to duplicate the entire file, or just the parts you want to change? The duplication would be a maintenance nightmare.
     

    Tip of the day: Just highlight the text in his response and press the quote button.


    Nahh, that didn't work either.  Ok, I give up.  What /are/ you suggesting to do?  And why?



  • @DaveK said:


    Nahh, that didn't work either.  Ok, I give up.  What /are/ you suggesting to do?  And why?

     

    Worked for me. 



  • @MasterPlanSoftware said:

    @bstorer said:

    Coming up next, the new hit series MasterPlanSoftware: Forum Police. 
     

    Yep, I can give a friendly piece of advice, and like clockwork I will have 5-10 people flame the hell out of me and this thread. Oh well.  At least I try.

     

    How fortunate we are, to have you here, trying on all our behalfs.  I cannot imagine what we'd do without you.  If only we would understand where our own best interests lie, surely we would appreciate you more and hurry to pledge our undying fealty!

    Alas, that in this cruel uncaring world, a prophet is always without honour in his own web forum

    Oh well.

    At least you try. 



  • @morbiuswilters said:

    Also, nobody in their right mind runs PHP in CGI mode on Apache.

     

    Quirk objection!



  • @DaveK said:

    I
     @DaveK said:
    only
    @DaveK said:
    lie
    @DaveK said:
    !

    Man, this highlight quoting is great.  Thanks, MPS. 



  • @DaveK said:

    Quirk objection!

    Yes?



  • @DOA said:

     I would like to see this attitude in other industries as well. Take the gas company for example. What kind of nazi said those gas pipes should have such a rigid architecture?  Why don't they have an opening or two along the way, complete with valves. If I want to get gas directly from the line for my experimental flame-thrower who are they to deny me?

     

    You know what...that would be pretty damn badass!  That anyone would even have an "experimental" flamethrower is pretty outstanding. 



  • @Soviut said:

    You know what...that would be pretty damn badass!  That anyone would even have an "experimental" flamethrower is pretty outstanding. 

    Haven't you heard? It's part of Linux kernel 2.7!



  • @morbiuswilters said:

    Also, nobody in their right mind runs PHP in CGI mode on Apache.


    EVERYBODY in their right mind running a shared hosting should run PHP in CGI mode, since this gives you the benefit of suexec, while such privilege separation is attainable with mod_php only by using an experimental apache2 MPM (like mpm-itk), there are no stable MPMs providing user separation. not a good idea to run all customers' code as the same system user, that would essentially mean all your customers can access each other's data, which might be a bit mitigated through obscurity, which of course is not a real solution.



  • @bstorer said:

    k
    [quote user="bstorer"]is[/quote]@bstorer said:
    s,
    [quote user="bstorer"]k[/quote]@bstorer said:
    is
    @bstorer said:
    s, MPS

    Ah, that explains it.  Looks like it works on FF1.0.x but doesn't on FF1.5.x

     



  • @morbiuswilters said:

    @DaveK said:

    Quirk objection!

    Yes?

     

    Assumes organ not in evidence, namely, a brain, without which said cheap hosting providers cannot be said to be either in their right minds or not.



  • @DaveK said:

    How fortunate we are, to have you here, trying on all our behalfs.  I cannot imagine what we'd do without you.  If only we would understand where our own best interests lie, surely we would appreciate you more and hurry to pledge our undying fealty!

    Alas, that in this cruel uncaring world, a prophet is always without honour in his own web forum

    Oh well.

    At least you try. 

     

    You really have nothing to do, huh?



  • @DaveK said:

    Ah, that explains it.  Looks like I just don't know what I am talking about.
     

    Looks like you needed a little help. You are welcome.



  • @lanzz said:

    EVERYBODY in their right mind running a shared hosting should run PHP in CGI mode, since this gives you the benefit of suexec, while such privilege separation is attainable with mod_php only by using an experimental apache2 MPM (like mpm-itk), there are no stable MPMs providing user separation. not a good idea to run all customers' code as the same system user, that would essentially mean all your customers can access each other's data, which might be a bit mitigated through obscurity, which of course is not a real solution.

    Guess you've never heard of safe mode, eh?  There are plenty of security problems inherent in running PHP in CGI mode as well, plus most applications don't even support it.  I've never seen a shared host that used CGI instead of the apache module, but I guess there could be one. 



  • @morbiuswilters said:

    Guess you've never heard of safe mode, eh? 

    Although I essentially agree with this, it's open_basedir you really want. Safe mode will be gone in PHP 6, and to prevent people from using system() or simlar functions to get other people's files via the shell, you can just disable those functions.



  • @Pidgeot said:

    Although I essentially agree with this, it's open_basedir you really want. Safe mode will be gone in PHP 6, and to prevent people from using system() or simlar functions to get other people's files via the shell, you can just disable those functions.

    Yes, but it all falls under the umbrella of "safe mode".  I wasn't referring to the specific option safe_mode.  Any good shared host would implement security measures to prevent users from accessing each other's data and they don't need CGI to do it.



  • @MasterPlanSoftware said:

    @DaveK said:

    Ah, that explains it.  Looks like I just don't know what I am talking about.
     

    Looks like you needed a little help. You are welcome.

     

    LOFL!  Postediting a quote is an automatic self-spank.  Consider yourself nominated for AUK.

     


Log in to reply