OpenVMS Boot Camp

[BillPedersen]

OpenVMS Boot Camp Pre-Conference Seminars - A great deal!

What is the best way to improve your Alpha environment...
How to get ready for OpenVMS Version 9!
Moving your Alpha based OpenVMS environment into the 21st Century.
Supporting new applications with your existing data.
Evolving your infrastructure to the 21st Century.

https://www.eiseverywhere.com/ehome/openvms2017/547969/

[Simon Clubley]

There's clearly still a market for supported Alpha systems.

How many VAX systems remain in production use ?

In the Windows world, when people need to run old unsupported
versions of Windows (say Windows XP) for some reason, they are
supposed to take strong measures to isolate those systems from the
rest of their network so that newly discovered vulnerabilities in
those old versions of Windows are not accessible from, or exposed to,
the rest of their network.

Do people still running old unsupported VAX systems take similar
precautions ?

Don't forget that vulnerabilities found in versions of VMS running
on more modern architectures may also apply to VAX systems.

Simon.

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

[Colin Butcher]

Thanks for all the work to Bill and the rest of the organisers. There's
a great deal of stuff going on in the background to make this event
happen and to make it successful.

[IanD]

Most places I worked in where Vax's were still in use, they were internally focused tucked away inside the bowls of a corporate network and not internet facing at all. They also tended to be running on emulators to mitigate the hardware risk

The DEFCON event that showed up glaring holes in VMS security should have been a wake-up call that VMS needed / needs work

When the exploit was discovered for VMS at DEFCON, I saw endless comments about that being because of the tcp stack and not part of VMS and all other down-playing. That type of attitude is scary IMO and will not help VMS harden itself against modern exploits

Transparency, fast reporting mechanisms, community focus on security as drastically needed

The greatest security risk is the attitude that thinks everything is ok and that VMS is sitting pretty security wise

[Simon Clubley]

On 2017-09-04, IanD <iloveo...@gmail.com> wrote:
>
> Most places I worked in where Vax's were still in use, they were internally
> focused tucked away inside the bowls of a corporate network and not internet
> facing at all. They also tended to be running on emulators to mitigate the
> hardware risk
>

They also need to be isolated from the other parts of the internal network;
isolating them from the external networks is not enough.

A recent high profile Windows XP example would be the disabling of the
NHS computer network due to WannaCry.

There are a good number of comparisons which can be made between old VMS
versions and old Windows versions when it comes to security.

BTW, as you are aware, emulators only handle the hardware risk; insecure
operating system code running on an emulator is still insecure operating
system code. I hope the people choosing to virtualise their VAX and Alpha
systems also realise this.

> The DEFCON event that showed up glaring holes in VMS security should have
> been a wake-up call that VMS needed / needs work
>
> When the exploit was discovered for VMS at DEFCON, I saw endless comments
> about that being because of the tcp stack and not part of VMS and all other
> down-playing. That type of attitude is scary IMO and will not help VMS harden
> itself against modern exploits
>

Multiple exploits actually, both within TCP/IP and VMS itself. I too have
also noticed how some people move the discussion away from VMS itself and
towards the TCP/IP stack when discussing that event.

On a related note, sometimes something can still be of concern even if
it's not a full exploit as it can point to possible weaknesses elsewhere.

As such, I encourage people to report any dodgy code they find so the
dodgy code can be fixed and so that a review can be carried out to see
if the same type of dodgy code is being used elsewhere in a place where
it might _really_ matter.

> Transparency, fast reporting mechanisms, community focus on security as
> drastically needed
>

I think everyone around here now knows what I think about this area. :-)

> The greatest security risk is the attitude that thinks everything is ok and
> that VMS is sitting pretty security wise

As I've mentioned before, in some ways the Linux/Windows people are more
secure than VMS because they _know_ their systems are subject to
vulnerabilities being found and they plan accordingly.

[clairg...@gmail.com]

