php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #17415 using exec
Submitted: 2002-05-24 14:25 UTC Modified: 2002-05-24 14:59 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: zony at zonehomes dot com Assigned:
Status: Not a bug Package: *Directory/Filesystem functions
PHP Version: 4.2.1 OS: Windows 2000 IIS 5 SP2
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: zony at zonehomes dot com
New email:
PHP Version: OS:

 

 [2002-05-24 14:25 UTC] zony at zonehomes dot com
One cannot utilize the exec() funtion without granting read/execute rights to the IUSR-machinename account on cmd.exe. This is a major security flaw on windows systems. Almost all of the exploits on IIS systems stem from allowing the IUSR account to have read/execute permissions on cmd.exe.

So, with that said, the exec() function is unusable on IIS. I'm new to PHP and I don't know who handles the decisions for which accounts an app runs under, but whoever you are you need to change this yesterday to protect the users of PHP on windows.

Peace.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-05-24 14:59 UTC] imajes@php.net
whilst there is a bug here in that exec is pretty useless on win2k, giving r/w permissions on cmd.exe isn't a bug -- this is the only way really you can do filesystem stuff on windows.

this is the same as php on *nix, it needs access to a standard shell to perform file functions.

none of the filesystem functions are overly safe, (it probably would negate the point of them if they were) but if you were to set permissions aggressively, you should be able to workaround this.

as for who handles accounts for which apps run under, that'd be Bill Gates, and his IIS team -- IUSR-<task/machine name> accounts are designed to be unprivileged accounts that can run stuff (sounds wierd, huh?) under the guise of internet programs. 

PHP is a powerful scripting language -- and if you really want to be safe, move to *nix, chroot, and restrict access to functions.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 15:01:29 2024 UTC