[Info-vax] Using VMS for a web server

[Jan-Erik Soderholm]

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

Jan-Erik.



>
> bill
>