[Info-vax] VMS and the Internet of Things (IoT)

[Stephen Hoffman]

On 2016-09-12 21:15:55 +0000, Chris said:

> On 09/12/16 20:30, Stephen Hoffman wrote:
>> On 2016-09-12 18:13:26 +0000, Chris said:
>> 
>>> Why is that ?. Ignoring other factors, any non X86 architecture is 
>>> inherently more secure that X86, in term of binary virus and malware 
>>> susceptibility. Most of the world's malware depends on X86 architecture 
>>> to run at all...
>> 
>> More than a little of the recent malware depends on Word macros, and 
>> — barring holes in the iLO firmware or Intel AME firmware — all of 
>> the malware is specific to a particular software package or operating 
>> system, and not to the underlying hardware. Bare hardware doesn't and
>> can't run malware. But then I've chased around more than a little 
>> malware that was wonderfully overloading OpenVMS servers, due to bugs 
>> in the OpenVMS NTP server being used for reflection attacks.
> 
> I guess we must agree to differ there. From what I understand, the 
> object of the exercise is to get a binary executable into a region of 
> memory where it can be run. Doesn't matter if the attack
> surface is a word or spreadsheet macro, email client, or browser 
> exploit, the result is the same. Of course the "bare metal" machine 
> runs code, it's what it's designed to do :-).

That's if you're stack smashing, and that code is still entirely 
dependent on the operating system that's running in the box.

That memory must be executable and more than a little of it isn't, and 
the code or data elsewhere in memory must have a layout that the 
malware understands — this is why app or system crashes can sometimes 
point to latent security issues, as the malware doesn't get the layout 
right — and it's why systems (other than OpenVMS) have moved to address 
space randomization, stack canaries and other features.   Yes, there's 
executable code — for some malware.   But there still has to be an 
entry that provides a way to get that code loaded, and a way to get the 
processor to execute that code, and that's *entirely* system or 
software dependent.   There's no magic here.

More than a little of the current malware has absolutely nothing to do 
with executable machine code, it's Office macro code.    Some of the 
more recent malware — and what's now declining on platforms with modern 
security and ASLR — isn't even code, it's data.   That uses what's 
called ROP; return oriented programming.   The data causes existing 
operating system or application code to execute in completely 
unexpected and unforeseen ways, and that code is already and inherently 
resident in executable storage.   Malware using ROP is very dependent 
on the other code around, which means the malware has to know the 
layout of virtual memory and ASLR and stack canaries and such — all 
lacking on OpenVMS — makes these approaches vastly harder.

Other malware loads via Flash or Java weaknesses, which can be platform 
independent.   It wouldn't surprise me to learn that OpenVMS I64 with a 
browser and web start configured — not all that easy to get there — 
would be vulnerable to some of the Java malware around, too.   That's 
due to the ancient version of Java.

With Office macros shut off via policy and with EMET loaded, and 
without Adobe Flash and Java web start present or with both disabled, 
you're probably going to do pretty well with Windows 10 on x86-64, too.

> It's one of the primary reasons why I continued to run an aged Alpha 
> box as the main lab server for years. Now Solaris, but also 
> investigating FreeBSD, non X86 version of course.

Which is as much about the software involved — and some of which can be 
infested or problematic — as the underlying hardware.

> Overall, I think Power would have been a better machine to port VMS to, 
> in terms of the sort of markets that both address, but I guess it would 
> be unacceptable for all kinds of reasons...

Porting OpenVMS to Power is one of the worst ideas around.   Great 
processor, certainly.   It'll be expensive to buy and rarely 
encountered outside of specific sites and with everything that tended 
to make Alpha a business problem and a competitive disadvantage, and 
for the foreseeable future.  x86-64 won this round, and whether it's 
ugly or not, it's currently the only financially viable choice — 
porting to Power hammers OpenVMS development for another five or ten 
years, further splits what exists of the OpenVMS installed base, and is 
more likely to contribute to the end of OpenVMS than to its 
renaissance.  In five or ten years or whenever x86-64 architecture has 
a serious competitor and particularly one that's in volume server 
production — Power or AArch64 or whatever — then that's worth a look.   
Then.   But OpenVMS needs to get its features and capability and 
security and the rest more competitive far before that port, and that 
development and porting work can only happen well after OpenVMS x86-64 
and ISV software and end-user software is ported over and working.

Here's what Power is right now: 
https://www.youtube.com/watch?v=SSUXXzN26zg   It's (in the most polite 
terms) a distraction.   It's flailing, thrashing, indecision, added 
costs, product fragmentation, increased costs...  And it's a whole lot 
more work, and more expensive boxes, and all for... well... how much 
specific end-user benefit past what x86-64 provides?


-- 
Pure Personal Opinion | HoffmanLabs LLC