[Info-vax] Using VMS for a web server

[Bill Gunshannon]

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.

> 
> 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.

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>