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

[David Froble]

Simon Clubley wrote:
> 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.

No, it means I have a wicked sense of humor ....

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

When the x86 port and such is done, then perhaps your insistence will be more 
appropriate.

> 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.
> 
I don't disagree with much of what you write, not just now.  However, I feel 
your priorities may be a bit skewed, at least for now.  The x86 port isn't 
everything, it's the ONLY thing.  (Credit to Vince Lombardi)

Another thing is, it seems that you feel that security is the job of the vendor. 
  Perhaps, as far as sorta secure code goes.  But the buck stops with the end 
user, who must define their vulnerabilities, and see that they are protected.