[Info-vax] VMS security, was: Re: OpenVMS books

[David Froble]

Simon Clubley wrote:
> On 2017-07-29, Kerry Main <kemain.nospam at gmail.com> wrote:
>> Or.. since we doing the "lets do some pure 100% speculating", the
>> alternate speculating might be that the security researchers tried to
>> hack recent (not 15+ year old UCX bugs) versions of OpenVMS and they
>> gave up trying.
>>
>> Since neither of us know which scenario is true, then either one of us
>> could be right.
>>
> 
> The DCL bug I found recently appears to have laid dormant within VMS
> for at least a couple of decades until I decided on a whim to fuzz
> the DCL recall buffer one Sunday.

I'm sure there are many things that could cause problems.  However, during 
normal usage, how often will someone attempt to flood the recall buffer with 
nulls?  I'm not defending the lack of some sanity checking.  But it didn't seem 
to be a security issue.

If all you want to do is crash the computer, just pull the plug ...

See how easy that was?

I learned long ago that if while taking specs for something, and you hear the 
words "that never happens", count on that being one of the first things that 
bites you.  So, the lesson should be, vet all input data, completely.  Not 
always done.

> I may have just got lucky but it only took me several minutes to
> crash DCL. Finding the cause of the crash took a lot longer however
> due to my limited free time at the moment and especially since my
> initial assumption about the cause of the crash was wrong. :-)
> 
> My point is: How many other bugs are just waiting to be discovered
> in VMS and will the next one turn out to be a security vulnerability ?

I'm going to predict that most won't be security issues.  Some will.

>> Especially when the value of security bugs that can crack a platform
>> that runs stock exchanges, banks, lotteries, nuclear stations, power
>> utilities would likely go for a very high price in the bad guy world.
>>
> 
> And it doesn't help matters when certain portions of the VMS community
> sticks its head in the sand and tries to claim the issues affecting
> other operating systems do not apply to VMS.

I think those people are few.

> And given that list of _very_ high value targets above, VSI should be
> gearing up to detect and stop nation state attacks against VMS and the
> VSI VMS development infrastructure just like some other vendors do with
> their own critical infrastructure products.

So, they need to install surface to air missiles?

> Instead at the moment, we have a vendor that can't even be bothered to
> put on its website the security reporting mechanism Clair says he had
> people write towards the end of last year.

That's really bugging you, huh?

>> Btw - while the finger bug was something that needed fixing, one should
>> remember that the service is disabled by default and I have never known
>> any OpenVMS system that even uses finger. It was/is a service that came
>> from the UNIX based code that was ported to OpenVMS as UCX.
>>
> 
> That's not the point. The point is that the code should never have
> passed peer review.

That wasn't really a VMS issue, other than the mistake of adopting *ix junk.