ID: 17416 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Directory/Filesystem functions Operating System: Windows 2000 IIS 5 SP2 PHP Version: 4.2.1 New Comment:
> Why not just have php.exe call the cmd.exe in the system process? from what i think i understand you're saying here, it does. Remember, php.exe is not a user. nor indeed is IIS. Both run under the user of IUSR_*. This is inbuilt microsoft security, and to be honest, trying to work around that would be a: one hell of a hack, and b: much less secure. we don't want to be adding security holes here. and as far as your nimda reference goes -- have you noticed that nimda et al all require a script on the webserver to exploit? the reason this hasn't happened with php (yet) is because we don't distribute too many scripts with our binary. So, there is no guarantee of the existance of a script, like there is with IIS's install layout. i understand how you would feel this is a bug, but realisitically, for the most safety we have to build PHP as an unprivileged binary. Anymore, and it would be too dangerous to even consider using php -- or any other scripting engine, for that matter. Previous Comments: ------------------------------------------------------------------------ [2002-05-24 15:22:24] [EMAIL PROTECTED] Why not just have php.exe call the cmd.exe in the system process? I'd recommend allowing a choice. Either pass the logged on user or let php handle exec() in the system process (default behavior). One already allows IUSR permissions to php.exe. That way you wouldn't have to worry about requests like this (all the nimda variants et al): '/scripts/..%c1%1c../winnt/system32/cmd.exe' Coming from the Microsoft world of programming for the past 9 years I see this as a bug. If you see it as a feature request, then so be it. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=17416&edit=1
