2

In our enterprise we have several workers and collaborators. For the external collaborators, we have specific FTP accounts to restricted folders (test folders), and restricted access to MySQL database with priviledges. However, we have discovered that they can upload a PHP file with

system("rm -r *");

and it will perfectly work, for all paths, including at the top level of the FTP directory.

How can we prevent this from happening? Is there any way in some config file that we can have the above command to fail, and the need to use:

 system("sudo -uUSER -pPASSWORD rm -r *");

so we will only give those user and password credentials to trusted collaborators, and the others can continue working without us being afraid of any fool play from their part?

  • I am not sure I fully understand your scenario, however, I did want to warn you that you should NEVER have an FTP directory within your web space. It is a HUGE security hole. It this is the case, you want to change this immediately. If you require uploading to a web space, then there should be an additional step in the process so that you retain full control over your site and a user cannot upload anything dangerous. Cheers!! – closetnoc Jul 15 '16 at 23:40
  • I understand that I could give an out-of-public ftp to those collaborators, but they are not usual users, not anonymous, they are under job contract and all those things. And we need for them to see online results, i.e., the folders must interpret PHP and the result should be visible in web server. Some of those collaborators will be in a test period, so in the case they don't continue her/his job with us, we would be more confident if they can't execute a Linux command (via PHP) like described. There is the contract and legal restrictions, but one bad human reaction and we have a problem. – Cesar Jul 17 '16 at 8:59
  • I get you. Still, I think I would give them a rubber room of some type. Perhaps a sub-domain with everything you/they need. I was just warning you. It sounds like you know what you are doing. We get users of all stripes and experiences so I have to be careful for your sake. Cheers!! – closetnoc Jul 17 '16 at 14:55
  • Thanks closetnoc. I will check with my IT provider for a solution, as they claim that sudo always asks for the password, but the problem is that there are commands that do not need sudo, which seems to imply a too top level permission for PHP user. – Cesar Jul 18 '16 at 5:17
  • Also 'sudo -i' allows the password to only be prompted once. This is dangerous even when you know what you are doing... I know... I had to rebuild a test server once. ;-) Ooopppsss!! But just once! – closetnoc Jul 18 '16 at 5:20
1

The most secure thing to do in this instance is to prevent these temporary user accounts from having sudo access on the server. If they are able to upload a PHP file to the server and run it through their browser then this is a greater security hole than you may realise. On the first hand the server could be misconfigured to run PHP files as the user who uploaded them in which case that indicates that all these temporary contract users have been given root level sudo access which they shouldn't have. In the other case if the server is running all PHP files under the web server user (similar to www-user) which is the way it should be configured that then indicates that the www-user account has sudo access which is even more dangerous as anyone who connects to the web server can then run a sudo command if they can feed one in through a badly written PHP file that does not prevent dangerous commands being passed through it.

Best thing here is to limit sudo access to staff who absolutely need it and absolutely disable it for the apache www-user account.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.