The CVE proves the vulnerability is real
[I am the same person who found the vulnerability detailed in this article.]
@AC on 1-Jan-2019
The AC is a perfect example of the kind of person in the VMS user community I was warning about in the article.
He is either clueless enough about modern security practices that he doesn't have a clue what a CVE is, or he is one of the people who denies that VMS has the same issues as other operating systems do and is in denial that a decades old vulnerability has been found by myself.
What the AC didn't say in his posting above is that he showed up in the comp.os.vms newsgroup several months ago, saying the same things as he has here and ignoring any comments which explained why this vulnerability really does exist and that VSI had produced a patch to fix it.
He only finally went away when the VSI engineer who fixed the vulnerability I found also confirmed the vulnerability was real and so was the patch which fixed it.
As for the money, the AC has already been told I am not interested in it even though the proof he seeks already exists; this wasn't the reason I did this research. Besides, I doubt the money really exists.
In case the AC is simply unaware of what a CVE is, the following should hopefully enlighten him. It doesn't explain however why he has ignored the information provided to him in comp.os.vms.
The CVE database is an industry-wide database of vulnerabilities which has existed since 1999. This specific CVE entry was created by VSI, not myself, and the text in the CVE, which shows the issue has existed since VAX/VMS V4.0, was also written by VSI after they had analysed and confirmed my research.
This means the CVE is a vendor statement confirming the vulnerability and on which platforms (VAX and Alpha) the vulnerability can be exploited to compromise the system. It is NOT merely a series of claims by myself.
This also means the VSI issued CVE _is_ the proof you seek.
BTW, this isn't the first time elements in the VMS user community have reacted in this way. The last major public discussion of VMS vulnerabilities occurred about 10 years ago when VMS was probed at DEFCON 16 and vulnerabilities were found. Some of the subsequent user community discussion was less than impressive in the knowledge displayed and the negative attitude towards the researchers.
VSI marketing
This idea that VMS stands above all other operating systems when it comes to security is also reinforced by VSI as VSI makes the idiotic claim that VMS is "the most secure operating system on the planet". And yes, that's a direct quote from VSI.
As far as I can tell, VSI justifies making this claim by comparing the number of CVEs issued for an operating system (VMS) which is probed once in a blue moon (if that!) and then comparing it to the number of CVEs issued for Linux and Windows, which is actively probed every single day by an entire army of researchers.
Unfortunately, this attitude reflects what some in the VMS user community also believe.
Final notes
I am not a professional security researcher; I am a normal programmer with a range of experience in various operating systems (including VMS) and various programming languages.
I did this one-off research because I was alarmed by the increasingly out of touch language, both by the VMS user community and VSI, about the security of VMS. I could see the possibility of the VMS users getting a very sudden wakeup call from security researchers if they saw the language on the VSI website and treated it as a challenge.
I therefore decided to temporarily put on a security researcher hat and probe VMS for a vulnerability which I could use to hit the VMS community over the head with before any third-party researchers came along and taught them the same lesson in a much more sudden manner.
As you can see from the CVE, I promptly found a vulnerability in VMS which allowed you to compromise VAX (and later Alpha when it arrived) systems for over 30 years if you have direct access to DCL. It makes you wonder what the professional researchers may find if they turn their attention to VMS.
Oh, and the reason why my discovery allowed me to compromise VMS ?
Well, it turns out that on VMS, shells running in supervisor mode (ie: DCL) have access to the privileges of the programs they run. And no, I didn't believe that either when I found it.
Non-privileged users cannot run their own custom written shell in supervisor mode without a privileged user's authorisation, but the above does mean that if a non-privileged user can get shellcode they create running somewhere inside DCL (as I did) it may be possible to use that code to compromise VMS.