The VMS engineers I've worked with (for 30 years now) do not have such an attitude, never have, never will - period. There may be people in "the VMS community" who do but it will not be anyone who has ever written VMS operating system code. For example, three of us spent significant time over the last 2-3 weeks analyzing, testing, and tracking down a couple problems that were sent to us. Given the people involved, that took time away from 1) a future security-related project and 2) porting to x86. This was normal procedure, not an exceptional case, when such problems are discovered.

Are there more problems in VMS? Of course.....10s, 100s, 1000s, who knows? What I can tell you is that we will never be complacent when it comes to the quality of the system.

[Simon Clubley]

On 2017-09-04, IanD <iloveo...@gmail.com> wrote:
>

> The greatest security risk is the attitude that thinks everything is ok and
> that VMS is sitting pretty security wise

Eternal September is playing up so I can see mine and Clair's postings
in Google Groups but not in slrn at the moment so I cannot directly reply
to my earlier post.

In order to avoid any misunderstandings, I want to make it very clear
that I am talking about parts of the VMS community in my earlier post
and _NOT_ VMS Engineering itself.

I am the person who sent those issues to Clair and I can confirm that,
while it would be nice for Clair's management to place his security
reporting mechanism on the VSI website, Clair's actual response so far
has been absolutely impeccable, especially when you consider that the
issues I have reported currently fall into the category of dodgy code
instead of a CVE.

I will not be making any details public for now as I am giving Clair
a reasonable amount of time to investigate my findings and to make any
precautionary patches available if he deems that necessary.

[Simon Clubley]

On 2017-09-04, IanD <iloveo...@gmail.com> wrote:
>

> The greatest security risk is the attitude that thinks everything is ok and
> that VMS is sitting pretty security wise

I apologise for posting this a second time but Eternal September has
just had a hardware failure and it appears not all recent messages
were fully propagated, especially to other Eternal September users.

It's in reply to a message which Clair posted yesterday in which he
commented on VMS Engineering standards and about VSI working on a couple
of recently received issues.

That message, and my original posting, are visible at Google Groups if
they are not in your normal newsfeed (they never arrived back at Eternal
September). Sorry if you have already read this reply but I want the VSI
engineers to know I was not targeting them in my original posting.

My earlier reply:
-----------------

In order to avoid any misunderstandings, I want to make it very clear
that I am talking about parts of the VMS community in my earlier post
and _NOT_ VMS Engineering itself.

I am the person who sent those issues to Clair and I can confirm that,
while it would be nice for Clair's management to place his security
reporting mechanism on the VSI website, Clair's actual response so far
has been absolutely impeccable, especially when you consider that the
issues I have reported currently fall into the category of dodgy code
instead of a CVE.

I will not be making any details public for now as I am giving Clair
a reasonable amount of time to investigate my findings and to make any
precautionary patches available if he deems that necessary.

[Robert A. Brooks]

On 9/5/2017 8:50 AM, Simon Clubley wrote:

> It's in reply to a message which Clair posted yesterday in which he
> commented on VMS Engineering standards and about VSI working on a couple
> of recently received issues.
>
> That message, and my original posting, are visible at Google Groups if
> they are not in your normal newsfeed (they never arrived back at Eternal
> September). Sorry if you have already read this reply but I want the VSI
> engineers to know I was not targeting them in my original posting.

I never saw Clair's response, nor your reply to his response.

I use Eternal September for my news feed, and it's not been particularly good
the last couple of weeks -- I have not been able to connect unless I use an unsecured port.

--

-- Rob

[Paul Sture]

Here's the announcement on <http://www.eternal-september.org/>

Time zone CET assumed, since their whois record shows them as being in
Germany:

-- quote --
2017-09-05 09:38:05 Server news.eternal-september.org replaced

The old reader server news.eternal-september.org had to be replaced
by new hardware just before the scheduled replacement date. The new
server is up and running, DNS changes are underway. The new server
is called reader.eternal-september.org, but will also be available
under the usual name as soon as the DNS changes have fully
propagated. Currently, connections on port 80 and 443 are not
available yet. These will be available again soon. The new server
has an SSL certificate for both reader.eternal-september.org and
news.eternal-september.org. UUCP connectivity is currently not
available, but will be re-established tomorrow.
-- end quote ==

