[Info-vax] Next release of OpenVMS x86

[johnwallace4 at yahoo.co.uk]

On Friday, 10 July 2020 18:37:31 UTC+1, Simon Clubley  wrote:
> On 2020-07-10, Dave Froble <davef at tsoft-inc.com> wrote:
> > On 7/10/2020 7:51 AM, IanD wrote:
> >> I'm very well aware there is VSI management who are putting their
> >> spin on things, I also don't like the fact that they publicly stated
> >> VMS security as being the best, I think it is foolish. A statement
> >> that they were not relying on VMS's solid track record in regards to
> >> security would have been better in my view
> >
> > Ok, perhaps there could be possible vulnerabilities.  But, if they are 
> > not exploited, for whatever reason, then they are not yet an issue.
> >
> 
> There are always vulnerabilities to be found.
> 
> If you are lucky, they will be reported so they can be fixed.
> 
> If you are unlucky, they will be hoarded and silently used to compromise
> systems.
> 
> IOW, just because _you_ have not heard of an exploit doesn't mean they
> don't exist.
> 
> > Nothing is perfect.  And note, the claims do not say VMS is impervious, 
> > just rather good.  Seems to me some work is happening to make it even 
> > better.
> >
> 
> Yes, VSI do pretty much claim the former. The claim from VSI management
> is that VMS is the most secure operating system on the planet, which is
> nonsense, especially when other operating systems have much more advanced
> security capabilities.
> 
> For example, Linux has SELinux MAC security and VMS has nothing like that.
> 
> The seL4 microkernel has been formally verified.
> 
> VMS doesn't even have basic protections (by today's standards) such as ASLR.
> 
> So tell me David, do you agree with VSI management's statement and if so why ?
> 
> > So their claims don't bother me.  Until there are successful exploits, 
> > it is secure.  Perhaps there will never be any successful exploits.
> >
> 
> What would you call my DCL vulnerability ?
> 
> > Carefully note that any past exploits did not happen on the software VSI 
> > is currently distributing.
> >
> 
> https://vmssoftware.com/pdfs/security/2018/03/VSI_CVE-2017-17482.pdf
> 
> Note that the security vulnerability page mentioned in that PDF was
> removed by VSI sometime around several months after that PDF was finally
> released. Why VSI would go to the effort of doing that is beyond me.
> 
> >>
> >> Let's not sink the VMS ship before it's had time to sail but I do
> >> agree with you, it was silly to promote it's security virtues when
> >> it's been many years since it's come under a modern microscope
> >> analysis in regards to attacks and exploits
> >
> > Haven't seen any of those "modern microscopes" lately ....
> >
> 
> That's nothing for you to be proud of David. You are not expected to
> be a security expert but you should at least have a familiarity with
> today's security issues and attack methods when you are writing software.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

"I have formally verified this program but I have not tested it."

... time passes ...

"I have tested this formally verified program and its behaviour 
is erroneous and there may be security vulnerabilities as a 
result."

... time passes ...

(formal verification falls even more out of fashion; x86 or 
Windows or MacOS doesn't have it therefore nobody needs it. 
VIPER [verifiable integrated processor for enhanced reliability] 
did have it and it was wrong.)

ASLR has been readily defeatable in the real world. Is it smoke 
and mirrors, or is it snake oil. It certainly isn't the panacea 
it is often claimed to be. 

Intel SGX is about as much use as a chocolate fireguard. Well, 
less, actually.

Etc.