[Info-vax] Using VMS for a web server

[Bill Gunshannon]

In article <ml6qf1$d82$1 at news.albasani.net>,
	Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:
> Bill Gunshannon skrev den 2015-06-09 14:59:
>> In article <ml6kja$e6p$1 at news.albasani.net>,
>> 	Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:
>>> Bill Gunshannon skrev den 2015-06-09 13:46:
>>>> In article <8dfc8$5576079d$5ed4324a$42996 at news.ziggo.nl>,
>>>> 	Dirk Munk <munk at home.nl> writes:
>>>>> Stephen Hoffman wrote:
>>>>>> On 2015-06-08 18:58:09 +0000, johnwallace4 at yahoo.co.uk said:
>>>>>>
>>>>>>> On Monday, 8 June 2015 16:35:04 UTC+1, li... at openmailbox.org  wrote:
>>>>>>>> It is an unknown on VAX, Alpha, and Itanium.
>>>>>>
>>>>>> I've documented cases of malware on OpenVMS, and I've reproduced one or
>>>>>> two of the more recent weaknesses — successfully — on OpenVMS.   It's
>>>>>> rare, but it happens.
>>>>>
>>>>> How did the malware enter the VMS system?
>>>>
>>>> I have no experience with it but doesn't the same PHP run on VMS
>>>> that runs on other OSes?  There's a hole big enough to drive a
>>>> Mack truck through.
>>>>
>>>>>
>>>>>>
>>>>>> I've also encountered and resolved cases with OpenVMS servers that were
>>>>>> parts of DDoS botnets, too.  OpenVMS has been subject to a couple of
>>>>>> those in recent years, too.  Everybody is patched to current, of course?
>>>>>>
>>>>>
>>>>> How does something like that work? As far as I'm aware these are
>>>>> executables, so how do they get on the VMS system, and how do these
>>>>> hackers get them running?
>>>>
>>>> Doesn't VMS support PHP?  Great attack vector.  Allows the execution of
>>>> arbitrary commands.  On Unix I have seen attackers use PHP scripts available
>>>> through the web server to run the "fetch" command to copy a telnet daemon,
>>>> written in PHP, to any writable directory they can guess at (in the past
>>>> it was just /tmp, but hopefully today no one allows executables there to run).
>>>> They then use the same method to run it and voila.  Don't know if the same
>>>> method would work on VMS, but being as it is a PHP hole, I see no reason
>>>> why not.
>>>>
>>>
>>> You would normaly run your server process (where the PHP code runs)
>>> using a dedicated username that doesn't have access to anything it
>>> doesn't need for normal processing.
>>
>> Well, guess that depends on your environment.  My users want to use
>> PHP from their web pages and one of the professors actually teaches
>> a course on how to do it.
>>
>> Now, you are going to say that you don't do that in a production
>> environment and you would be right.  But, that doesn't change the
>> security model of PHP.  I fixed the aforementioned problem by
>> removing the "fetch" command from the system.  But that was just
>> one command.  The attackers are very inventive.  They will find
>> others.  Being as PHP is just text, one could even use "cat" to
>> put the offending script on the system.  All this is just to point
>> out that unless your VMS systems live n a vacuum, they are probably
>> vulnerable to some forms of attack.  The INTERNET is no place for
>> children to play anywmore.
>>
>>>
>>> It would be simple to either review or actualy test something
>>> if you can point at a reproducer.
>>>
>>> But yes, PHP programmers have an habbit to simply concatenate
>>> input params from the user with the rest of the SQL statement.
>>> That make SQL injection very simple, just write an SQL
>>> statement in the input box instead of the expected value.
>>
>> The method I am talking about is much worse than that.  it involves
>> passing a command embedded in the URL that calls the PHP script and
>> PHP executing it.  I am sure there is a way to prevent it, but by
>> default it is a hole.  And it has been used here for numerous
>> bnreach attempts.
> 
> It would be nice to have a reproducer and test it out.
> Or at least a pointer to a description.
> 
>>
>>>
>>> If one uses SQL parameter markers that is simply impossible.
>>> All my Python code uses paramater markers since that is the
>>> "normal" way to interface to Rdb. The user has no way from
>>> the web page to interfere with the actual SQL code.
>>
>> I am not aware of similar methods in Python or even Perl, but
>> the web world is enamored with PHP at the moment.  Low hanging
>> fruit and all that.
> 
> OK. I have only read quite a lot about PHP and it's "problems"
> but never used it or had it installed on any server.
> 
> But it would surprice me *a lot* if there wasn't an available
> fix for a simple URL based exploit...
> 

The controllong body wopuld have to accept that it was a problem as
opposed to a feature.  I don;t know about others, but I don't see
that happeneing.

I don't like Python either, but I would certainly like to see Python
supplant PHP as the poster child for web scripting.

But then, in 16 days, I will no longer be responsible for the servers
here and will be doing my best to stop caring.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>