--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.

[Simon Clubley]

On 2017-09-05, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
>

> I never saw Clair's response, nor your reply to his response.
>

In that case, here is Clair's response (taken from Google Groups):

(I've chopped out some of the earlier quoted text).

|On Monday, September 4, 2017 at 1:31:54 AM UTC-4, IanD wrote:

|> On Sunday, September 3, 2017 at 1:33:23 PM UTC+10, Simon Clubley wrote:
|> >
|> > There's clearly still a market for supported Alpha systems.
|> >
|> > How many VAX systems remain in production use ?
|> >
|> > In the Windows world, when people need to run old unsupported
|> > versions of Windows (say Windows XP) for some reason, they are
|> > supposed to take strong measures to isolate those systems from the
|> > rest of their network so that newly discovered vulnerabilities in
|> > those old versions of Windows are not accessible from, or exposed to,
|> > the rest of their network.
|> >
|> > Do people still running old unsupported VAX systems take similar
|> > precautions ?
|> >
|> > Don't forget that vulnerabilities found in versions of VMS running
|> > on more modern architectures may also apply to VAX systems.
|> >
|>

|> Most places I worked in where Vax's were still in use, they were internally focused tucked away inside the bowls of a corporate network and not internet facing at all. They also tended to be running on emulators to mitigate the hardware risk
|>
|> The DEFCON event that showed up glaring holes in VMS security should have been a wake-up call that VMS needed / needs work
|>
|> When the exploit was discovered for VMS at DEFCON, I saw endless comments about that being because of the tcp stack and not part of VMS and all other down-playing. That type of attitude is scary IMO and will not help VMS harden itself against modern exploits
|>
|> Transparency, fast reporting mechanisms, community focus on security as drastically needed
|>

|> The greatest security risk is the attitude that thinks everything is ok and that VMS is sitting pretty security wise
|

|The VMS engineers I've worked with (for 30 years now) do not have such an attitude, never have, never will - period. There may be people in "the VMS community" who do but it will not be anyone who has ever written VMS operating system code. For example, three of us spent significant time over the last 2-3 weeks analyzing, testing, and tracking down a couple problems that were sent to us. Given the people involved, that took time away from 1) a future security-related project and 2) porting to x86. This was normal procedure, not an exceptional case, when such problems are discovered.
|
|Are there more problems in VMS? Of course.....10s, 100s, 1000s, who knows? What I can tell you is that we will never be complacent when it comes to the quality of the system.
|

[Arne Vajhøj]

On 9/4/2017 8:26 AM, Simon Clubley wrote:
> On 2017-09-04, IanD <iloveo...@gmail.com> wrote:
>> Most places I worked in where Vax's were still in use, they were internally
>> focused tucked away inside the bowls of a corporate network and not internet
>> facing at all. They also tended to be running on emulators to mitigate the
>> hardware risk
>
> They also need to be isolated from the other parts of the internal network;
> isolating them from the external networks is not enough.

Computers totally isolated are usually not very useful.

> A recent high profile Windows XP example would be the disabling of the
> NHS computer network due to WannaCry.
>
> There are a good number of comparisons which can be made between old VMS
> versions and old Windows versions when it comes to security.

VAX'es and XP PC's are typical used for very different purposes
resulting in different location within the network.

And the attack vector is very different. I consider it likely
that security bugs per KLOC is at least as high for VMS VAX as
for a patched WinXP (WinXP was under heavy attack for many
years resulting in a lot of security bugs being found and
fixed - VMS VAX has not gone through anything like that).
But I stil think the attack vector on (most) VMS VAX systems
will be much smaller than WinXP systems. There are simply
a lot less stuff running (less KLOC to have bugs). And
on top of that there is the obfuscation factor - non
standard protocols, non standard instruction set, non
standard OS etc. all make it less of a target for
broad attacks (it does not protect against attacks
going specifically after them).

Arne

[Simon Clubley]

On 2017-09-05, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 9/4/2017 8:26 AM, Simon Clubley wrote:
>> On 2017-09-04, IanD <iloveo...@gmail.com> wrote:
>>> Most places I worked in where Vax's were still in use, they were internally
>>> focused tucked away inside the bowls of a corporate network and not internet
>>> facing at all. They also tended to be running on emulators to mitigate the
>>> hardware risk
>>
>> They also need to be isolated from the other parts of the internal network;
>> isolating them from the external networks is not enough.
>
> Computers totally isolated are usually not very useful.
>

The general idea is to have very severely restricted access instead
of no access and to maybe force access to the old unsecure old VMS
systems go through some intermediate machine or process instead.

>> A recent high profile Windows XP example would be the disabling of the
>> NHS computer network due to WannaCry.
>>
>> There are a good number of comparisons which can be made between old VMS
>> versions and old Windows versions when it comes to security.
>
> VAX'es and XP PC's are typical used for very different purposes
> resulting in different location within the network.
>

The general comparison I was making is that you have to increasingly
restrict access and generally lock things down tighter if you need to
continue to operate the old operating systems in your local network.

> And the attack vector is very different. I consider it likely
> that security bugs per KLOC is at least as high for VMS VAX as
> for a patched WinXP (WinXP was under heavy attack for many
> years resulting in a lot of security bugs being found and
> fixed - VMS VAX has not gone through anything like that).

Oh, I agree and don't forget that issues could be found which affect
VAX/VMS even when those issues were found on more modern architectures
instead of on VAX directly.

> But I stil think the attack vector on (most) VMS VAX systems
> will be much smaller than WinXP systems. There are simply
> a lot less stuff running (less KLOC to have bugs). And
> on top of that there is the obfuscation factor - non
> standard protocols, non standard instruction set, non
> standard OS etc. all make it less of a target for
> broad attacks (it does not protect against attacks
> going specifically after them).
>

Agreed on the latter. There are always things waiting to be found,
regardless of operating system, when you decide to start looking for
them. (And don't forget that those things don't have to be actual
exploits either as discovered weaknesses can give you ideas about
other things to look for which could be actual exploits.)

[IanD]

> |
> |Are there more problems in VMS? Of course.....10s, 100s, 1000s, who knows? What I can tell you is that we will never be complacent when it comes to the quality of the system.
> |

<The above was Claire's response to a comment made by myself>

It was never my intention to say VSI or the VMS OS writers were complacent about security - sorry if it even remotely came across this way Claire - please accept my apology if my brash commenting came across that way :-(

When commenting, I had in my mind, of how many in the VMS community reacted when at DEFCON the VMS exploit was exposed.
It's the compliance of those in the VMS community at the time that I was thinking of when I commented.

I remember talk about blaming the TCP stack because it was ported and not pure bla bla bla. I even think those words came out of my mouth too.

I've even worked with people recently who keep saying VMS is the most secure OS in the world bar none and even say things like 'it's secure'

I too once counted myself in the ignorant complacent camp until I knocked over a few security courses, then my attitude changed dramatically when I was exposed to some of the modern day hacks and to what has been done with some linux kernel code to try and harden it against attacks. It's an eye opener to see the lengths hackers will go to just to find an opening.

One goes from a smug point of view about VMS being secure because of it's past and it's foundational design, to realising that security will always be an ongoing issue to work on, even for VMS.

At best your one step ahead, at worst your on par or behind attacks of earnest and big money is to be made finding openings that can be sold in black markets now, meaning the sophistication of the attacks are increasing.

Anyhow, this was a thread from a while ago but when I saw the reply, I realised my comment(s) may have been interpreted as attacking the integrity of the VSI developers, nothing of the sort was intended - sorry...

[clairg...@gmail.com]

No problem. Plus, I completely agree with you. A large part of the VMS community may well have their heads in the sand. (The developers do not.)