Results 1 to 31 of 31
  1. #1
    Join Date
    Sep 2004
    Posts
    242

    how to prevent perl from working ?

    Hello

    I have a cPanel/Linux server , runing apache as a webserver .

    i want to know how can i prevent perl/cgi files from working on all virtual hosts on both apache2/apache1.3 !


    Thank you !
      0 Not allowed!

  2. #2
    Join Date
    Nov 2001
    Location
    Ann Arbor, MI
    Posts
    2,978
    You can remove the perl cgi files, disable mod_cgi, remove the handler for it, remove perl. Is this a multi-user system?
    -Mark Adams
    www.bitserve.com - Secure Michigan web hosting for your business.
    Only host still offering a full money back uptime guarantee and prorated refunds.
    Offering advanced server management and security incident response!
      0 Not allowed!

  3. #3
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    Alternatively, you can change the permissions of perl so that ONLY root can execute it:
    Code:
    chown root:root /usr/bin/perl
    chown root:root /usr/local/bin/perl
    chmod a-rxw /usr/bin/perl
    chmod u+rxw /usr/bin/perl
    This will stop the user 'nobody' (which apache usually runs under) from executing it, but will NOT stop root access to perl (needed for things like cpanel updates, etc).

    Removing the mod_cgi is good, but it doesn't FULLY stop users from accessing perl.
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details
      0 Not allowed!

  4. #4
    Join Date
    Nov 2001
    Location
    Ann Arbor, MI
    Posts
    2,978
    Quote Originally Posted by linux-tech View Post
    Removing the mod_cgi is good, but it doesn't FULLY stop users from accessing perl.
    None of these methods stop a user from FULLY accessing perl. That's why I asked if it was a multi-user system. Removing mod_cgi comes closer than changing permissions on the shared binary for multi-user systems though, in my opinion.
    -Mark Adams
    www.bitserve.com - Secure Michigan web hosting for your business.
    Only host still offering a full money back uptime guarantee and prorated refunds.
    Offering advanced server management and security incident response!
      0 Not allowed!

  5. #5
    Join Date
    Sep 2004
    Posts
    242
    Hello

    Thank you all for stopped by my post !

    Yes this is a multiuser-system "shared hosting" .

    what if i removed the mod_cgi , will this stop cpanel from acting :

    http://www.site.com/cpanel ?

    Thank you !
      0 Not allowed!

  6. #6
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    Quote Originally Posted by bitserve View Post
    None of these methods stop a user from FULLY accessing perl. That's why I asked if it was a multi-user system. Removing mod_cgi comes closer than changing permissions on the shared binary for multi-user systems though, in my opinion.
    Wrong
    Your way:
    Perl can still be accessed by the user. All they have to do is put a script in their home directory (note: not web), call perl directly, and poof, you've got perl

    My way:
    Perl can not be accessed by ANYONE but root.
    .cgi and the like STILL call perl itself (Ever notice the perl call in one of them?) and it's required to work. They all have this line (at least every one I've ever seen) at the top
    Code:
    #!/usr/local/bin/perl
    #!/usr/bin/perl
    This means they're CALLING this binary, which they have to do. If this binary can't be read (or executed), the perl script will error out.

    My way doesn't JUST carry out to 'web' scripts, it limits perl usage entirely. Your way, easily worked around by uploading a perl script and executing it through the shell (cron, php shell, etc). If you doubt me , test my way out, you will find that it works.

    what if i removed the mod_cgi , will this stop cpanel from acting :

    http://www.site.com/cpanel ?
    No, as that is an alias, not perl itself.
    CPanel runs on it's own webserver, independent of apache, and uses it's own settings, so it doesn't care what apache says to do, usually.
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details
      0 Not allowed!

  7. #7
    Join Date
    Sep 2004
    Posts
    242
    Quote Originally Posted by linux-tech View Post
    Wrong
    Your way:
    Perl can still be accessed by the user. All they have to do is put a script in their home directory (note: not web), call perl directly, and poof, you've got perl

    My way:
    Perl can not be accessed by ANYONE but root.
    .cgi and the like STILL call perl itself (Ever notice the perl call in one of them?) and it's required to work. They all have this line (at least every one I've ever seen) at the top
    Code:
    #!/usr/local/bin/perl
    #!/usr/bin/perl
    This means they're CALLING this binary, which they have to do. If this binary can't be read (or executed), the perl script will error out.

    My way doesn't JUST carry out to 'web' scripts, it limits perl usage entirely. Your way, easily worked around by uploading a perl script and executing it through the shell (cron, php shell, etc). If you doubt me , test my way out, you will find that it works.


    No, as that is an alias, not perl itself.
    CPanel runs on it's own webserver, independent of apache, and uses it's own settings, so it doesn't care what apache says to do, usually.

    Thank you man
      0 Not allowed!

  8. #8
    Join Date
    Nov 2001
    Location
    Ann Arbor, MI
    Posts
    2,978
    Quote Originally Posted by linux-tech View Post
    Wrong
    Your way:
    Perl can still be accessed by the user. All they have to do is put a script in their home directory (note: not web), call perl directly, and poof, you've got perl
    The OP said perl CGI. Removing mod_cgi would certainly stop perl from being used as CGI in apache. Calling perl "directly" isn't CGI.

    My way:
    Perl can not be accessed by ANYONE but root.
    .cgi and the like STILL call perl itself (Ever notice the perl call in one of them?) and it's required to work. They all have this line (at least every one I've ever seen) at the top
    Code:
    #!/usr/local/bin/perl
    #!/usr/bin/perl
    This means they're CALLING this binary, which they have to do. If this binary can't be read (or executed), the perl script will error out.

    My way doesn't JUST carry out to 'web' scripts, it limits perl usage entirely. Your way, easily worked around by uploading a perl script and executing it through the shell (cron, php shell, etc). If you doubt me , test my way out, you will find that it works.

    No, as that is an alias, not perl itself.
    CPanel runs on it's own webserver, independent of apache, and uses it's own settings, so it doesn't care what apache says to do, usually.
    Changing permission on the shared perl interpreter doesn't stop the user from installing their own interpreter, and in fact doesn't affect CGI usage of perl in anyway. You say that my method only affects CGI usage of perl, and simply put, that's what the OP was asking.

    You may want to try sharing your own opinion without attacking others.
    -Mark Adams
    www.bitserve.com - Secure Michigan web hosting for your business.
    Only host still offering a full money back uptime guarantee and prorated refunds.
    Offering advanced server management and security incident response!
      0 Not allowed!

  9. #9
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    The OP said perl CGI
    No, the thread title says it all:
    how to prevent perl from working ?
    Specifically:
    i want to know how can i prevent perl/cgi
    That doesn't say perl cgi, that says PERL/CGI . Traditionally, that says perl OR cgi or perl AND cgi, but NOT EXCLUSIVELY CGI.

    Changing permission on the shared perl interpreter doesn't stop the user from installing their own interpreter,
    Correct, but not many people are going to pull THAT off. If they wanted to go that far, you're screwed no matter what you do.

    .... and in fact doesn't affect CGI usage of perl in anyway
    Again, wrong answer.
    IF the perl binary can not be executed, then the website will error out. DON'T say it's not so, because you obviously haven't tested this fact. I have. I don't post things here for the hell of it, or things that are untested. IF the perl binary can not be executed, the perl script will error. pure and simple.


    Next time, you might want to read through the post and grasp what the user is going for here. When the user is saying 'perl/cgi', don't exclude one or the other just because you THINK they only mean one, or the other.

    You may want to try sharing your own opinion without attacking others.
    You spread misinformation, and can't handle the fact that it's rebutted, not my problem. Next time, read the thread before you reply.

    Nobody 'attacked' you. I merely stated that your way of doing things was 'wrong', as it does not fully disable anything. If you don't like being told your way is 'wrong', then I'd suggest not posting 'wrong' ways to do things, or going around with statements like 'My way is better', or 'my way comes closer', or 'your way sucks'.

    Your way isolates a minimal part of the problm (cgi handler). My way isolates the CORE of the problem (perl itself). BOTH of these can be worked around, but then again ANYTHING can be worked around!
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details
      0 Not allowed!

  10. #10
    Join Date
    Nov 2001
    Location
    Ann Arbor, MI
    Posts
    2,978
    Quote Originally Posted by linux-tech View Post
    No, the thread title says it all:

    Specifically:

    That doesn't say perl cgi, that says PERL/CGI . Traditionally, that says perl OR cgi or perl AND cgi, but NOT EXCLUSIVELY CGI.
    Not being the OP, you don't have the privilege to tell me that I interpreted the OPs question wrong. The OP clearly wasn't making a distinction between perl and CGI.

    Correct, but not many people are going to pull THAT off. If they wanted to go that far, you're screwed no matter what you do.
    Glad that you admit that I was correct, and that your method doesn't "fully disable perl". You oddly make it sound difficult to install a perl interpreter.

    IF the perl binary can not be executed, then the website will error out. DON'T say it's not so, because you obviously haven't tested this fact. I have. I don't post things here for the hell of it, or things that are untested. IF the perl binary can not be executed, the perl script will error. pure and simple.
    See the previous section where we show that the perl CGI app may not be using your common perl interpreter.

    Next time, you might want to read through the post and grasp what the user is going for here. When the user is saying 'perl/cgi', don't exclude one or the other just because you THINK they only mean one, or the other.

    You spread misinformation, and can't handle the fact that it's rebutted, not my problem. Next time, read the thread before you reply.

    Nobody 'attacked' you. I merely stated that your way of doing things was 'wrong', as it does not fully disable anything. If you don't like being told your way is 'wrong', then I'd suggest not posting 'wrong' ways to do things, or going around with statements like 'My way is better', or 'my way comes closer', or 'your way sucks'.

    Your way isolates a minimal part of the problm (cgi handler). My way isolates the CORE of the problem (perl itself). BOTH of these can be worked around, but then again ANYTHING can be worked around!
    None of the facts that I posted were wrong. You're trying to say that even my opinion is wrong. If you interepreted the question differently, perhaps some clarification was in order on your part. The method that you posted fundamentally has no impact on perl being used as CGI with apache's HTTP server, and even when not using it as CGI.

    If the OP's question had been, "How do I stop users from using a specific instance of the perl interpreter", removing that instance would still have made more sense than changing permissions on it, even in a mult-user environment.

    I'm sorry that you can't see how obtuse you are being.
    -Mark Adams
    www.bitserve.com - Secure Michigan web hosting for your business.
    Only host still offering a full money back uptime guarantee and prorated refunds.
    Offering advanced server management and security incident response!
      0 Not allowed!

  11. #11
    Join Date
    Oct 2002
    Location
    Manchester, UK
    Posts
    1,164
    I'm sorry that you can't see how obtuse you are being
    I love this forum

    The OP is looking for a way to stop Perl from being executed via Apache. Removing the handlers, modules and configuration from Apache will achieve just that.

    I wouldn't recommend modifying the interpreters permissions directly when simply disabling apaches ability to understand what to do with the request is sufficient
    Rob Greenwood
    RedHat Certified, Unix Consultant
    http://www.linkedin.com/in/bilco105
      0 Not allowed!

  12. #12
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    I wouldn't recommend modifying the interpreters permissions directly when simply disabling apaches ability to understand what to do with the request is sufficient
    Wrong
    It is NOT sufficient to 'disable mod_cgi'. Again, that is an EASY work around, simply upload the file to the server and poof, you've got what you want, using server perl calls, PERIOD.

    Are both abusable? You bet. Disabling mod_cgi , however is the weakest link here, and the easiest one to get around. Creating perl binaries means that the attacker has to go through the extra effort to FIND the perl binaries that will work for this system,whereas with the other alternative, one can simply find a phpshell, upload the file and boom, you've got what you need by calling perl.
    The OP is looking for a way to stop Perl from being executed via Apache. Removing the handlers, modules and configuration from Apache will achieve just that.
    Wrong
    The OP doesn't ask "how can I stop CGI", do they? No, they don't. They ask "HOW DO I PREVENT PERL FROM WORKING?". End of story.

    The first step in solving problems? DON'T read into the problem. If the user asks how to stop perl, don't tell them how to stop CGI. If the user asks how to stop both, don't solve the problem HALFWAY, solve it FULLY

    In order to prevent perl and cgi from working, the perl executables need to be modified as instructed before. Removing mod_cgi will work ONLY for stopping cgi, and will NOT stop true web attacks. Either is worked around, but removing the binary from use (ie: chmod) is much, much harder to work around than just removing mod_cgi.
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details
      0 Not allowed!

  13. #13
    Join Date
    Oct 2002
    Location
    Manchester, UK
    Posts
    1,164
    It is NOT sufficient to 'disable mod_cgi'. Again, that is an EASY work around, simply upload the file to the server and poof, you've got what you want, using server perl calls, PERIOD.
    Just because your opinion differs from another, doesn't make that opinion wrong. The sooner you accept that, the better.

    It is more than sufficient, Apache needs to know what to do with a request when it receives it, hence the need for the module, scriptaliasing and such forth

    Take www.f3ck.com/cgi-bin/test.pl as an example. I'd rather you actually test someones theory before trashing it, especially when you obviously have no clue what you're preaching.

    Would you change the PHP interpreters permissions when you want to stop supporting PHP? - no, don't be rediculous. This is no different.
    Last edited by Bilco105; 01-15-2008 at 06:57 AM.
    Rob Greenwood
    RedHat Certified, Unix Consultant
    http://www.linkedin.com/in/bilco105
      0 Not allowed!

  14. #14
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    Would you change the PHP interpreters permissions when you want to stop supporting PHP? - no, don't be rediculous. This is no different.
    The user didn't ask 'how do I stop supporting cgi, did they? NO. They asked 'how do I prevent perl from working'. This is MUCH different than 'how do I stop supporting php'.


    Disabling mod_cgi does not prevent perl from working. The sooner you get that through your head and UNDERSTAND it, the better.


    Just because your opinion differs from another, doesn't make that opinion wrong
    It's not about "opinion", it's about FACT.
    Disabling mod_cgi does NOTHING to prevent 99% of the hacks that are out there, written in what? PERL. Why? Because they are called using the perl binary/inerpreter. ALL disabling mod_cgi does is removes cgi from someone's directory. OOOH, gee, I'll just upload a perl script, call it through shel, and be done.

    If you want to TRULY prevent perl from working (as BOTH the title and the thread request), you need to disable it by changing the permissions. Disabling mod_cgi would be a decent ADDITION to that (to prevent someone from uploading their own handlers), and I never said it wouldn't, BUT disabling mod_cgi, alone, by itself does NOT prevent perl from working!
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details
      0 Not allowed!

  15. #15
    Join Date
    Apr 2005
    Posts
    1,711
    This thread is too hot for me!
    (This is why I use PHP, not Perl)
    For the record, I concur with linux-tech.
      0 Not allowed!

  16. #16
    Join Date
    Oct 2002
    Location
    Manchester, UK
    Posts
    1,164
    I never said it would 'prevent perl from working', as thats not what the OP requested, I'll repeat it for you..;

    i want to know how can i prevent perl/cgi files from working on all virtual hosts on both apache2/apache1.3 !
    I don't disagree that changing the permissions of Perl isn't a viable solution, however, its easily worked around.

    You cannot just 'call' perl from within a script and expect it to work. Apache needs to know how to handle the request, just as it does with PHP, rails or whatever else you want to hook in. By removing its ability to do just that, removes any way of perl being processed through the webserver (which is what the OP requested).

    As a test, set yourself up with a webserver with mod_cgi enabled. Change the permissions of the perl binary to your reccommendation, you now have a non-working perl (Obviously). Ok, now upload a seperate perl binary and change the shebang. Now you have a working perl installation again.

    As a second test, set yourself up with a webserver with mod_cgi disabled. Upload a seperate perl binary and change the shebang. What happens? - apache doesn't understand that the request is dynamic and displays the static code, standard apache behavour.

    Just agree to disagree on this one. Your solution isn't the most effective, no matter how much bold writing you back it with.
    Last edited by Bilco105; 01-15-2008 at 12:11 PM.
    Rob Greenwood
    RedHat Certified, Unix Consultant
    http://www.linkedin.com/in/bilco105
      0 Not allowed!

  17. #17
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    I never said it would 'prevent perl from working', as thats not what the OP requested
    Yes, yes it is

    how to prevent perl from working ?

    however, its easily worked around.
    SO is the mod_cgi 'suggestion'. In fact, the mod_cgi 'suggestion' doesn't stop a single threat.

    Both are worked around, the mod_cgi suggestion, doesn't actually STOP anything security wise, and doesn't do a thing.

    The permission modification of perl ISN'T easily worked around though it is worked around. If you've got the server setup right (no compilers except to root), then you have to find perl built exactly for that system, download it, and use it. Not everyone has that ability . phpshell exploits, however, are very readily available.
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details
      0 Not allowed!

  18. #18
    Join Date
    Nov 2001
    Location
    Ann Arbor, MI
    Posts
    2,978
    I don't know about threat, but it will certainly stop perl/CGI on all virtual hosts in apache.

    Bilco15, at least linux-tech/Tom didn't say you were wrong this time.

    Unfortunately Tom's attitude in this case will make me ignore anything worthwhile that he may post in the future.
    -Mark Adams
    www.bitserve.com - Secure Michigan web hosting for your business.
    Only host still offering a full money back uptime guarantee and prorated refunds.
    Offering advanced server management and security incident response!
      0 Not allowed!

  19. #19
    Join Date
    Oct 2002
    Location
    Manchester, UK
    Posts
    1,164
    SO is the mod_cgi 'suggestion'. In fact, the mod_cgi 'suggestion' doesn't stop a single threat.
    Provide examples.

    I wouldn't post a solution unless I had tested it, or had previous knowledge that it works as expected. I don't work on hearsay...

    I've already proved my method works, and works correctly.
    Rob Greenwood
    RedHat Certified, Unix Consultant
    http://www.linkedin.com/in/bilco105
      0 Not allowed!

  20. #20
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    Provide examples.
    I've already done so, multiple times in this thread. I'm not going to repeat myself again and again. The mod_cgi solution is EASILY worked around for disabling perl.
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details
      0 Not allowed!

  21. #21
    Join Date
    Oct 2002
    Location
    Manchester, UK
    Posts
    1,164
    Quote Originally Posted by linux-tech View Post
    I've already done so, multiple times in this thread. I'm not going to repeat myself again and again. The mod_cgi solution is EASILY worked around for disabling perl.
    Constantly repeating 'WRONG' over and over doesn't constitute an example. All you've done is constantly repeat the same points without providing any actual evidence or working examples. I on the otherhand, implemented the solution I suggested, tested it, proved it works as it should and provided access to the setup.

    Anyway, i'm done with this thread. OP, I hope whichever solution you pick works well for you.

    Let us know how you get on.
    Rob Greenwood
    RedHat Certified, Unix Consultant
    http://www.linkedin.com/in/bilco105
      0 Not allowed!

  22. #22
    Join Date
    Jul 2006
    Location
    Waitakere City, NZ
    Posts
    47
    Hmmmmmmmmmm, I think for the first port of action you should buy Linux-Tech a valium, then force him to take it because he'll sit there shouting WRONG WRONG WRONG at you while you're trying to give it to him, then follow the example given by Bilco105, not to take anything away from bitserve but I'm leaning more towards Bilcos suggestion.
      0 Not allowed!

  23. #23
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    Constantly repeating 'WRONG' over and over doesn't constitute an example.
    Do you read posts, or do you just assume that the author is incompetent and refuse to read them.

    Once again for the slow people, a PERFECT example of how disabling mod_cgi does NOT "prevent perl from working"!

    Step 1
    Create php shell

    Step 2
    Upload abusable perl script

    Step 3
    Upload said perl script

    Step 4
    Execute said perl script through cron, uploaded php shell, or what have you.

    OOPS, it's possible to do. Damn

    Disabling mod_cgi DOES NOT prevent perl from working, as the title requests, and suggests. It DOES prevent CGI from working, but that is ONLY half the battle. Disabling CGI from working will NOT disable perl from working, NOR will it disable crapware from getting in your system and actually abusing it.

    OTOH, disabling PERL from working itself (sans root user) will disable ALL PERL FUNCTIONS from functioning, period. The only way around THAT? To find a perl interpreter built for that system's specifics and upload it to the server.

    Once again, one way will disable every single attack base, the other will disable minimalistic usage. BOTH are easily worked around
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details
      0 Not allowed!

  24. #24
    Join Date
    Oct 2002
    Location
    Manchester, UK
    Posts
    1,164
    Step 1
    Create php shell

    Step 2
    Upload abusable perl script

    Step 3
    Upload said perl script

    Step 4
    Execute said perl script through cron, uploaded php shell, or what have you.

    OOPS, it's possible to do. Damn
    Oh please, you have bigger problems than executing perl if your web server is insecure enough to create php shells.

    My method does exactly what was required, stop perl processing through all Apache vhosts. You can't work around it, because even WITH your solution, Perl is NOT being run through Apache.

    I can get round your solution in 5 seconds flat once I know the architecture my FTP account is running on.

    Agree to disagree and let it go. I'm sorry, but your solution isn't suitable for what was initially requested. If the request was, my webserver is insecure, how can I stop anyone uploading a shell and executing perl, you may have a case.
    Last edited by Bilco105; 01-17-2008 at 08:35 AM.
    Rob Greenwood
    RedHat Certified, Unix Consultant
    http://www.linkedin.com/in/bilco105
      0 Not allowed!

  25. #25
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    Oh please, you have bigger problems than executing perl if your web server is insecure enough to create php shells.
    Wow, way to be ignorant of the facts there. I was just using the EXAMPLE of a php shell. This can also be done through uploading (ftp), or well, anything. Again, this does NOT solve the problem. I won't go into the assumptions about 'php shells' being insecure, because that's just hillarious. phpshell has it's purpose AS LONG as it's kept under control and the user can't actually cause any damage.

    your solution isn't suitable for what was initially requested
    My solution is PERFECTLY suitable for what was 'initially requested', that being 'how to prevent perl from working'.
    In addition, the request went on to say 'how to prevent perl/cgi from working.

    YOUR suggestion, on the other hand prevents ONE from working, but not the other, so THAT is unsuitable for what was requested, not the other way around.

    By modifying perl binaries to be executable ONLY by root, this does both well enough. Again, both ways are easily worked around,but , one is more easily donee than the other.

    Next time you want to get into an argument, make sure the person you're arguing with doesn't know what they're doing, and hasn't tested the facts. I have, both sides of this. The best, and most effective way to 'prevent perl from working', as the user requested is to modify the permissions of the binary so that it can not work for anyone but root
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details
      0 Not allowed!

  26. #26
    Join Date
    Oct 2002
    Location
    Manchester, UK
    Posts
    1,164
    My solution is PERFECTLY suitable for what was 'initially requested', that being 'how to prevent perl from working'.
    In addition, the request went on to say 'how to prevent perl/cgi from working.
    Read the OP, not just the thread title. Take note of the bits specific to APACHE.

    YOUR suggestion, on the other hand prevents ONE from working, but not the other, so THAT is unsuitable for what was requested, not the other way around.
    It prevents the user from being able to execute Perl/CGI through Apache, with NO workaround at the Apache level. Exactly what was requested by the OP.

    By modifying perl binaries to be executable ONLY by root, this does both well enough. Again, both ways are easily worked around,but , one is more easily donee than the other.
    No, its overkill and easily worked around.

    Next time you want to get into an argument, make sure the person you're arguing with doesn't know what they're doing, and hasn't tested the facts.
    The person I'm argueing with already took care of that for me.

    Off-topic, stop using random uppercase works. It doesn't get your point across anymore than correct grammar, and just makes your posts irratating to sift through.
    Rob Greenwood
    RedHat Certified, Unix Consultant
    http://www.linkedin.com/in/bilco105
      0 Not allowed!

  27. #27
    Join Date
    Jul 2006
    Location
    Waitakere City, NZ
    Posts
    47
    Quote Originally Posted by linux-tech View Post
    Wow, way to be ignorant of the facts there. I was just using the EXAMPLE of a php shell. This can also be done through uploading (ftp), or well, anything. Again, this does NOT solve the problem. I won't go into the assumptions about 'php shells' being insecure, because that's just hillarious. phpshell has it's purpose AS LONG as it's kept under control and the user can't actually cause any damage.



    My solution is PERFECTLY suitable for what was 'initially requested', that being 'how to prevent perl from working'.
    In addition, the request went on to say 'how to prevent perl/cgi from working.

    YOUR suggestion, on the other hand prevents ONE from working, but not the other, so THAT is unsuitable for what was requested, not the other way around.

    By modifying perl binaries to be executable ONLY by root, this does both well enough. Again, both ways are easily worked around,but , one is more easily donee than the other.

    Next time you want to get into an argument, make sure the person you're arguing with doesn't know what they're doing, and hasn't tested the facts. I have, both sides of this. The best, and most effective way to 'prevent perl from working', as the user requested is to modify the permissions of the binary so that it can not work for anyone but root
    VALIUM VALIUM VALIUM

    Dude do you spend your entire life shouting at people and getting angry because someone says you're not 100% correct on things?

    Sure fire way to have a coranary (Or however you spell it) my friend.

    Chill out a little bit and accept the fact that everyone has said your solution works in certain cases but in their personal opinion it doesn't apply properly to this situation/scenario. It isn't the end of the world you know.

    The guy will most likely NOT (See I can use capitals to emphasise too) choose your solution now for the simple fact that you're ranting on like a child because someone took your rattle away. Reading your posts is too much like watching my 2 year old son have a hissy fit when I won't let him have my car keys.
      0 Not allowed!

  28. #28
    Join Date
    May 2006
    Location
    Teh Interweb
    Posts
    314
    I hate jumping into threads but you should know that linux-tech is one of the small handful of people on WHT that actually knows what they are talking about. You guys shouldn't knock him for sharing his expertise with you.

    [[email protected]] ~ $ cat .signature
    cat: .signature: No such file or directory
      0 Not allowed!

  29. #29
    Join Date
    Nov 2001
    Location
    Ann Arbor, MI
    Posts
    2,978
    Quote Originally Posted by CaroTech04 View Post
    I hate jumping into threads but you should know that linux-tech is one of the small handful of people on WHT that actually knows what they are talking about. You guys shouldn't knock him for sharing his expertise with you.
    Unfortunately he's not showing that here, and he's got me no longer caring whether he has anything worthwhile to contribute.
    -Mark Adams
    www.bitserve.com - Secure Michigan web hosting for your business.
    Only host still offering a full money back uptime guarantee and prorated refunds.
    Offering advanced server management and security incident response!
      0 Not allowed!

  30. #30
    Join Date
    Jul 2006
    Location
    Waitakere City, NZ
    Posts
    47
    nobody is knocking his contribution, everyone's just fed up with his attitude, from what I've seen he isn't one of the only ones on the site who knows what he's talking about he's one of many who know what they're talking about, he's just the only one who jumps up and down, insults others and in general goes around shouting in big capital letters WRONG WRONG WRONG at other peoples perfectly good answers.
      0 Not allowed!

  31. #31
    Join Date
    Sep 2004
    Location
    Flint, Michigan
    Posts
    5,765
    This has gotten far enough out of hand. </thread>
      0 Not allowed!

Posting Permissions

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