[Info-vax] Using VMS for a web server
Jan-Erik Soderholm
jan-erik.soderholm at telia.com
Wed Jun 10 11:21:09 EDT 2015
Bill Gunshannon skrev den 2015-06-10 14:29:
> In article <ml8kdi$g8a$1 at news.albasani.net>,
> Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:
>> Simon Clubley skrev den 2015-06-10 02:32:
>>> On 2015-06-09, Jan-Erik Soderholm <jan-erik.soderholm at telia.com> wrote:
>>>>
>>>> OK. That needs a script called wawalo.php already beeing on the server
>>>> in a directory where the server can execute it. The exploit is realy
>>>> to be able to upload the wawalo.php file in the first place.
>>>>
>>>
>>> Actually what I read it as was that a PHP script installed for a
>>> legitimate purpose on the server (as part of, say, a PHP application)
>>> had a vulnerability which allowed attacker controlled commands to
>>> be executed.
>>
>> OK. I read that a file wawalo.jpg was first uploaded, then renamed
>> into .php and finaly executed. The only purpose of this file was
>> to exloit this PHP "feature", as I understood.
>
> Don't know where you saw that. Certainly not in my logs.
>
>>
>> But yes, it might also have been a file that was part
>> of some application...
>
> Except that as I showed, it seems to work with any random PHP script.
> Or maybe it takes a script that uses some particular feature of PHP.
> I don't know, I don't reall care. I have a real job. Oh wait, only
> for 15 more days!! :-)
>
>>
>>
>>>
>>>> If you have a server setup where someone can both upload a random
>>>> file and then also execute that file just like that frm the same
>>>> directory, you have a severe problem.
>>>>
>>>> Now, is this a "hole in PHP"? Or could the same thing be done
>>>> using any tool that can take an input parameter and execute it?
>>>>
>>>
>>> In this case, I think I would class this as a PHP application
>>> vulnerability and not a PHP vulnerability itself.
>>>
>>> However, speaking as someone who has actually written PHP code, the
>>> negative reputation the language itself has in some quarters is well
>>> justified.
>>
>> Right, I'm in no way defending PHP as such! It's just that this
>> was used as an argument against having a web server on VMS. You
>> can have that without PHP, if you like.
>
> If you are refering to me, I never intended it to be an argument
> against VMS Web Servers. I was merely pointing it out and really
> wondering if the same exploit would work at all on VMS.
Yes, if the actual PHP script has system() or eval() calls
using the URL variable as paramters, I guess that would work
just as fine on VMS.
I am not convinced that you can get the PHP interpreter to
just run any code you like, without the "support" of a badly
written PHP script.
> The argument
> is actually against PHP on anything.
>
>>
>> I'm not even sure that that exploit would work on VMS where
>> the scripting processes usualy runs in a restricted user
>> context.
>
> So does a script on a Unix box running apache. But on many webservers
> ther eis a thing called SUEXEC that let's local users have scripts in
> their web pages that run as themselves. Sometimes it is necessary for
> a web app to write data back. In the past this required at least one
> file with world write privs. Always a bad idea. This isn't perfect
> but it's better than it used to be. Although I doubt it gets used much,
> if at all, I expect that VMS has the needed functionality to do this too.
>
> bill
>
More information about the Info-vax
mailing list