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

[Simon Clubley]

On 2017-07-30, David Froble <davef at tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> 
>> 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.
>

_This_ time it wasn't a security issue. What about next time ?

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

The very fact you make that comment means you don't understand the
issues involved.

For a really simple example, have VSI considered the possibility of
a Quantum Insert attack against their development infrastructure ?

I would remind you of what happened to some Belgium telecommunications
employees who were reading Slashdot. (It doesn't have to be Slashdot
BTW, it could be a genuine work related website.)

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

Yes, and for reasons which should be very obvious to anyone who even
vaguely understands the current security environment and the standard
practices in that environment.

For example, VSI management are making these grandiose claims about VMS
on their website by comparing VMS to Linux and other operating systems
but then VSI doesn't even implement the same security reporting
infrastructure as those other operating systems.

That comes across as showing a lack of understanding that the security
environment of today, and what is expected by an OS vendor operating
today, is very different from the 1990s. This is especially true when
VSI can't even be bothered to put on their website something as simple
as a secure reporting mechanism even when Clair has apparently done the
work for them.

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

If I understood the problem report correctly, the code was of the
general form (with either printf or another string function):

	printf(untrusted_string);

If true, that should have been caught instantly during code review.

The CVE summary is at: http://www.cvedetails.com/cve/CVE-2008-3940/

BTW, while looking for the above CVE, I also came across this one which
I had forgotten about:

http://www.cvedetails.com/cve/CVE-2008-3946/

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world