Discussion:
Should VSI create a security bug bounty program for VMS ?
(too old to reply)
Simon Clubley
2016-08-15 12:39:19 UTC
Permalink
Should VSI create a security bug bounty program for VMS ?

I think there could be a number of advantages to this, provided
people in the VMS community were prepared to deal with any bugs
found in a responsible manner and not shout down any reporters.

The correct model should be a Responsible Disclosure model IMHO
so that VSI get the chance to fix the problems but also so that
any issues found are not swept under the carpet and hidden. This
also means the VMS community can discuss the implications of any
issues found as they relate to the design of VMS.

Likewise I would expect any discovered issues to be assigned CVE
numbers rather than being silently fixed in a patch without
telling the world about the issue. That's the standard for other
products and it should be the standard for VMS as well.

I would suggest a 30 day disclosure target for simple issues to
60 days for more complex issues. If something exposes a complicated
design flaw in VMS (say for example you did something clever to
get to the kernel via RMS) then extending the disclosure period
to 4-6 months would be acceptable but this disclosure period
duration should only be used when justified by the specific issue.

The bug bounty program should only apply to products shipped by
VSI (including any layered products with security implications)
and not to any third party products such as WASD which are
downloaded by the end user.

Just to be clear: I'm not associated with VSI in any way. I just
want to see what the community thinks about this.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2016-08-15 14:57:17 UTC
Permalink
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
Is there even a security contact over there?
Post by Simon Clubley
I think there could be a number of advantages to this, provided people
in the VMS community were prepared to deal with any bugs found in a
responsible manner and not shout down any reporters.
Disclosures are going to mean a flurry of patches, and very likely also
published and unresolved bugs too.
Post by Simon Clubley
I would suggest a 30 day disclosure target for simple issues to 60 days
for more complex issues. If something exposes a complicated design flaw
in VMS (say for example you did something clever to get to the kernel
via RMS) then extending the disclosure period to 4-6 months would be
acceptable but this disclosure period duration should only be used when
justified by the specific issue.
That's going to be very aggressive for the usual turn-around with
OpenVMS patches, and patch installations. It's still slow, but
somewhat closer to what should be, though.
Post by Simon Clubley
Just to be clear: I'm not associated with VSI in any way. I just want
to see what the community thinks about this.
Good fodder for a boot camp panel discussion, too.
--
Pure Personal Opinion | HoffmanLabs LLC
IanD
2016-08-15 15:23:31 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
Is there even a security contact over there?
Post by Simon Clubley
I think there could be a number of advantages to this, provided people
in the VMS community were prepared to deal with any bugs found in a
responsible manner and not shout down any reporters.
Disclosures are going to mean a flurry of patches, and very likely also
published and unresolved bugs too.
Post by Simon Clubley
I would suggest a 30 day disclosure target for simple issues to 60 days
for more complex issues. If something exposes a complicated design flaw
in VMS (say for example you did something clever to get to the kernel
via RMS) then extending the disclosure period to 4-6 months would be
acceptable but this disclosure period duration should only be used when
justified by the specific issue.
That's going to be very aggressive for the usual turn-around with
OpenVMS patches, and patch installations. It's still slow, but
somewhat closer to what should be, though.
Post by Simon Clubley
Just to be clear: I'm not associated with VSI in any way. I just want
to see what the community thinks about this.
Good fodder for a boot camp panel discussion, too.
--
Pure Personal Opinion | HoffmanLabs LLC
lol

Your talks on security / mistakes at boot camp could certainly be a platform set things up for talking about such important issues as security and what HAS to happen going forward.

Obviously you are not going to bite the hand that feeds you but I sure wish I could be there to listen t you give your talk.

I also hope probably in vain that the conference will be recorded and talks made available for purchase afterwards (even delayed by weeks if necessary), the same as I hoped last year something might happen in this regard as well.

It would be nice if they followed a similar model to hosting major sporting events here. When the event is a sell-out, free to air TV gets to broadcast the event.

I just found the list of confirmed speakers / topics - it's all pretty impressive actually.

I might make a seperate thread as I didn't see one in my causal browse here on Google Groups
John Reagan
2016-08-15 16:36:01 UTC
Permalink
Post by IanD
Post by Stephen Hoffman
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
Is there even a security contact over there?
Post by Simon Clubley
I think there could be a number of advantages to this, provided people
in the VMS community were prepared to deal with any bugs found in a
responsible manner and not shout down any reporters.
Disclosures are going to mean a flurry of patches, and very likely also
published and unresolved bugs too.
Post by Simon Clubley
I would suggest a 30 day disclosure target for simple issues to 60 days
for more complex issues. If something exposes a complicated design flaw
in VMS (say for example you did something clever to get to the kernel
via RMS) then extending the disclosure period to 4-6 months would be
acceptable but this disclosure period duration should only be used when
justified by the specific issue.
That's going to be very aggressive for the usual turn-around with
OpenVMS patches, and patch installations. It's still slow, but
somewhat closer to what should be, though.
Post by Simon Clubley
Just to be clear: I'm not associated with VSI in any way. I just want
to see what the community thinks about this.
Good fodder for a boot camp panel discussion, too.
--
Pure Personal Opinion | HoffmanLabs LLC
lol
Your talks on security / mistakes at boot camp could certainly be a platform set things up for talking about such important issues as security and what HAS to happen going forward.
Obviously you are not going to bite the hand that feeds you but I sure wish I could be there to listen t you give your talk.
I also hope probably in vain that the conference will be recorded and talks made available for purchase afterwards (even delayed by weeks if necessary), the same as I hoped last year something might happen in this regard as well.
It would be nice if they followed a similar model to hosting major sporting events here. When the event is a sell-out, free to air TV gets to broadcast the event.
I just found the list of confirmed speakers / topics - it's all pretty impressive actually.
I might make a seperate thread as I didn't see one in my causal browse here on Google Groups
I think the blanket non-disclosure statement is what keeps that from happening. That said, there are many presentations with don't have any secret information given. For instance, the material in my talks will pretty much match what I've already said here or what will be in the release notes. Maybe Bill or others on the program committee can say whether they've discussed a finer grained non-disclosure scheme.
Stephen Hoffman
2016-08-15 20:35:56 UTC
Permalink
Post by IanD
Obviously you are not going to bite the hand that feeds you but I sure
wish I could be there to listen t you give your talk.
I also hope probably in vain that the conference will be recorded and
talks made available for purchase afterwards (even delayed by weeks if
necessary), the same as I hoped last year something might happen in
this regard as well.
During the boot camp last year, most of the sessions were recorded.
Speakers were using lapel mikes and pocket recorders. The session
recordings were made available to attendees.

Over the years, very few boot camp sessions have had any confidential
content. Pragmatically, I'd expect most sessions featuring some sort
of non-disclosure or confidentiality agreement use those more for
marketing cachet or maybe for information on projects that might well
slip or might get cancelled ahead of release, than to protect anything
that was actually really secret. If it's really secret or actually
sensitive information and not the usual marketeering presentation,
don't talk about it in front of a whole lot of people. Don't put it in
your marketing materials and general presentations. Take the
discussion offline somewhere. Duh.

Why post this stuff? If you're going to go to the time and effort to
create and present sessions, you might as well get as much use and
reuse out of that effort as you can, too.

One of many organizations that's come around to this
open-it-up-for-everybody approach:
https://developer.apple.com/videos/wwdc2016/

AFAIK, the boot camp decision around (not) making the presentation
material available from boot camp was centrally encouraging folks to
pay for and to attend; financial.

I've disagreed with that, but I don't get a vote.

I've always found it's the hallway conversations and meetings and
after-hours discussions that are the real value of the event.

Individual speakers can and have made their own presentations
available, of course.
--
Pure Personal Opinion | HoffmanLabs LLC
IanD
2016-08-16 00:10:14 UTC
Permalink
On Tuesday, August 16, 2016 at 6:35:58 AM UTC+10, Stephen Hoffman wrote:

<snip>
Post by Stephen Hoffman
If it's really secret or actually
sensitive information and not the usual marketeering presentation,
don't talk about it in front of a whole lot of people. Don't put it in
your marketing materials and general presentations. Take the
discussion offline somewhere. Duh.
Exactly
Post by Stephen Hoffman
Why post this stuff? If you're going to go to the time and effort to
create and present sessions, you might as well get as much use and
reuse out of that effort as you can, too.
Everything is marketing these days. If your not out there tagging as many people as you can your limiting your success going forward.

If your squirreling away your presentations to only those that can physically attend then your limiting the audience base dramatically - effectively preaching to the converted
Post by Stephen Hoffman
One of many organizations that's come around to this
https://developer.apple.com/videos/wwdc2016/
Another good link - thanks, I'll have a look at some of those ones that look interesting simply because they are easy to access (and I dislike Apple as a company personally).

I just downloaded the 'what's new in swift', this should be interesting
Post by Stephen Hoffman
AFAIK, the boot camp decision around (not) making the presentation
material available from boot camp was centrally encouraging folks to
pay for and to attend; financial.
I've disagreed with that, but I don't get a vote.
That's understandable
Post by Stephen Hoffman
I've always found it's the hallway conversations and meetings and
after-hours discussions that are the real value of the event.
However, it would be interesting to poll people if they would still attend if video lectures where made available as well, I suspect most still will because the value as you say is in the offline discussions and networking potential.

It was the same when I attended OpenVMS training many moons ago.

I think some folk may be defending a model of financial protection that may not actually be there or need defending but only a proper survey will find this out for sure.
Post by Stephen Hoffman
Individual speakers can and have made their own presentations
available, of course.
--
Pure Personal Opinion | HoffmanLabs LLC
I wish I knew where.

Do what major sporting events do here. Once the sports arena is full and therefore the venture's maximum intake reached, they open the viewing to free-to-air TV. A similar balance I'm sure could be found.

If I could afford to attend I would. I get a buzz just looking at the topic list. I'd love to see these things posted up to YouTube so that I could partake also and direct others to the content in my travels to help show that OpenVMS is not dead.

People still pay to go to Python conferences despite the content being made available almost immediately. The Open source movement has realised that releasing content to the greater world is necessary otherwise your message is never going to get heard other than those already in the know.

I'd even pay something towards the video content, so I'm not just expecting free content. Wanna video your sessions Hoff and I'll buy them from you? (I cannot afford much but I'd be willing to pay something towards the costs)

Actually, if the event has issues getting presenters, then perhaps this could be part of the model for attracting them, allow them to sell their content (video) through the event as a form of subsidy for them attending?
Simon Clubley
2016-08-15 19:50:31 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
Is there even a security contact over there?
That's a really good question. If I had to contact someone at VSI
about a security matter, right now I'd just email one of the usual
suspects (probably via Eisner) and ask them how they wanted to
proceed but that's not an option everyone will have the knowledge
to use.

In Google, doing:

site:vmssoftware.com security contact

as well as looking at their FAQ at https://vmssoftware.com/about_faq.html
didn't reveal anything obvious either.

If someone found a security issue in VMS right now, I wonder if they
should go via VSI or HP. To be honest, if I found something in Alpha
VMS I personally would still contact VSI first because (primarily) it
might affect what VSI are doing and (secondly) because VSI could
probably route the issue more efficiently within HP than I could.
Post by Stephen Hoffman
Post by Simon Clubley
I think there could be a number of advantages to this, provided people
in the VMS community were prepared to deal with any bugs found in a
responsible manner and not shout down any reporters.
Disclosures are going to mean a flurry of patches, and very likely also
published and unresolved bugs too.
Good. That's exactly what I hope will happen. There could be some
initial instability around new types of issues which are found and
a flurry of initial work but the end result would be a far stronger
and more tested (against today's security tools and environment)
VMS as a result.
Post by Stephen Hoffman
Post by Simon Clubley
I would suggest a 30 day disclosure target for simple issues to 60 days
for more complex issues. If something exposes a complicated design flaw
in VMS (say for example you did something clever to get to the kernel
via RMS) then extending the disclosure period to 4-6 months would be
acceptable but this disclosure period duration should only be used when
justified by the specific issue.
That's going to be very aggressive for the usual turn-around with
OpenVMS patches, and patch installations. It's still slow, but
somewhat closer to what should be, though.
My suggested figures do have some slack in them but not by too much and
hopefully VSI would reduce the time taken to issue a patch over time.

However, in today's world, the above figures are at the upper limit of
what I would consider to be acceptable and yes, you are correct that
they are aggressive by traditional VMS standards (but not by current
standards elsewhere). Given the more greater interconnected nature of
today's systems, the turnaround delays inherent in the old patch model
simply are not adequate any more.

To people questioning that, don't forget VMS is about to come available
on widely available hardware for the first time in it's history, which
means that a larger number of people are probably going to start looking
for security issues in VMS.

Also don't forget that if it's a generic VMS issue, then VMS may be
vulnerable across more than one architecture.
Post by Stephen Hoffman
Post by Simon Clubley
Just to be clear: I'm not associated with VSI in any way. I just want
to see what the community thinks about this.
Good fodder for a boot camp panel discussion, too.
If someone does do that, I would be interested in hearing the results.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2016-08-15 20:43:16 UTC
Permalink
...right now I'd just email one of the usual suspects (probably via
Eisner) and ask them how they wanted to proceed but that's not an
option everyone will have the knowledge to use.
I would not trust nor even use eisner for any confidential disclosures
nor sensitive information. That system is far too ripe a target for
shenanigans and for attacks, unfortunately.
Post by Stephen Hoffman
Good fodder for a boot camp panel discussion, too.
If someone does do that, I would be interested in hearing the results.
I'm planning to attend, and will see if there's interest in a
standalone session or panel on that topic. If not, I'll ask in the
sessions I'm presenting.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2016-08-15 21:15:50 UTC
Permalink
Post by Stephen Hoffman
...right now I'd just email one of the usual suspects (probably via
Eisner) and ask them how they wanted to proceed but that's not an
option everyone will have the knowledge to use.
I would not trust nor even use eisner for any confidential disclosures
nor sensitive information. That system is far too ripe a target for
shenanigans and for attacks, unfortunately.
That's why I said I would ask them how they wanted to proceed. You could
use VMS mail to make sure you got in touch with someone to let them know
there was an issue and then they could setup some secure way for you to
send them the information.

Of course it would be preferable if the security contact procedures
were formally documented in some high profile location on VSI's website.

To VSI: don't forget that the people wanting to contact you with
security vulnerability information may not actually be a customer
of yours.
Post by Stephen Hoffman
Post by Stephen Hoffman
Good fodder for a boot camp panel discussion, too.
If someone does do that, I would be interested in hearing the results.
I'm planning to attend, and will see if there's interest in a
standalone session or panel on that topic. If not, I'll ask in the
sessions I'm presenting.
Thanks. I would appreciate that.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2016-08-15 21:32:19 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
I would not trust nor even use eisner for any confidential disclosures
nor sensitive information. That system is far too ripe a target for
shenanigans and for attacks, unfortunately.
That's why I said I would ask them how they wanted to proceed. You
could use VMS mail to make sure you got in touch with someone to let
them know there was an issue and then they could setup some secure way
for you to send them the information.
I'd be concerned that any report made via Eisner or made via a path
suggested via Eisner was going to VSI, or going to an attacker.

One of the folks managing Eisner have indicated in recent times that
they view ease of server access as a priority over connection security
and server security.

I'd wonder who I was really communicating with over there; who had
access to the discussion, and who was participating.

In general, I'd be cautious around any reporting path that wasn't
acquired via HTTPS directly with the vendor's own web site, and
preferably then involving a posted public key and preferably with a key
fingerprint confirmed via some other vendor-controlled communications
channel.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2016-08-16 01:47:48 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
Post by Stephen Hoffman
I would not trust nor even use eisner for any confidential
disclosures nor sensitive information. That system is far too ripe
a target for shenanigans and for attacks, unfortunately.
That's why I said I would ask them how they wanted to proceed. You
could use VMS mail to make sure you got in touch with someone to let
them know there was an issue and then they could setup some secure way
for you to send them the information.
I'd be concerned that any report made via Eisner or made via a path
suggested via Eisner was going to VSI, or going to an attacker.
One of the folks managing Eisner have indicated in recent times that
they view ease of server access as a priority over connection security
and server security.
I'd wonder who I was really communicating with over there; who had
access to the discussion, and who was participating.
In general, I'd be cautious around any reporting path that wasn't
acquired via HTTPS directly with the vendor's own web site, and
preferably then involving a posted public key and preferably with a key
fingerprint confirmed via some other vendor-controlled communications
channel.
What about the old fashioned way, a phone call?
Simon Clubley
2016-08-16 12:13:44 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
Post by Stephen Hoffman
I would not trust nor even use eisner for any confidential disclosures
nor sensitive information. That system is far too ripe a target for
shenanigans and for attacks, unfortunately.
That's why I said I would ask them how they wanted to proceed. You
could use VMS mail to make sure you got in touch with someone to let
them know there was an issue and then they could setup some secure way
for you to send them the information.
I'd be concerned that any report made via Eisner or made via a path
suggested via Eisner was going to VSI, or going to an attacker.
Obviously a good degree of common sense would be involved. For example,
I'm not likely to send details to ***@gmail.com :-).

In fact I couldn't see myself using any communications path to actually
send the security data that didn't involve a domain controlled by VSI.

The proper way of course is for VSI to setup formal security bug
reporting procedures on their website which would make this whole
how-to-report discussion redundant.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Simon Clubley
2016-08-15 21:05:28 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
Post by Simon Clubley
I think there could be a number of advantages to this, provided people
in the VMS community were prepared to deal with any bugs found in a
responsible manner and not shout down any reporters.
Disclosures are going to mean a flurry of patches, and very likely also
published and unresolved bugs too.
Good. That's exactly what I hope will happen. There could be some
initial instability around new types of issues which are found and
a flurry of initial work but the end result would be a far stronger
and more tested (against today's security tools and environment)
VMS as a result.
Having read that again, I should point out that I was only talking about
the flurry of patches bit when I said that this is exactly what I hope
would happen.

However, as for the second bit about people publishing unresolved bugs,
while I hope that doesn't happen and while I _strongly_ hope that
everyone will do responsible disclosure instead, full disclosure is
still preferable to you never finding out about the issue. That security
bug still exists in your systems even if you don't know about it.

As such I would be willing to tolerate a certain percentage of full
disclosure even though I strongly prefer responsible disclosure. It
would give you some short term pain, but would also give you a more
secure VMS in the longer term.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2016-08-15 17:05:11 UTC
Permalink
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
I think there could be a number of advantages to this, provided
people in the VMS community were prepared to deal with any bugs
found in a responsible manner and not shout down any reporters.
The correct model should be a Responsible Disclosure model IMHO
so that VSI get the chance to fix the problems but also so that
any issues found are not swept under the carpet and hidden. This
also means the VMS community can discuss the implications of any
issues found as they relate to the design of VMS.
Likewise I would expect any discovered issues to be assigned CVE
numbers rather than being silently fixed in a patch without
telling the world about the issue. That's the standard for other
products and it should be the standard for VMS as well.
I would suggest a 30 day disclosure target for simple issues to
60 days for more complex issues. If something exposes a complicated
design flaw in VMS (say for example you did something clever to
get to the kernel via RMS) then extending the disclosure period
to 4-6 months would be acceptable but this disclosure period
duration should only be used when justified by the specific issue.
The bug bounty program should only apply to products shipped by
VSI (including any layered products with security implications)
and not to any third party products such as WASD which are
downloaded by the end user.
Just to be clear: I'm not associated with VSI in any way. I just
want to see what the community thinks about this.
Simon.
I'd call it a "contest" with a reward.

Note, I've been here in the past, advocating that there would be a reward for
anyone breaking security on a specific VMS system set up just for such a
contest. Never happened, other than I believe way back when a VMS based ISP in
Chicago set up such.

Your conditions are good, don't want the problems announced before tey can be
addressed and updates put in place.

I would not limit the reporting to strictly VSI products. If something happens
on a VMS system, then it will be known as a VMS bug. For example, for a WASD
problem, VSI could notify Mark, and he could address it.
Simon Clubley
2016-08-15 20:13:35 UTC
Permalink
Post by David Froble
I'd call it a "contest" with a reward.
Note, I've been here in the past, advocating that there would be a reward for
anyone breaking security on a specific VMS system set up just for such a
contest. Never happened, other than I believe way back when a VMS based ISP in
Chicago set up such.
A contest isn't the right of thinking about this as it brings up images
of a one-off event held over a short period of time with a single winner.
A security bug bounty program is a formal ongoing program offered by an
organisation to all the security experts out there.
Post by David Froble
Your conditions are good, don't want the problems announced before tey can be
addressed and updates put in place.
They are part of the standard Responsible Disclosure protocol which
is the protocol I prefer to see used in these matters. It gives the
vendor a defined time interval to address the problem and issue fixes
and also allows the vendor to request an extension if the problem is
proving more difficult to fix than expected.

The details of the exploit are only released after either the vendor
has issued a patch or if the vendor shows no evidence of actually
fixing the problem after multiple warnings.
Post by David Froble
I would not limit the reporting to strictly VSI products. If something happens
on a VMS system, then it will be known as a VMS bug. For example, for a WASD
problem, VSI could notify Mark, and he could address it.
The problem with that is that VSI then becomes a clearing house for
every piece of software that runs on VMS. Also, I don't think that
third party bugs would automatically become known as VMS bugs in
the same way that a bug in a piece of third party software running
on Windows doesn't automatically make it a Windows bug.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2016-08-16 02:06:00 UTC
Permalink
Post by Simon Clubley
Post by David Froble
I'd call it a "contest" with a reward.
Note, I've been here in the past, advocating that there would be a reward for
anyone breaking security on a specific VMS system set up just for such a
contest. Never happened, other than I believe way back when a VMS based ISP in
Chicago set up such.
A contest isn't the right of thinking about this as it brings up images
of a one-off event held over a short period of time with a single winner.
A security bug bounty program is a formal ongoing program offered by an
organisation to all the security experts out there.
Think marketing. Think "wow, no bugs found in VMS". I don't care what it's
called, but, it should be more than just bug reporting. VMS needs exposure,
good exposure.
Post by Simon Clubley
Post by David Froble
Your conditions are good, don't want the problems announced before tey can be
addressed and updates put in place.
They are part of the standard Responsible Disclosure protocol which
is the protocol I prefer to see used in these matters. It gives the
vendor a defined time interval to address the problem and issue fixes
and also allows the vendor to request an extension if the problem is
proving more difficult to fix than expected.
The details of the exploit are only released after either the vendor
has issued a patch or if the vendor shows no evidence of actually
fixing the problem after multiple warnings.
How responsible is it to tell the hackers how to violate systems? I'd op for
never exposing such.
Post by Simon Clubley
Post by David Froble
I would not limit the reporting to strictly VSI products. If something happens
on a VMS system, then it will be known as a VMS bug. For example, for a WASD
problem, VSI could notify Mark, and he could address it.
The problem with that is that VSI then becomes a clearing house for
every piece of software that runs on VMS. Also, I don't think that
third party bugs would automatically become known as VMS bugs in
the same way that a bug in a piece of third party software running
on Windows doesn't automatically make it a Windows bug.
At some point, the system takes the blame. Maybe not from you or me, but the
casual users. It's "the computer".
Simon Clubley
2016-08-16 12:34:09 UTC
Permalink
Post by David Froble
Post by Simon Clubley
Post by David Froble
I'd call it a "contest" with a reward.
Note, I've been here in the past, advocating that there would be a reward for
anyone breaking security on a specific VMS system set up just for such a
contest. Never happened, other than I believe way back when a VMS based ISP in
Chicago set up such.
A contest isn't the right of thinking about this as it brings up images
of a one-off event held over a short period of time with a single winner.
A security bug bounty program is a formal ongoing program offered by an
organisation to all the security experts out there.
Think marketing. Think "wow, no bugs found in VMS". I don't care what it's
called, but, it should be more than just bug reporting. VMS needs exposure,
good exposure.
Once again, this isn't about marketing, it's about reporting bugs in a
responsible way so they can be fixed. Oh, and the no bugs found in VMS
thing was obsolete long ago. The DEFCON researchers found those issues
with very little knowledge of VMS. Imagine what's going to happen when
people with detailed VMS knowledge start looking.

The reality is that when the wider security community start probing VMS
they _are_ going to find bugs and you need a procedure in place to handle
that. A security bug bounty program would also motivate them to directly
report the issues to VSI so they can be fixed before the details are
reported.
Post by David Froble
Post by Simon Clubley
Post by David Froble
Your conditions are good, don't want the problems announced before tey can be
addressed and updates put in place.
They are part of the standard Responsible Disclosure protocol which
is the protocol I prefer to see used in these matters. It gives the
vendor a defined time interval to address the problem and issue fixes
and also allows the vendor to request an extension if the problem is
proving more difficult to fix than expected.
The details of the exploit are only released after either the vendor
has issued a patch or if the vendor shows no evidence of actually
fixing the problem after multiple warnings.
How responsible is it to tell the hackers how to violate systems? I'd op for
never exposing such.
You only tell the hackers _after_ the vendor has released the patches
and disclosure is the standard procedure these days. It forces the
vendors to fix the issues in a timely manner and if the vendor refuses
to fix the issues after several warnings then at least the users of
the products will know exactly what the problem is so they can decide
what they want to do next. That security issue still exists regardless
of whether the end users know about it or not.

Non-disclosure is simply not an option these days as the only thing
it does is to provide a false illusion of security. The other benefit
of disclosure after the patch is released is that it _forces_ the
users to apply the patch rather than allow themselves to be deluded
into thinking that they can safely put off applying the patch.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2016-08-16 14:22:32 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
Post by David Froble
I'd call it a "contest" with a reward.
Note, I've been here in the past, advocating that there would be a reward for
anyone breaking security on a specific VMS system set up just for such a
contest. Never happened, other than I believe way back when a VMS based ISP in
Chicago set up such.
A contest isn't the right of thinking about this as it brings up images
of a one-off event held over a short period of time with a single winner.
A security bug bounty program is a formal ongoing program offered by an
organisation to all the security experts out there.
Think marketing. Think "wow, no bugs found in VMS". I don't care what it's
called, but, it should be more than just bug reporting. VMS needs exposure,
good exposure.
Once again, this isn't about marketing, it's about reporting bugs in a
responsible way so they can be fixed. Oh, and the no bugs found in VMS
thing was obsolete long ago. The DEFCON researchers found those issues
with very little knowledge of VMS. Imagine what's going to happen when
people with detailed VMS knowledge start looking.
The reality is that when the wider security community start probing VMS
they _are_ going to find bugs and you need a procedure in place to handle
that. A security bug bounty program would also motivate them to directly
report the issues to VSI so they can be fixed before the details are
reported.
Post by David Froble
Post by Simon Clubley
Post by David Froble
Your conditions are good, don't want the problems announced before tey can be
addressed and updates put in place.
They are part of the standard Responsible Disclosure protocol which
is the protocol I prefer to see used in these matters. It gives the
vendor a defined time interval to address the problem and issue fixes
and also allows the vendor to request an extension if the problem is
proving more difficult to fix than expected.
The details of the exploit are only released after either the vendor
has issued a patch or if the vendor shows no evidence of actually
fixing the problem after multiple warnings.
How responsible is it to tell the hackers how to violate systems? I'd op for
never exposing such.
You only tell the hackers _after_ the vendor has released the patches
and disclosure is the standard procedure these days. It forces the
vendors to fix the issues in a timely manner and if the vendor refuses
to fix the issues after several warnings then at least the users of
the products will know exactly what the problem is so they can decide
what they want to do next. That security issue still exists regardless
of whether the end users know about it or not.
Non-disclosure is simply not an option these days as the only thing
it does is to provide a false illusion of security. The other benefit
of disclosure after the patch is released is that it _forces_ the
users to apply the patch rather than allow themselves to be deluded
into thinking that they can safely put off applying the patch.
Simon.
Ok, last post on this topic, as it appears we will not find agreement.

In the situation where a vendor can not, or will not, correct a problem,
customers still may not be affected if nobody else ever finds the problem. Not
saying this is optimum. By publishing the problem and how to use it, you are
enabling the bad guys to do harm to some vulnerable systems. In doing so, I'd
maintain that you're an accomplice, and criminally liable. If I was the victim,
in addition to filing criminal charges, I'm pretty sure my lawyers would be
going after you in a civil case also. Just the way I see it ....
Simon Clubley
2016-08-16 18:14:23 UTC
Permalink
Post by David Froble
Post by Simon Clubley
You only tell the hackers _after_ the vendor has released the patches
and disclosure is the standard procedure these days. It forces the
vendors to fix the issues in a timely manner and if the vendor refuses
to fix the issues after several warnings then at least the users of
the products will know exactly what the problem is so they can decide
what they want to do next. That security issue still exists regardless
of whether the end users know about it or not.
Non-disclosure is simply not an option these days as the only thing
it does is to provide a false illusion of security. The other benefit
of disclosure after the patch is released is that it _forces_ the
users to apply the patch rather than allow themselves to be deluded
into thinking that they can safely put off applying the patch.
Ok, last post on this topic, as it appears we will not find agreement.
In the situation where a vendor can not, or will not, correct a problem,
customers still may not be affected if nobody else ever finds the problem. Not
saying this is optimum. By publishing the problem and how to use it, you are
enabling the bad guys to do harm to some vulnerable systems. In doing so, I'd
maintain that you're an accomplice, and criminally liable. If I was the victim,
in addition to filing criminal charges, I'm pretty sure my lawyers would be
going after you in a civil case also. Just the way I see it ....
Congratulations David. You have just demonstrated far better than
I ever could just how far out of touch you are with the realities
of the security environment as it exists today.

Did it ever occur to you that finding a specific bug is not some
kind of exclusive situation and that multiple people can, and do,
find the same bug ? The difference is that while one of those
people might be doing the responsible disclosure thing with the
vendor, someone else might be exploiting the bug for their own
benefit.

By forcing the vendor to fix the problem in a timely manner you
also stop any other people from exploiting the same vulnerability.
Furthermore, if the vendor refuses to fix the issue, then making
end users aware of the situation by providing proof allows them
to implement workarounds which also will stop an attacker.

As for the criminal liability threats, I'm going to be a lot more
diplomatic here than I should be in deference to the fact that you
are clearly clueless about the implications of what you are saying.

Some vendors have indeed attempted to sue security researchers for
disclosing security vulnerabilities and the results have usually
been a disaster for the vendor in terms of the publicity that
resulted.

If HP or VSI sued a researcher for disclosing a VMS vulnerability,
especially a researcher which followed the responsible disclosure
protocols, it would be an absolutely brain dead idiotic decision
of unbelievable proportions and not just because of the immediate
PR disaster.

For one thing, if someone was stupid enough to do that, then the
next VMS security bugs to be disclosed would probably show up on
one of the full disclosure mailing lists anonymously along with
a note saying that the person wanted to work with the vendor using
the responsible disclosure approach but the last time that was
tried the vendor sued the researcher who reported the issue.

The end result would be a VMS security issue out in the wild and
without HP or VSI having the chance to first fix it so I really
hope that no-one would be stupid enough to sue a researcher for
following what are the industry standard responsible disclosure
protocols.

Security researchers are the good people here, they are not liable
for the vendor's failings, and if VMS wants to play in today's world
then it needs to follow today's rules because those rules exist for
a good reason.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
j***@yahoo.co.uk
2016-08-16 19:19:41 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
You only tell the hackers _after_ the vendor has released the patches
and disclosure is the standard procedure these days. It forces the
vendors to fix the issues in a timely manner and if the vendor refuses
to fix the issues after several warnings then at least the users of
the products will know exactly what the problem is so they can decide
what they want to do next. That security issue still exists regardless
of whether the end users know about it or not.
Non-disclosure is simply not an option these days as the only thing
it does is to provide a false illusion of security. The other benefit
of disclosure after the patch is released is that it _forces_ the
users to apply the patch rather than allow themselves to be deluded
into thinking that they can safely put off applying the patch.
Ok, last post on this topic, as it appears we will not find agreement.
In the situation where a vendor can not, or will not, correct a problem,
customers still may not be affected if nobody else ever finds the problem. Not
saying this is optimum. By publishing the problem and how to use it, you are
enabling the bad guys to do harm to some vulnerable systems. In doing so, I'd
maintain that you're an accomplice, and criminally liable. If I was the victim,
in addition to filing criminal charges, I'm pretty sure my lawyers would be
going after you in a civil case also. Just the way I see it ....
Congratulations David. You have just demonstrated far better than
I ever could just how far out of touch you are with the realities
of the security environment as it exists today.
Did it ever occur to you that finding a specific bug is not some
kind of exclusive situation and that multiple people can, and do,
find the same bug ? The difference is that while one of those
people might be doing the responsible disclosure thing with the
vendor, someone else might be exploiting the bug for their own
benefit.
By forcing the vendor to fix the problem in a timely manner you
also stop any other people from exploiting the same vulnerability.
Furthermore, if the vendor refuses to fix the issue, then making
end users aware of the situation by providing proof allows them
to implement workarounds which also will stop an attacker.
As for the criminal liability threats, I'm going to be a lot more
diplomatic here than I should be in deference to the fact that you
are clearly clueless about the implications of what you are saying.
Some vendors have indeed attempted to sue security researchers for
disclosing security vulnerabilities and the results have usually
been a disaster for the vendor in terms of the publicity that
resulted.
If HP or VSI sued a researcher for disclosing a VMS vulnerability,
especially a researcher which followed the responsible disclosure
protocols, it would be an absolutely brain dead idiotic decision
of unbelievable proportions and not just because of the immediate
PR disaster.
For one thing, if someone was stupid enough to do that, then the
next VMS security bugs to be disclosed would probably show up on
one of the full disclosure mailing lists anonymously along with
a note saying that the person wanted to work with the vendor using
the responsible disclosure approach but the last time that was
tried the vendor sued the researcher who reported the issue.
The end result would be a VMS security issue out in the wild and
without HP or VSI having the chance to first fix it so I really
hope that no-one would be stupid enough to sue a researcher for
following what are the industry standard responsible disclosure
protocols.
Security researchers are the good people here, they are not liable
for the vendor's failings, and if VMS wants to play in today's world
then it needs to follow today's rules because those rules exist for
a good reason.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Agree with that, except one word was perhaps missing:
*Proper* security researchers are the good people here.

There are lots of people calling themselves security researchers
whose primary goal appears to be to get themselves or their
organisation media coverage for stuff which is neither here nor
there, e.g. something reported some years earlier, repackaged
slightly differently to get a few more column inches and page
views). Or something which is marginally interesting but of
little real world significance (such as keylogging by allegedly
monitoring the RFI from a PC/laptop power supply, see e.g.
http://news.bbc.co.uk/1/hi/technology/8147534.stm).
Craig A. Berry
2016-08-16 20:38:35 UTC
Permalink
Post by Simon Clubley
Congratulations David. You have just demonstrated far better than
I ever could just how far out of touch you are with the realities
of the security environment as it exists today.
You're a hero, Simon. Unfortunately the VP of Engineering at VSI is not particularly more in touch with The Real World than is David:

<http://blog.ecubesystems.com/eddie-orcutt-interview/>

wherein he says ridiculous things like that VMS is 81 times less vulnerable to breaches than commodity operating systems because there have been 81 times fewer security vulnerabilities reported against it in its 39-year history, and even seems to think that infrequent patching is a competitive advantage of VMS.

I know the engineers know better, but if that's the official word, it's not very encouraging for seeing VSI get on board with modern security practices.

If folks think the lack of CVEs makes their VMS systems secure, consider NTP. The link date for the latest SYS$SYSTEM:TCPIP$NTPD.EXE available from HPE with TCP/IP Services 5.7 ECO 5 is 8-NOV-2014. I count 14 CVEs against NTP since then:

<https://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html>

I have no idea how many of those pose a danger on VMS, but is anyone even checking?
Stephen Hoffman
2016-08-17 12:54:28 UTC
Permalink
Post by Craig A. Berry
I know the engineers know better, but if that's the official word, it's
not very encouraging for seeing VSI get on board with modern security
practices.
It'd be encouraging to see VSI move toward more modern approaches here,
with the implementation and with the associated practices and with the
tools.
Post by Craig A. Berry
If folks think the lack of CVEs makes their VMS systems secure,
consider NTP. ...
I have no idea how many of those pose a danger on VMS, but is anyone even checking?
Ayup. Without going into details, this area is a problem.

Marketing on bug counts usually comes around and bites you, too.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2016-08-16 23:28:44 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
You only tell the hackers _after_ the vendor has released the patches
and disclosure is the standard procedure these days. It forces the
vendors to fix the issues in a timely manner and if the vendor refuses
to fix the issues after several warnings then at least the users of
the products will know exactly what the problem is so they can decide
what they want to do next. That security issue still exists regardless
of whether the end users know about it or not.
Non-disclosure is simply not an option these days as the only thing
it does is to provide a false illusion of security. The other benefit
of disclosure after the patch is released is that it _forces_ the
users to apply the patch rather than allow themselves to be deluded
into thinking that they can safely put off applying the patch.
Ok, last post on this topic, as it appears we will not find agreement.
Guess I lied ...
Post by Simon Clubley
Post by David Froble
In the situation where a vendor can not, or will not, correct a problem,
customers still may not be affected if nobody else ever finds the problem. Not
saying this is optimum. By publishing the problem and how to use it, you are
enabling the bad guys to do harm to some vulnerable systems. In doing so, I'd
maintain that you're an accomplice, and criminally liable. If I was the victim,
in addition to filing criminal charges, I'm pretty sure my lawyers would be
going after you in a civil case also. Just the way I see it ....
Congratulations David. You have just demonstrated far better than
I ever could just how far out of touch you are with the realities
of the security environment as it exists today.
Reality is what actually happens ..
Post by Simon Clubley
Did it ever occur to you that finding a specific bug is not some
kind of exclusive situation and that multiple people can, and do,
find the same bug ? The difference is that while one of those
people might be doing the responsible disclosure thing with the
vendor, someone else might be exploiting the bug for their own
benefit.
By forcing the vendor to fix the problem in a timely manner you
also stop any other people from exploiting the same vulnerability.
Furthermore, if the vendor refuses to fix the issue, then making
end users aware of the situation by providing proof allows them
to implement workarounds which also will stop an attacker.
As for the criminal liability threats, I'm going to be a lot more
diplomatic here than I should be in deference to the fact that you
are clearly clueless about the implications of what you are saying.
I don't think I'm as clueless as you claim ...
Post by Simon Clubley
Some vendors have indeed attempted to sue security researchers for
disclosing security vulnerabilities and the results have usually
been a disaster for the vendor in terms of the publicity that
resulted.
And I'd agree with this ...
Post by Simon Clubley
If HP or VSI sued a researcher for disclosing a VMS vulnerability,
especially a researcher which followed the responsible disclosure
protocols, it would be an absolutely brain dead idiotic decision
of unbelievable proportions and not just because of the immediate
PR disaster.
I never mentioned VSI, vendors, researchers, or such. What I mentioned was "if
I was the victim". Much different.
Post by Simon Clubley
For one thing, if someone was stupid enough to do that, then the
next VMS security bugs to be disclosed would probably show up on
one of the full disclosure mailing lists anonymously along with
a note saying that the person wanted to work with the vendor using
the responsible disclosure approach but the last time that was
tried the vendor sued the researcher who reported the issue.
The end result would be a VMS security issue out in the wild and
without HP or VSI having the chance to first fix it so I really
hope that no-one would be stupid enough to sue a researcher for
following what are the industry standard responsible disclosure
protocols.
Security researchers are the good people here, they are not liable
for the vendor's failings, and if VMS wants to play in today's world
then it needs to follow today's rules because those rules exist for
a good reason.
You are totally missing the point. What I wrote was that I'd consider it wrong
to publicize some problem, knowing that it would enable some naferious types to
potentially harm someone. In some locals that would allow the victim to go
after you for being an accessory.

Depending on how deep your pockets are, I know a bunch of lawyers who'd droll at
such a case ....
Simon Clubley
2016-08-17 13:08:47 UTC
Permalink
Post by David Froble
Post by Simon Clubley
For one thing, if someone was stupid enough to do that, then the
next VMS security bugs to be disclosed would probably show up on
one of the full disclosure mailing lists anonymously along with
a note saying that the person wanted to work with the vendor using
the responsible disclosure approach but the last time that was
tried the vendor sued the researcher who reported the issue.
The end result would be a VMS security issue out in the wild and
without HP or VSI having the chance to first fix it so I really
hope that no-one would be stupid enough to sue a researcher for
following what are the industry standard responsible disclosure
protocols.
Security researchers are the good people here, they are not liable
for the vendor's failings, and if VMS wants to play in today's world
then it needs to follow today's rules because those rules exist for
a good reason.
You are totally missing the point. What I wrote was that I'd consider it wrong
to publicize some problem, knowing that it would enable some naferious types to
potentially harm someone. In some locals that would allow the victim to go
after you for being an accessory.
You are correct David, I did misunderstand you.

I now see that what you _actually_ said is even more insane and out of
touch than what I _thought_ you said. My apologies for the misunderstanding.

So what you are saying is that in your world, a vendor's customer could
go after the security researcher for publishing the details of a problem
instead of going after the vendor for failing to fix the problem and
effectively abandoning the product even though the security researcher
gave the vendor plenty of opportunity to first fix the problem.

The implication I see here is that you think researchers should keep
quiet about vulnerabilities if they cannot get the vendor to fix the
problem.

Let's explore that a bit further.

First, assume the responsible disclosure process worked and the vendor
successfully released a patch before the researcher provided details
of how the exploit works. Do you think the researcher should still be
prosecuted or sued for then releasing details of how the exploit works ?

However, even if a detailed report of the vulnerability is not made
available, then in the case of a patch that's sufficiently serious, some
people will spend the effort analysing the patch to determine what was
fixed, so by publishing the patch the vendor is allowing a sufficiently
determined attacker to find out what the original vulnerability was.

Now assume that someone reports a VMS IA64 issue to VSI which turns out
to be a cross-platform vulnerability so that the exploit works on VAX,
Alpha and IA64. VAX is not receiving new patches and (IIRC) neither will
Alpha after the end of this year.

This means that by fixing this cross-platform issue in IA64 VMS, VSI
would be telling a sufficiently motivated attacker exactly how to
compromise the Alpha and VAX systems out there. In your world, VSI
would either (1) not fix the IA64 problem or (2) would become liable
to VAX or Alpha customers because they provided a patch which told
attackers how to compromise those VAX/Alpha systems.

I hope you see how insane that idea is. Once again, security researchers
are not liable for the failings of vendors.

Oh, and the day a VMS customer tried to sue a security researcher would
be the day that VMS security would fall to pieces because any new VMS
security issues would likely be released anonymously without giving
VSI a chance to first fix the problem because the researcher would
have no other choice.

Also, VSI might as well close up shop if that happened because such an
action would seriously taint the VMS ecosystem and switch off any
possible newcomers to VMS as the idea a VMS customer could sue
researchers is so completely alien to the way things are done. Those
potential new customers (with experience of the outside world) would
see the damage caused to VMS by a suing customer and probably decide
that they didn't want to be a part of that VMS world.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bob Gezelter
2016-08-17 13:39:43 UTC
Permalink
As I noted in an earlier post, there are really two separate questions:

- A "bug bounty" program, where there is a reward system for new bugs

- A documented way to advise VSI of an OpenVMS/OpenVMS layered product vulnerability

That said, the example of the OpenSSL Heartbleed bug is instructive. Heartbleed affected every system using the OpenSSL package. It opened the potential to compromise internal web server data, including private keys. The vulnerability was front page news in both the trade and general press. A patch to circumvent the vulnerability was quickly available.

Yet a month after the publicity storm (May 2014), close to a million web servers remained unpatched. I have not seen more recent numbers, but suspect that they are equally, if not more, depressing.

It has been debated ad nauseum in non-OS specific fora about the dangers of disclosing/non-disclosing vulnerabilities. While one can argue that it is regrettable, the consensus is that not disclosing vulnerabilities provides cover for vendors ignoring corrective action (e.g., without looming disclosure, far too many managements fail to take corrective action).

OpenVMS management and line engineering have always taken security vulnerabilities seriously. However, the question is customer perception (and more importantly, customer managements' perception). It is important that there exist an identified portal (e.g., TLS-secured www page; email address with corresponding PGP key; attention marking for conventional post/delivery service) to receive vulnerability related information.

Similarly, CVEs reported on Open Source components need to be promptly recognized and remedial action taken.

- Bob Gezelter, http://www.rlgsc.com
Simon Clubley
2016-08-19 22:57:13 UTC
Permalink
I agree with that.
Post by Bob Gezelter
- A "bug bounty" program, where there is a reward system for new bugs
How important the bug bounty program is to someone depends on that
person. For myself it wouldn't really be a major factor as I would
report any issues found anyway. For others however, it could be the
motivation required for VSI to find out about a major bug in their
products in a controlled manner instead of finding out the hard way
when it becomes general knowledge. Certainly the bug bounty program
concept is growing so it's clearly seen as a good thing overall.

I wonder if the people within VSI have had a proper discussion of
this even once since they were setup ?
Post by Bob Gezelter
- A documented way to advise VSI of an OpenVMS/OpenVMS layered
product vulnerability
There are some areas in which VSI have really dropped the ball and this
is one of them. (The other big one BTW, is the lack of push style
communication with the VMS community where VSI push information to
the community instead of waiting for the community to come and get
it from them. I think it's probably past time for another comp.os.vms
posting from VSI with a status update of where they are with the port.)

These are the kinds of things which don't cost a lot to setup or run,
but they do make all the difference to how professional a vendor is
perceived to be, especially in today's environment. The common theme
here is one of engaging with the community which VSI are not doing as
well as they should be.

Not having a formal public security reporting mechanism which everyone
can use is crazy given how trivally easy such a mechanism is to setup
and given how expected such a mechanism is for an OS vendor.
Post by Bob Gezelter
That said, the example of the OpenSSL Heartbleed bug is
instructive. Heartbleed affected every system using the OpenSSL
package. It opened the potential to compromise internal web server
data, including private keys. The vulnerability was front page news in
both the trade and general press. A patch to circumvent the
vulnerability was quickly available.
Yet a month after the publicity storm (May 2014), close to a million
web servers remained unpatched. I have not seen more recent numbers,
but suspect that they are equally, if not more, depressing.
I saw a later followup and while I don't now remember the figure I do
remember being amazed at how high the figure still was at that time.
Post by Bob Gezelter
It has been debated ad nauseum in non-OS specific fora about the
dangers of disclosing/non-disclosing vulnerabilities. While one can
argue that it is regrettable, the consensus is that not disclosing
vulnerabilities provides cover for vendors ignoring corrective action
(e.g., without looming disclosure, far too many managements fail to
take corrective action).
I have supported responsible disclosure for a long time now. As well
as forcing the vendor to act, it also has another major advantage in
that other researchers can look at the original researcher's work and
identify areas or related concepts to examine that the original
researcher might have overlooked. This can lead to more security
issues being found and fixed and produces a far more robust product in
the longer term.
Post by Bob Gezelter
OpenVMS management and line engineering have always taken security
vulnerabilities seriously. However, the question is customer
perception (and more importantly, customer managements'
perception). It is important that there exist an identified portal
(e.g., TLS-secured www page; email address with corresponding PGP key;
attention marking for conventional post/delivery service) to receive
vulnerability related information.
There is a complacency in some parts of the VMS world that the security
reporting protocols and problems that other OS vendors have to deal
with don't really apply to VMS. Certainly, there are lower numbers of
bugs publicly reported in the VMS world but I wonder what combination
of possibilities from the following list are the cause of that:

1) VMS may simply have been designed and implemented to a higher standard,

2) VMS requires custom hardware to run on so there's been less
researchers interested in looking at VMS security than the commodity
operating systems,

3) Kerry mentioned that VMS was actively probed in it's heyday and he
was right but you can't do as much testing on an expensive production
system as you can on that PC you own in your house/office,

Personally, I think it's a combination of all three and if 2) and 3)
are indeed significant factors (and my feeling is that they are)
then all that may change with x86-64 because those security
researchers will now be able to run VMS on their existing hardware
and will be able to apply their techniques gained from probing other
operating systems.

People should also keep in mind that these security failures found
on x86-64 could be common mode failures that apply equally well to
those old VAXes and Alphas sat somewhere in the corner of your
organisation.

If that old VAX or Alpha suddenly had a big security hole revealed for
which no patch would be produced, would you be able to handle the
situation or would you have a crisis on your hands ? When you decided
to continue running that old VAX/Alpha system out of software support
did you perhaps even not bother considering this because "that's not
something VMS people have to worry about" ?

You may be lucky and find the number of issues reported may not change
because it turned out, even with VMS on x86-64, the security researchers
are no longer interested in learning and probing VMS or you may find
(especially if VSI launch a x86-64 hobbyist program that turns out to
be of interest to the researchers) new VMS security issues being revealed
that might affect you.

To the people in this situation, while you are privately hoping for the
former, think about what you would do if the latter becomes reality and
the bugs discovered start affecting your old systems. What would you do ?
Post by Bob Gezelter
Similarly, CVEs reported on Open Source components need to be
promptly recognized and remedial action taken.
Both HP and VSI need to be actively tracking this stuff and releasing
patches on similar timescales to other OS vendors IMHO.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
IanD
2016-08-21 13:23:59 UTC
Permalink
On Saturday, August 20, 2016 at 8:57:14 AM UTC+10, Simon Clubley wrote:

<snip>
...The other big one BTW, is the lack of push style
communication with the VMS community where VSI push information to
the community instead of waiting for the community to come and get
it from them. I think it's probably past time for another comp.os.vms
posting from VSI with a status update of where they are with the port.)
These are the kinds of things which don't cost a lot to setup or run,
but they do make all the difference to how professional a vendor is
perceived to be, especially in today's environment. The common theme
here is one of engaging with the community which VSI are not doing as
well as they should be.
I gave up asking :-(

I also check with less frequency the VSI website. It seems the updates come around the 3 months mark but that typically follows nag type post about 'What's happening VSI' from the public - the opposite as to what should be happening

I feel like someone who's always badgering about why there is no information flow and it always seems to get answered by the same person or couple of people from VSI who frequent here and I feel like they are wearing the mantle for what should be coming from the company overall (sorry guys, you know who you are, my whinging about lack of updates certainly isn't directed towards yourselves personally, in ANY way)

We are at the 2 1/2 month mark without a formal update. Sure, if 3 month updates is what is going to be normal then it should be stated as such so as to set the expectation

Yes, the conference is coming and I'm sure all the goodies are being saved to release there but not all of us are going so a few crumbs of information would still be nice for the rest of us :-)

I'm left to hoping that Hoff once again gives a great brief about what happens at the conference...
Not having a formal public security reporting mechanism which everyone
can use is crazy given how trivally easy such a mechanism is to setup
and given how expected such a mechanism is for an OS vendor.
<snip>
There is a complacency in some parts of the VMS world that the security
reporting protocols and problems that other OS vendors have to deal
with don't really apply to VMS. Certainly, there are lower numbers of
bugs publicly reported in the VMS world but I wonder what combination
1) VMS may simply have been designed and implemented to a higher standard,
2) VMS requires custom hardware to run on so there's been less
researchers interested in looking at VMS security than the commodity
operating systems,
3) Kerry mentioned that VMS was actively probed in it's heyday and he
was right but you can't do as much testing on an expensive production
system as you can on that PC you own in your house/office,
Personally, I think it's a combination of all three and if 2) and 3)
are indeed significant factors (and my feeling is that they are)
then all that may change with x86-64 because those security
researchers will now be able to run VMS on their existing hardware
and will be able to apply their techniques gained from probing other
operating systems.
Better to have a formal process for bug-reporting and security patching BEFORE OpenVMS exists on easy to access hardware

Last thing we want in our journey to revamp OpenVMS is to have script kiddies publishing on social media OpenVMS hacks!

<snip>
Post by Bob Gezelter
Similarly, CVEs reported on Open Source components need to be
promptly recognized and remedial action taken.
Where I am, linux is now under a much tighter patching regime than it used to be. It's not just security patching either, there is a renewed focus to keep things up to date as possible because a slip quickly becomes worldwide fodder that your competitor to throw around endlessly

A company only receives a fraction of a public bollocking if it falls to a new hack versus never having patched an insisting one - customers get mighty pissed of with a company behaving lackadaisically
Both HP and VSI need to be actively tracking this stuff and releasing
patches on similar timescales to other OS vendors IMHO.
<snip>

Yep!
c***@gmail.com
2016-08-21 19:43:40 UTC
Permalink
I thought we have stated this many times by now but maybe not. We put up an updated Roadmap every three months. The next one will be the first week in September. Actually getting it up on the website is not my job but I am responsible for its content so if you have any questions do not hesitate to ask.

An updated State of the Port will also appear at that time. I apologize for not getting one done in June but I'm already working on the one for September.

Clair
IanD
2016-08-21 21:59:12 UTC
Permalink
Post by c***@gmail.com
I thought we have stated this many times by now but maybe not.
We put up an updated Roadmap every three months. The next one will be the first week in September.
Roadmap yes, other items, no
Post by c***@gmail.com
Actually getting it up on the website is not my job but I am responsible for its content so if you have any questions do not hesitate to ask.
There-in lays the issue. You already answering items on this forum as does John and from a community aspect, quite frankly it appear at times that you two are the only VSI people out there! (sorry if I missed any other VSI rep.)
Post by c***@gmail.com
An updated State of the Port will also appear at that time. I apologize for not getting one done in June but I'm already working on the one for September.
Clair
No need to apologize at all, I for one don't expect you to be doing everything and the fact that you frequent here is great and already probably takes enough of your time as it is.

Is there an email address we can hit perhaps where people can send their feedback on the lack of regular content appearing on VSI's homepage / update section? People post here because a forum is a visible entity to others. email addresses are big black holes unfortunately which is probably why people gravitate to posting here instead.

If it's going to take community feedback to prompt VSI management to pay attention to the need for all information flow to be more regular then we need to push for that - your just the point we tend to reference because you actually take the time to show your face and respond!!!
Craig A. Berry
2016-08-21 22:29:21 UTC
Permalink
Post by IanD
There-in lays the issue. You already answering items on this forum
asdoes John and from a community aspect, quite frankly it appear at times
that you two are the only VSI people out there! (sorry if I missed any
other VSI rep.)
You've apparently not noticed when Rob Brooks, Doug Gordon, Camiel
Vanderhoeven, and Paul Anderson have posted here. Possibly Brett
Cameron, though I may have seen him in a different forum. And probably
others that *I* haven't noticed. That said, listening to and patiently
engaging all the back seat drivers may not be something everyone at VSI
has the time or temperament to deal with.
Post by IanD
Is there an email address we can hit perhaps where people can send
their feedback on the lack of regular content appearing on VSI's
homepage / update section?
You could consider writing Sue Skonetski at the obvious address and
asking why you haven't been receiving the VSI newsletter. Could it be
that you haven't signed up for it?
c***@gmail.com
2016-08-22 00:31:03 UTC
Permalink
For technical stuff - ***@vmssoftware.com

For other stuff - ***@vmssoftware.com

Fire away.....
c***@gmail.com
2016-08-22 11:33:38 UTC
Permalink
Post by c***@gmail.com
Fire away.....
And one more thing.....

RE: "Yes, the conference is coming and I'm sure all the goodies are being saved to release there ....."

We don't "save any goodies" for Boot Camp. We do the best we can to out together a few presentations we think will be informative without taking too much time away from development work. Things of major importance should happen on the website or in press releases. Sometimes they coincide with Boot Camp which makes it convenient for us.

BTW: I completely agree with the observations about our lack of communication. No one questions the importance but In two years we have not figured out how to do more. Getting to where we are now has been a real struggle. We are very aware we have a ton of shortcomings and wish we could be doing more.
Simon Clubley
2016-08-22 13:00:28 UTC
Permalink
Post by c***@gmail.com
BTW: I completely agree with the observations about our lack of
communication. No one questions the importance but In two years we have not
figured out how to do more. Getting to where we are now has been a real
struggle. We are very aware we have a ton of shortcomings and wish we could be
doing more.
I've sent email to Sue covering the areas we have discussed here.

I've also added this suggestion which I haven't mentioned here yet:

|One specific suggestion I have is that you do a monthly reminder
|notice in comp.os.vms. It doesn't have to be long; just something
|which says there's a VSI newsletter you can subscribe to, and links to
|your online presence. Clair has said that he tries to do a state of
|the port update every 3 months, so putting when the next expected
|update is due into the the monthly posting would help as well.
|
|I think it's little things like that which make all the difference.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
j***@yahoo.co.uk
2016-08-22 11:27:37 UTC
Permalink
Post by Craig A. Berry
Post by IanD
There-in lays the issue. You already answering items on this forum
asdoes John and from a community aspect, quite frankly it appear at times
that you two are the only VSI people out there! (sorry if I missed any
other VSI rep.)
You've apparently not noticed when Rob Brooks, Doug Gordon, Camiel
Vanderhoeven, and Paul Anderson have posted here. Possibly Brett
Cameron, though I may have seen him in a different forum. And probably
others that *I* haven't noticed. That said, listening to and patiently
engaging all the back seat drivers may not be something everyone at VSI
has the time or temperament to deal with.
Post by IanD
Is there an email address we can hit perhaps where people can send
their feedback on the lack of regular content appearing on VSI's
homepage / update section?
You could consider writing Sue Skonetski at the obvious address and
asking why you haven't been receiving the VSI newsletter. Could it be
that you haven't signed up for it?
Is this VSI newsletter available on the web anywhere for reference,
for use by people who haven't signed up? If it is available. it's
not obvious to me right now where I should find it, and the obvious
searches don't find it either.

It presumably isn't either of the two listed under Updates on the
VSI wesbsite? ie the Business Update (last issue: March 2016) or
the Engineering Update (last issue: June 2016).

Sue's VMS$UPDATE (last issue: June 2016) is available via the VSI
Facebook page (though FB without an FB account is a user interface
nightmare) but as described by Sue it's not the official "VSI
newsletter".

Communicating formally and informally with previous, existing,
and potential customers should be part of someone's core job
description at VSI. It shouldn't be somebody's 'spare time' side
project (nb for clarity, contributions from engineering
folks, Sue, etc, here and elsewhere are very welcome).
Craig A. Berry
2016-08-22 12:09:15 UTC
Permalink
Post by j***@yahoo.co.uk
Post by Craig A. Berry
You could consider writing Sue Skonetski at the obvious address and
asking why you haven't been receiving the VSI newsletter. Could it be
that you haven't signed up for it?
Is this VSI newsletter available on the web anywhere for reference,
for use by people who haven't signed up? If it is available. it's
not obvious to me right now where I should find it, and the obvious
searches don't find it either.
It presumably isn't either of the two listed under Updates on the
VSI wesbsite? ie the Business Update (last issue: March 2016) or
the Engineering Update (last issue: June 2016).
Sue's VMS$UPDATE (last issue: June 2016) is available via the VSI
Facebook page (though FB without an FB account is a user interface
nightmare) but as described by Sue it's not the official "VSI
newsletter".
You clearly know more about it than I do. While it doesn't seem to
appear every month, it does seem to appear more often than the quarterly
updates and might be of interest to someone who feels those aren't
frequent enough.
Post by j***@yahoo.co.uk
Communicating formally and informally with previous, existing,
and potential customers should be part of someone's core job
description at VSI. It shouldn't be somebody's 'spare time' side
project (nb for clarity, contributions from engineering
folks, Sue, etc, here and elsewhere are very welcome).
I didn't realize it was a side project for Sue. Yes, there are a lot of
things about the VSI web site and official communication that could
stand improvement, but the informal communication is as good (probably
better) than it's ever been.
j***@yahoo.co.uk
2016-08-22 12:22:16 UTC
Permalink
Post by Craig A. Berry
Post by j***@yahoo.co.uk
Post by Craig A. Berry
You could consider writing Sue Skonetski at the obvious address and
asking why you haven't been receiving the VSI newsletter. Could it be
that you haven't signed up for it?
Is this VSI newsletter available on the web anywhere for reference,
for use by people who haven't signed up? If it is available. it's
not obvious to me right now where I should find it, and the obvious
searches don't find it either.
It presumably isn't either of the two listed under Updates on the
VSI wesbsite? ie the Business Update (last issue: March 2016) or
the Engineering Update (last issue: June 2016).
Sue's VMS$UPDATE (last issue: June 2016) is available via the VSI
Facebook page (though FB without an FB account is a user interface
nightmare) but as described by Sue it's not the official "VSI
newsletter".
You clearly know more about it than I do. While it doesn't seem to
appear every month, it does seem to appear more often than the quarterly
updates and might be of interest to someone who feels those aren't
frequent enough.
Post by j***@yahoo.co.uk
Communicating formally and informally with previous, existing,
and potential customers should be part of someone's core job
description at VSI. It shouldn't be somebody's 'spare time' side
project (nb for clarity, contributions from engineering
folks, Sue, etc, here and elsewhere are very welcome).
I didn't realize it was a side project for Sue. Yes, there are a lot of
things about the VSI web site and official communication that could
stand improvement, but the informal communication is as good (probably
better) than it's ever been.
Indeed, customer communication (formal or informal) has probably
*never* been a side project for Sue :)

But then she says on Facebook that VMS$UPDATE isn't the official
VSI Newsletter. So is anybody responsible for the official VSI
Newsletter (wherever it may be), and if it's a side project for
them, maybe some adjustment is needed somewhere?

Why can't people just do everything immediately to the expected
quality and with zero budget.
Simon Clubley
2016-08-22 13:11:38 UTC
Permalink
Post by IanD
Better to have a formal process for bug-reporting and security patching
BEFORE OpenVMS exists on easy to access hardware
I've just emailed my security bug reporting suggestion to VSI.
Post by IanD
Last thing we want in our journey to revamp OpenVMS is to have script kiddies
publishing on social media OpenVMS hacks!
You need to work on the assumption that this information will be published
in the same way as it is for all the other operating systems out there.

What we are looking for is responsible disclosure (ie: reporting the
exploit details _after_ VSI has a patch ready) instead of full
disclosure (which is reporting the details before VSI has been given
an opportunity to produce a patch).

As such VSI need to have a secure and easy to access way that allows
security researchers and the general VMS community to tell VSI about
security issues in VMS.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
j***@yahoo.co.uk
2016-08-23 10:12:20 UTC
Permalink
Post by Simon Clubley
Post by IanD
Better to have a formal process for bug-reporting and security patching
BEFORE OpenVMS exists on easy to access hardware
I've just emailed my security bug reporting suggestion to VSI.
Post by IanD
Last thing we want in our journey to revamp OpenVMS is to have script kiddies
publishing on social media OpenVMS hacks!
You need to work on the assumption that this information will be published
in the same way as it is for all the other operating systems out there.
What we are looking for is responsible disclosure (ie: reporting the
exploit details _after_ VSI has a patch ready) instead of full
disclosure (which is reporting the details before VSI has been given
an opportunity to produce a patch).
As such VSI need to have a secure and easy to access way that allows
security researchers and the general VMS community to tell VSI about
security issues in VMS.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
As a point of comparison, what do the HPE NonStop people do about
reporting security isses (to and from HPE)?

Here's a recent hint:
https://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c05240731
"Multiple potential remote and local vulnerabilities impacting
Perl and PHP have been addressed by HPE NonStop Servers OSS
Script Languages. The vulnerabilities include Perl's
opportunistic loading of optional modules which might allow
local users to gain elevation of privilege via a Trojan horse
library under the current working directory."

And here's the generic HPE Security Issue Reporting link
(includes OpenVMS):
https://www.hpe.com/info/report-security-vulnerability

So the first line stuff is in place at HPE. What happens
after that is doubtless another story.
Craig A. Berry
2016-08-24 02:07:04 UTC
Permalink
Post by j***@yahoo.co.uk
https://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c05240731
"Multiple potential remote and local vulnerabilities impacting
Perl and PHP have been addressed by HPE NonStop Servers OSS
Script Languages. The vulnerabilities include Perl's
opportunistic loading of optional modules which might allow
local users to gain elevation of privilege via a Trojan horse
library under the current working directory."
FWIW there are release candidates for Perl out including mitigating
changes for the CVE, which is documented at:

<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1238>

<http://www.nntp.perl.org/group/perl.perl5.porters/2016/07/msg238271.html>

I'll do my best to produce PCSI kits as soon as the relevant releases
become final. At least some of the Linux vendors released updates the
same day as the disclosure, but they had commonly-used bits of their
core infrastructure that were vulnerable.

I suppose the subtext here (getting back to Simon's original point) is
that the Linux vendors were in the loop when disclosure was coordinated,
which means someone knew who they were and contacted them and/or they
were involved enough in an upstream project to be subscribed to its
private security list and be aware of what was coming down.
Simon Clubley
2016-08-24 12:26:05 UTC
Permalink
Post by j***@yahoo.co.uk
As a point of comparison, what do the HPE NonStop people do about
reporting security isses (to and from HPE)?
If The Register and the HP link are to be believed, then they seem to be
fixed over a longer timeframe than even VMS open source related bugs:

http://www.theregister.co.uk/2016/08/22/hpe_patches_nonstop_admin/

And some people still wonder if responsible disclosure of exploits is
really required in order to get vendors to fix their own security bugs...
Post by j***@yahoo.co.uk
So the first line stuff is in place at HPE. What happens
after that is doubtless another story.
I would hope that VMS specific security bugs are currently fixed on
a far tighter timescale than some of the above appear to have been.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
IanD
2016-08-24 12:37:28 UTC
Permalink
Post by Simon Clubley
Post by j***@yahoo.co.uk
As a point of comparison, what do the HPE NonStop people do about
reporting security isses (to and from HPE)?
If The Register and the HP link are to be believed, then they seem to be
http://www.theregister.co.uk/2016/08/22/hpe_patches_nonstop_admin/
And some people still wonder if responsible disclosure of exploits is
really required in order to get vendors to fix their own security bugs...
Post by j***@yahoo.co.uk
So the first line stuff is in place at HPE. What happens
after that is doubtless another story.
I would hope that VMS specific security bugs are currently fixed on
a far tighter timescale than some of the above appear to have been.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
When I looked at that link and saw...

Quote: ...The oldest of these was fixed by the PHP project the same year it was discovered, 2013, so it's somewhat mysterious that HPE rolls it up into a single giant update.

The 45 patches part isn't the worrying bit, it's that some of these dated back as far as 2013 and where fairly promptly fixed when they were discovered by the open source custodians

3 years! Either HP could not be bothered or they were busy doing...doing...what exactly?

It's a catch 22 I guess. If your vendor is sitting on their arse over patching a vulnerability then at what point do you force the issue? Maybe it should be part of the license agreement? Once a security hole is detected, that it needs to be patched within x months or a discount off the next purchase triggers ;-)
David Froble
2016-08-24 13:05:58 UTC
Permalink
Post by IanD
Post by Simon Clubley
Post by j***@yahoo.co.uk
As a point of comparison, what do the HPE NonStop people do about
reporting security isses (to and from HPE)?
If The Register and the HP link are to be believed, then they seem to be
http://www.theregister.co.uk/2016/08/22/hpe_patches_nonstop_admin/
And some people still wonder if responsible disclosure of exploits is
really required in order to get vendors to fix their own security bugs...
Post by j***@yahoo.co.uk
So the first line stuff is in place at HPE. What happens
after that is doubtless another story.
I would hope that VMS specific security bugs are currently fixed on
a far tighter timescale than some of the above appear to have been.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
When I looked at that link and saw...
Quote: ...The oldest of these was fixed by the PHP project the same year it
was discovered, 2013, so it's somewhat mysterious that HPE rolls it up into a
single giant update.
The 45 patches part isn't the worrying bit, it's that some of these dated
back as far as 2013 and where fairly promptly fixed when they were discovered
by the open source custodians
3 years! Either HP could not be bothered or they were busy
doing...doing...what exactly?
It's a catch 22 I guess. If your vendor is sitting on their arse over
patching a vulnerability then at what point do you force the issue? Maybe it
should be part of the license agreement? Once a security hole is detected,
that it needs to be patched within x months or a discount off the next
purchase triggers ;-)
After all this time, and HP's performance over that time, why do you feel
surprised when you find out HP is not responsive and doesn't seem to give a damn?

"Discount off next purchase?"

I should laugh, "ha-ha", but that is just too sad.

You'd buy a broken glass that won't hold water?

You'd buy a new car with an engine that doesn't run?

You'd buy food that's already rotten?

Hey, I got a bridge for sale .....................
IanD
2016-08-24 17:51:01 UTC
Permalink
<snip>
Post by David Froble
After all this time, and HP's performance over that time, why do you feel
surprised when you find out HP is not responsive and doesn't seem to give a damn?
"Discount off next purchase?"
I should laugh, "ha-ha", but that is just too sad.
You'd buy a broken glass that won't hold water?
You'd buy a new car with an engine that doesn't run?
You'd buy food that's already rotten?
Hey, I got a bridge for sale .....................
lol

I worked for a company who was taken over by HP, although they tried to call it a merger *cough*

When the higher up management came and gave us a presentation of how good HP was we sat there and listened like good on-boarding bright eyed and bushy tailed new recruits should.

Then when they explained how printer cartridges were there largest profit item we just looked at each other and realized instantly that unless your in the commodity game your employment days were numbered in HP.
10 months later HP gave us our marching orders. There was no place for service oriented folk in their commodity world.

I remember only too well the internal faceless interface within all areas of HP we had to deal with. Managers whom you never got to meet, processes that were so automated you never dealt with anyone on the phone because you only ever dealt with an email or a note in a ticket tracking system.
The complete dehumanization of every aspect and the laugh was, it was less efficient than so called older systems were human contact remained and you deal with humans directly. It was the equivalent to a totally over normalized database. No single area had the autonomy to operate on it's own accord.

A few years later I tried finding out what was necessary to upgrade an old Alphaserver and there-in started my journey of how disconnected the various elements within HP still were from what I had experienced as an insider!

I can't exactly remember now but in my efforts to find out the information necessary my emailed wound it's way through the organisation across 11 or 12 different people's inboxes for them to comment on.
In dribs and drabs came the answer but I was the one pushing to obtain more of the whole picture.
If this was a DB, have 12 different I/O paths to obtain the record you are after would be considered a rather poor design.

I seriously don't think HPE is going to be anymore successful quite frankly based on what I have seen unless they loose that stench they acquired when HP morphed into an organisation more interested in pushing commodity items for quick sale than being the great product producers they used to be (I'm fondly remembering my HP-41CX calculator and the solid HP printers I used to install and those wonder HP Oscilloscopes I used to play with so so long ago). Adding value and getting returns off that value you add was the driver behind the company I used to work for, getting a slice of pushing an item seemed to be the HP way. That's a looser game IMO because all your competing on is commodity prices.

A few of the HPE people I deal with here have been good but then again, they were good under HP anyway in-spite of the organisation.

I guess I cannot totally frown on HP, they did release OpenVMS at least, although under a somewhat restrained model so as to extract ongoing revenue, which is a bit rich in my book since they did sfa with it really since 2010.
David Froble
2016-08-24 21:41:55 UTC
Permalink
Post by IanD
<snip>
Post by David Froble
After all this time, and HP's performance over that time, why do you feel
surprised when you find out HP is not responsive and doesn't seem to give a damn?
"Discount off next purchase?"
I should laugh, "ha-ha", but that is just too sad.
You'd buy a broken glass that won't hold water?
You'd buy a new car with an engine that doesn't run?
You'd buy food that's already rotten?
Hey, I got a bridge for sale .....................
lol
I worked for a company who was taken over by HP, although they tried to call it a merger *cough*
When the higher up management came and gave us a presentation of how good HP was we sat there and listened like good on-boarding bright eyed and bushy tailed new recruits should.
Then when they explained how printer cartridges were there largest profit item we just looked at each other and realized instantly that unless your in the commodity game your employment days were numbered in HP.
10 months later HP gave us our marching orders. There was no place for service oriented folk in their commodity world.
I remember only too well the internal faceless interface within all areas of HP we had to deal with. Managers whom you never got to meet, processes that were so automated you never dealt with anyone on the phone because you only ever dealt with an email or a note in a ticket tracking system.
The complete dehumanization of every aspect and the laugh was, it was less efficient than so called older systems were human contact remained and you deal with humans directly. It was the equivalent to a totally over normalized database. No single area had the autonomy to operate on it's own accord.
A few years later I tried finding out what was necessary to upgrade an old Alphaserver and there-in started my journey of how disconnected the various elements within HP still were from what I had experienced as an insider!
I can't exactly remember now but in my efforts to find out the information necessary my emailed wound it's way through the organisation across 11 or 12 different people's inboxes for them to comment on.
In dribs and drabs came the answer but I was the one pushing to obtain more of the whole picture.
If this was a DB, have 12 different I/O paths to obtain the record you are after would be considered a rather poor design.
I seriously don't think HPE is going to be anymore successful quite frankly based on what I have seen unless they loose that stench they acquired when HP morphed into an organisation more interested in pushing commodity items for quick sale than being the great product producers they used to be (I'm fondly remembering my HP-41CX calculator and the solid HP printers I used to install and those wonder HP Oscilloscopes I used to play with so so long ago). Adding value and getting returns off that value you add was the driver behind the company I used to work for, getting a slice of pushing an item seemed to be the HP way. That's a looser game IMO because all your competing on is commodity prices.
A few of the HPE people I deal with here have been good but then again, they were good under HP anyway in-spite of the organisation.
I guess I cannot totally frown on HP, they did release OpenVMS at least, although under a somewhat restrained model so as to extract ongoing revenue, which is a bit rich in my book since they did sfa with it really since 2010.
My daughter and her husband have a HP color ink jet printer, actually one of
those multi-function things. I never did like the piece of shit. It would sit
there and consume 50% of the CPU, just waiting on someone to attempt to scan
something, from the printer. What a bad idea. You want to scan something, have
the computer direct the printer to do the scan.

So I was there last week, and they have another printer, that they cannot seem
to get working. I asked why? The ink things in the HP printer are "past their
use date". Not empty, just, "time to buy more". I was told they were too
expensive.

Now, I just don't believe in ink jet printers. Get a laser printer, even a
color laser printer. Don't know what the color toner costs, but it can't be
much worse than the ink. I've never heard of toner that has an expiration date.

Anyone who knows what the likes of HP does, and still buys their products,
deserves to be screwed. Expiration dates on ink, whoever thought up that
atrocity needs to be the guest of honor at a blanket party, as the rest beat the
lumps out of the blanket with aluminum baseball bats.

HP joining the likes of DEC, Compaq, and such cannot happen too quickly ....
IanD
2016-08-27 11:24:25 UTC
Permalink
On Thursday, August 25, 2016 at 7:41:57 AM UTC+10, David Froble wrote:

<snip>
Post by David Froble
My daughter and her husband have a HP color ink jet printer, actually one of
those multi-function things. I never did like the piece of shit. It would sit
there and consume 50% of the CPU, just waiting on someone to attempt to scan
something, from the printer. What a bad idea. You want to scan something, have
the computer direct the printer to do the scan.
So I was there last week, and they have another printer, that they cannot seem
to get working. I asked why? The ink things in the HP printer are "past their
use date". Not empty, just, "time to buy more". I was told they were too
expensive.
Now, I just don't believe in ink jet printers. Get a laser printer, even a
color laser printer. Don't know what the color toner costs, but it can't be
much worse than the ink. I've never heard of toner that has an expiration date.
Anyone who knows what the likes of HP does, and still buys their products,
deserves to be screwed. Expiration dates on ink, whoever thought up that
atrocity needs to be the guest of honor at a blanket party, as the rest beat the
lumps out of the blanket with aluminum baseball bats.
HP joining the likes of DEC, Compaq, and such cannot happen too quickly ....
lol, funny but sadly true!

I have an HP printer that's a laser (A3 mono format). It's ok but it complains now and then about the drum needing replacing. I bought it at auction many years ago and I've got my monies worth out of it but only because the auction price was very low.

I gave up on inkjet printers about 4 years ago and because I wanted something for high quality color work, I opted for a color laser. Everyone was buying FujiXerox printer but I went for an Oki and have never looked back, it's an incredibly reliable printer but not cheap!

I'd happily buy an Oki again but would also consider Brother, they get a good rap for reliability also. Color toner is expensive, VERY, but the print price per page is much cheaper than ink, so it depends on how much you print will determine if it's worth going to color laser.

Also, note, color laser printers do not do photo's well. They are brilliant for documents but not for photo's.
Inkjet's still hold the crown in this area but with cheap photo labs around, it's not worth printing your own photo's anymore anyhow.

When HP took over our workplace, we were forced to give up our reliable Xerox printers and HP put in their large document printers. What pieces of utter crap they were, I have never experienced such unreliable printers as those pieces of trash were. These were huge departmental printers that seriously were broken more times then they were working. We had about 10 of these things spread over 4 large floor and we were always having to find out what printer was working that day and send the jobs to them, often involving traversing to other floors to get your printouts!
I cannot stress how much these things were just crap. Flimsy construction, lousy quality print and worst of all, piss poor PS processing and atrocious document handling. I'd never recommend one in a million years.

It was so frustrating printing something that would die at page 180 out of a 200 page double sided print job. Used to happen all the bloody time.
Stephen Hoffman
2016-08-24 13:22:16 UTC
Permalink
Post by IanD
The 45 patches part isn't the worrying bit, it's that some of these
dated back as far as 2013 and where fairly promptly fixed when they
were discovered by the open source custodians
VSI and OpenVMS "have some issues" with security, and I'll leave it at that.
--
Pure Personal Opinion | HoffmanLabs LLC
IanD
2016-08-30 18:23:42 UTC
Permalink
Post by Stephen Hoffman
Post by IanD
The 45 patches part isn't the worrying bit, it's that some of these
dated back as far as 2013 and where fairly promptly fixed when they
were discovered by the open source custodians
VSI and OpenVMS "have some issues" with security, and I'll leave it at that.
--
Pure Personal Opinion | HoffmanLabs LLC
I've read some of your posts on security and agree, OpenVMS has a lot of work, no, a sh*t load of work to do.

Security isn't just about protecting files, it's everything. I have taken the time to watch a number of youtube lectures on security exploits and hacking over the past 6 months and quite frankly, coming from the typical OpenVMS mindset where you sit smug thinking that OpenVMS is fine or mostly fine, you suddenly get a thunderbolt put right up your backside when you realize how sophisticated some of these exploits are.

I have gone from thinking OpenVMS is secure to thinking that OpenVMS will certainly fall IMO from a focused attack in it's current state and anyone thinking otherwise is delusional. As they say, the only reasonably safe system is one not connected to the network at all.

I know VSI cannot fix 10 years of neglect of OpenVMS in an instant but there are some fundamental elements that you don't want to get wrong going forward in the revamp and one is security.

If OpenVMS announces to the world it's back and on x86 and then gets hacked, we may as well all pack up our bags and go home, I think a hack of OpenVMS at that critical stage will be the be-all and end-all of OpenVMS as past quaint notions of OpenVMS being a sturgeon defense against attack will be put to rest forever.

Perhaps a think-tank of OpenVMS security might be a good idea. I don't know if that is already happening or not other than people making mention of it here in this forum.

Then we need systems that we can actively perform penetration testing on etc etc etc, a bucket-load of work is ahead of us and the leadership necessary to drive some of these initiatives is also going to need to be forthcoming as well.

What about concepts like asking companies to contribute towards a fund that provides OpenVMS specific penetration testing? Companies pay to have OpenVMS systems tested and depending on their contribution determines the level of security analysis detail they get? I'm just throwing ideas around and trying to work on the notion that the OpenVMS community is small and that pooling resources like this might be a way to get a community focus on OpenVMS security rather than waiting for VSI to do it all - they are busy enough trying to fix-up years of neglect.

Perhaps instead of VSI shelling out cash, any security breach that is uncovered by the community testers / security lab (however that lab is funded) gets discounts on VSI related licenses / products? Then we need VSI to give those security breaches the focus and attention they deserve.

LOTS of work to do...
Stephen Hoffman
2016-08-30 19:03:59 UTC
Permalink
Post by IanD
What about concepts like asking companies to contribute towards a fund
that provides OpenVMS specific penetration testing?
My concern is less one of finding weaknesses and security holes, it's
of funding the port, the necessary system development work, of building
the business and its infrastructure, and — rather further down the list
— working on security fixes and updates. Security empirically (and
understandably) appears to be rather further down on the general
funding list, and adding CVEs and pen-testing very likely won't change
these financial calculations.

Of some of the security issues discussed here in comp.os.vms in recent
years, there's removing and deprecating unencrypted transports,
integrating certificates and TLS and DTLS, ASLR and sandboxing, and
support for hardening VSI and ISV and end-user applications,
overhauling and speeding the entire patch process, and more than a few
other details. The holes are either known or obvious or should be
obvious to any cursory review, and there's not a whole lot of reason to
go looking for issues more when — for instance — DECnet is still
around, and where tools such as ftp and telnet are easy to get at.

Why look for (more) holes when more than a few of core network services
and tools — Apache, NTP, DHCP, php, Java, SMH, etc — are problematic,
and when there are lists of CVEs available? VSI is certainly working
on at least some of these areas, with a more recent Apache and Java
reportedly underway, and a new IP stack in development, among other
projects.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2016-08-31 01:17:17 UTC
Permalink
Post by Stephen Hoffman
Why look for (more) holes when more than a few of core network services
and tools — Apache, NTP, DHCP, php, Java, SMH, etc — are problematic,
and when there are lists of CVEs available? VSI is certainly working
on at least some of these areas, with a more recent Apache and Java
reportedly underway, and a new IP stack in development, among other
projects.
Because when you make a comment like that you are not thinking about
this in the way that you should be.

The items you list above have become workhorse security issues; yes,
it's always good to find new issues but it's no longer exciting to a
researcher unless the issue is really bad.

VMS itself OTOH represents something new to most security researchers
and it's an operating system that one of it's vendors says the following
about:

https://vmssoftware.com/products.html#security

When you say things like that, some outside researchers will see that
as a challenge and as a way to make a name for themselves if they find
several exploits in an operating system described as:

|OpenVMS remains the operating environment of choice for enterprises
|that require mission critical business continuity, scalability and the
|highest level of security.

(also from that page). Sometimes I think it would be good if someone
within the VMS community with the time and skills would undertake this
research themselves, find these issues and then publicise them in
detail _AFTER_ giving HP and VSI time to fix them. They would be doing
a good service to the VMS community and that way, it might shake some
people out of their complacency before the external researchers decide
to get in on the act.

And don't forget that there are issues to be found. The DEFCON
researchers found a SMG bug and a finger bug with very little VMS
knowledge. VMS descriptors did nothing to stop the first bug and the
finger code should never have passed code review.

There's also the V7.x era bug where trying to specify too long a
process name (IIRC) caused a system crash. VMS descriptors did nothing
to stop that one as well.

There also this little gem: https://www.cvedetails.com/cve/CVE-2010-0443/

|Unspecified vulnerability in Record Management Services (RMS) before
|VMS83A_RMS-V1100 for HP OpenVMS on the Alpha platform allows local
|users to gain privileges via unknown vectors.

Those are just examples that I either remembered or in the case of the
RMS one found with a quick search.

Three of those four bugs are VMS specific and where they exist, then
so will others. The security researchers who become interested in
exploring VMS security will know this and it will motivate them to
find more bugs.

BTW, that RMS bug is a nasty one and is also a good example of issues
that might be lying around which can blow VMS security wide open at
any time. Imagine what could have happened if an external researcher
had found that and reported it using full disclosure instead of
responsible disclosure.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Craig A. Berry
2016-08-31 02:20:08 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
Why look for (more) holes when more than a few of core network services
and tools — Apache, NTP, DHCP, php, Java, SMH, etc — are problematic,
and when there are lists of CVEs available? VSI is certainly working
on at least some of these areas, with a more recent Apache and Java
reportedly underway, and a new IP stack in development, among other
projects.
Because when you make a comment like that you are not thinking about
this in the way that you should be.
The items you list above have become workhorse security issues; yes,
it's always good to find new issues but it's no longer exciting to a
researcher unless the issue is really bad.
What about the old issues? I think Hoff is just saying you have to crawl
before you can walk. When there are CVEs that have been out for some
years but have not been patched on VMS, that stuff has to get fixed,
probably before any serious work on born-VMS vulnerabilities can be
properly attended to. That said, I agree with you about the need for
proper infrastructure to report and disclose security-related problems.
Post by Simon Clubley
VMS itself OTOH represents something new to most security researchers
and it's an operating system that one of it's vendors says the following
https://vmssoftware.com/products.html#security
When you say things like that, some outside researchers will see that
as a challenge and as a way to make a name for themselves if they find
It's probably of less interest to researchers than to people who base
criminal activity on research done some time ago. Most breaches exploit
vulnerabilities that have already been patched but catch people who
haven't applied the patches yet. When the patches don't even exist for
VMS years after they've been available elsewhere, that's a problem.
Stephen Hoffman
2016-08-31 15:30:14 UTC
Permalink
Post by Craig A. Berry
What about the old issues? I think Hoff is just saying you have to
crawl before you can walk. When there are CVEs that have been out for
some years but have not been patched on VMS, that stuff has to get
fixed,
probably before any serious work on born-VMS vulnerabilities can be
properly attended to.
Ayup. Exactly.
--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2016-08-31 19:39:10 UTC
Permalink
-----Original Message-----
Behalf Of Craig A. Berry via Info-vax
Sent: 30-Aug-16 10:20 PM
Subject: Re: [Info-vax] Should VSI create a security bug
bounty program for VMS ?
On 2016-08-30, Stephen Hoffman
Post by Stephen Hoffman
Why look for (more) holes when more than a few of
core network services
Post by Stephen Hoffman
and tools — Apache, NTP, DHCP, php, Java, SMH, etc
— are problematic,
Post by Stephen Hoffman
and when there are lists of CVEs available? VSI is
certainly working
Post by Stephen Hoffman
on at least some of these areas, with a more recent
Apache and Java
Post by Stephen Hoffman
reportedly underway, and a new IP stack in
development, among other
Post by Stephen Hoffman
projects.
Because when you make a comment like that you are
not thinking about
this in the way that you should be.
The items you list above have become workhorse
security issues; yes,
it's always good to find new issues but it's no longer
exciting to a
researcher unless the issue is really bad.
What about the old issues? I think Hoff is just saying you
have to crawl
before you can walk. When there are CVEs that have been
out for some
years but have not been patched on VMS, that stuff has
to get fixed,
probably before any serious work on born-VMS
vulnerabilities can be
properly attended to. That said, I agree with you about
the need for
proper infrastructure to report and disclose security-
related problems.
VMS itself OTOH represents something new to most
security researchers
and it's an operating system that one of it's vendors says
the following
https://vmssoftware.com/products.html#security
When you say things like that, some outside researchers
will see that
as a challenge and as a way to make a name for
themselves if they find
It's probably of less interest to researchers than to people
who base
criminal activity on research done some time ago. Most
breaches exploit
vulnerabilities that have already been patched but catch
people who
haven't applied the patches yet. When the patches don't
even exist for
VMS years after they've been available elsewhere, that's
a problem.
While I am all for enhancing security features and improving security reporting on OpenVMS, let's not forget that just because a patch is released for XYZ product and it results in a priv escalation on say Linux/UNIX, because of architecture issues, it does not necessarily mean the impact / end result is the same or even applicable on OpenVMS.

Just curious - what CVE's are out there today that have not been addressed on OpenVMS?

(not being contrary here, but would like to know)

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Craig A. Berry
2016-08-31 23:51:37 UTC
Permalink
Post by Kerry Main
While I am all for enhancing security features and improving
securityreporting on OpenVMS, let's not forget that just because a patch is
released for XYZ product and it results in a priv escalation on say
Linux/UNIX, because of architecture issues, it does not necessarily mean
the impact / end result is the same or even applicable on OpenVMS.
The CVEs are generally against the affected package, so if only GNU
libc, or only the Linux kernel is affected, that will likely be clear
enough in the disclosure. Otherwise you should assume the problem exists
on all platforms where the package runs until proven otherwise.
Post by Kerry Main
Just curious - what CVE's are out there today that have not been addressed on OpenVMS?
Many examples have already been given in this thread.
Kerry Main
2016-08-31 02:30:51 UTC
Permalink
-----Original Message-----
Behalf Of Simon Clubley via Info-vax
Sent: 30-Aug-16 9:17 PM
Cc: Simon Clubley
Subject: Re: [Info-vax] Should VSI create a security bug
bounty program for VMS ?
On 2016-08-30, Stephen Hoffman
Post by Stephen Hoffman
Why look for (more) holes when more than a few of
core network services
Post by Stephen Hoffman
and tools — Apache, NTP, DHCP, php, Java, SMH, etc —
are problematic,
Post by Stephen Hoffman
and when there are lists of CVEs available? VSI is
certainly working
Post by Stephen Hoffman
on at least some of these areas, with a more recent
Apache and Java
Post by Stephen Hoffman
reportedly underway, and a new IP stack in
development, among other
Post by Stephen Hoffman
projects.
Because when you make a comment like that you are not
thinking about
this in the way that you should be.
The items you list above have become workhorse security
issues; yes,
it's always good to find new issues but it's no longer
exciting to a
researcher unless the issue is really bad.
VMS itself OTOH represents something new to most
security researchers
and it's an operating system that one of it's vendors says
the following
https://vmssoftware.com/products.html#security
When you say things like that, some outside researchers
will see that
as a challenge and as a way to make a name for
themselves if they find
Well, OpenVMS runs some of the biggest financial environments on the planet (e.g. Shanghai Stock Exchange, German Stock Exchange, big banks) so that in itself should be motivation enough. But, as far as I know, this has not happened.

Let's also not forget that most hackers go after the easier environments that they know and understand. Likely 90+% of hackers today know some combination of Windows, Linux and / or UNIX.

What do think the % of hackers is that have the level of understanding to hack an OpenVMS account?
|OpenVMS remains the operating environment of choice
for enterprises
|that require mission critical business continuity, scalability and the
|highest level of security.
(also from that page). Sometimes I think it would be good
if someone
within the VMS community with the time and skills would
undertake this
research themselves, find these issues and then publicise
them in
detail _AFTER_ giving HP and VSI time to fix them. They
would be doing
a good service to the VMS community and that way, it
might shake some
people out of their complacency before the external
researchers decide
to get in on the act.
Agree it would be good to have external security companies contracted to do OpenVMS vulnerability testing on a regular basis - perhaps annually?
And don't forget that there are issues to be found. The
DEFCON
researchers found a SMG bug and a finger bug with very
little VMS
knowledge. VMS descriptors did nothing to stop the first
bug and the
finger code should never have passed code review.
SMG was a biggie. Agree. Finger was an issue back 15+ years ago as I recall, but let's be real - how many OpenVMS sites ever turn on the TCPIP Finger service?

When I first heard about it, I had to look it up as I never knew any site that enabled Finger.
There's also the V7.x era bug where trying to specify too
long a
process name (IIRC) caused a system crash. VMS
descriptors did nothing
to stop that one as well.
https://www.cvedetails.com/cve/CVE-2010-0443/
|Unspecified vulnerability in Record Management
Services (RMS) before
|VMS83A_RMS-V1100 for HP OpenVMS on the Alpha
platform allows local
|users to gain privileges via unknown vectors.
Those are just examples that I either remembered or in
the case of the
RMS one found with a quick search.
Three of those four bugs are VMS specific and where they
exist, then
so will others. The security researchers who become
interested in
exploring VMS security will know this and it will motivate
them to
find more bugs.
BTW, that RMS bug is a nasty one and is also a good
example of issues
that might be lying around which can blow VMS security
wide open at
any time. Imagine what could have happened if an
external researcher
had found that and reported it using full disclosure instead
of
responsible disclosure.
No one is saying OpenVMS is 100% secure. There is no platform on the planet that can say this.

The real issue is the VOLUME of monthly patches that Customer Operations groups have to deal with.

Commodity OS's have 20+ security patches released each and EVERY month. Security patches - not normal bug patches. Yes, not all apply to all OS versions. Not all apply to the Products or services these OPS group actually use.

However, the reality is that every month IT OPS groups with commodity OS platforms have to: (remember larger shops have 100 to 1000+ server OS instances to manage)
- review each patch release notes to determine which ones are applicable to their environment (remember that you sometimes have to read between lines as vendors understandably do not provide great amounts of details on known issues);
- schedule each important or critical App for testing with this month's security patches to be applied;
- make sure each patch time is approved as part of the change mgmt. board meetings;
- schedule down times for each OS instance with each of the appropriate BU's;
- once patch is applied and OS rebooted, perform some basic tests to ensure the critical apps have not been impacted;
- once all seems ok, close the change mgmt. ticket that was created for this patch cycle;

Now, you can rightly argue that there may be OpenVMS vulnerabilities lurking out there waiting to be uncovered and I would agree with you. Again, no platform is 100% secure.

However, todays reality is that OpenVMS Operations shops do NOT have to deal with all of the above every single month. If they have to deal with 3-5 vulnerabilities per YEAR, then that is considered a bad year.

This is not to say OpenVMS does not need better security features and tools. Of course this is true. Even when security products like System Detective are added on, there is still lots of room for native security enhancements.

One only has to look at the recent US Elections hacking sagas to understand that the hacking world is rapidly getting out of control. News tonight was FBI is launching formal investigation into whether foreign govt's are trying to manipulate US election voting.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Phillip Helbig (undress to reply)
2016-08-31 19:04:28 UTC
Permalink
Post by Kerry Main
Post by Simon Clubley
When you say things like that, some outside researchers
will see that
as a challenge and as a way to make a name for
themselves if they find
Well, OpenVMS runs some of the biggest financial environments on the
planet (e.g. Shanghai Stock Exchange, German Stock Exchange, big banks)
so that in itself should be motivation enough. But, as far as I know,
this has not happened.
At least these days, VMS at these places is only on internal networks.
If someone who shouldn't has access to the internal networks, then there
are much bigger problems to worry about.
Kerry Main
2016-08-31 19:47:01 UTC
Permalink
-----Original Message-----
Behalf Of Phillip Helbig undress to reply via Info-vax
Sent: 31-Aug-16 3:04 PM
Cc: Phillip Helbig undress to reply
Subject: Re: [Info-vax] Should VSI create a security bug
bounty program for VMS ?
In article <mailman.9.1472610713.31074.info-
Post by Kerry Main
Post by Simon Clubley
When you say things like that, some outside
researchers
Post by Kerry Main
Post by Simon Clubley
will see that
as a challenge and as a way to make a name for
themselves if they find
several exploits in an operating system described
Well, OpenVMS runs some of the biggest financial
environments on the
Post by Kerry Main
planet (e.g. Shanghai Stock Exchange, German Stock
Exchange, big banks)
Post by Kerry Main
so that in itself should be motivation enough. But, as
far
as I know,
Post by Kerry Main
this has not happened.
At least these days, VMS at these places is only on
internal
networks.
If someone who shouldn't has access to the internal
networks, then there
are much bigger problems to worry about.
Most security groups will state that their biggest worry
is not the Internet, but rather internal threats.

Not just disgruntled employees, but cell phones,
notebooks, and laptops all regularly traverse public /
home networks and then reconnect to wireless / hard
connections to internal networks in the office and/or via
VPN.

And of course, cell phones/notebooks are really just big
fat PC's with big storage and little to zero security
monitoring SW on them.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Phillip Helbig (undress to reply)
2016-09-01 20:58:24 UTC
Permalink
Post by Kerry Main
Post by Kerry Main
Post by Kerry Main
Well, OpenVMS runs some of the biggest financial
environments on the
Post by Kerry Main
planet (e.g. Shanghai Stock Exchange, German Stock
Exchange, big banks)
Post by Kerry Main
so that in itself should be motivation enough. But, as far
as I know,
Post by Kerry Main
this has not happened.
At least these days, VMS at these places is only on internal networks.
If someone who shouldn't has access to the internal
networks, then there
are much bigger problems to worry about.
Most security groups will state that their biggest worry
is not the Internet, but rather internal threats.
True, but usually not exploiting some security hole, but rather someone
doing something they shouldn't.
Post by Kerry Main
Not just disgruntled employees, but cell phones,
notebooks, and laptops all regularly traverse public /
home networks and then reconnect to wireless / hard
connections to internal networks in the office and/or via
VPN.
And if the production VMS systems are on the same network, then the
security policies need to be changed. (Reminds me of the old joke: when
the unix sysadmin talks about security, he means that of his job.)
Post by Kerry Main
And of course, cell phones/notebooks are really just big
fat PC's with big storage and little to zero security
monitoring SW on them.
Right, which is why they have no business on a production network.
Craig A. Berry
2016-09-01 21:18:14 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Kerry Main
And of course, cell phones/notebooks are really just big
fat PC's with big storage and little to zero security
monitoring SW on them.
Right, which is why they have no business on a production network.
Why not? For many companies they are production systems in that people
use them to perform critical functions, possibly even accessing data on
that VMS system you've got hidden away.
Stephen Hoffman
2016-09-02 16:52:14 UTC
Permalink
Post by Craig A. Berry
Post by Phillip Helbig (undress to reply)
And of course, cell phones/notebooks are really just big fat PC's with
big storage and little to zero security monitoring SW on them.
Right, which is why they have no business on a production network.
Why not? For many companies they are production systems in that people
use them to perform critical functions, possibly even accessing data on
that VMS system you've got hidden away.
Ayup. Computers serve the business.

More than a few of those devices are also managed via MDM or otherwise,
and the MDM packages provide the means to ensure current firmware and
related apps are present.

More than a few of the OpenVMS folks I work with use mobile devices
with OpenVMS. OpenVMS lacks any infrastructure for MDM and for
provisioning and profiles, unfortunately.

Then there's managing the servers. I remotely manage various servers
from phones and tablets regularly, and I'd really like for that to be
easier. Including OpenVMS servers. If OMS/TNT gets opened up and/or
gets updated, maybe there'll be better ways to do that, too?
--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2016-09-02 12:30:21 UTC
Permalink
-----Original Message-----
Behalf Of Phillip Helbig undress to reply via Info-vax
Sent: 01-Sep-16 4:58 PM
Cc: Phillip Helbig undress to reply
Subject: Re: [Info-vax] Should VSI create a security bug
bounty program for VMS ?
In article <mailman.2.1472673255.26953.info-
Post by Kerry Main
Post by Kerry Main
Post by Kerry Main
Well, OpenVMS runs some of the biggest financial
environments on the
Post by Kerry Main
planet (e.g. Shanghai Stock Exchange, German Stock
Exchange, big banks)
Post by Kerry Main
so that in itself should be motivation enough.
But, as
far
Post by Kerry Main
Post by Kerry Main
as I know,
Post by Kerry Main
this has not happened.
At least these days, VMS at these places is only on
internal networks.
Post by Kerry Main
Post by Kerry Main
If someone who shouldn't has access to the internal
networks, then there
are much bigger problems to worry about.
Most security groups will state that their biggest
worry
Post by Kerry Main
is not the Internet, but rather internal threats.
True, but usually not exploiting some security hole, but
rather someone
doing something they shouldn't.
That is only a part of it.

http://blog.eiqnetworks.com/blog/internal-vs.-external-sec
urity-threats-why-internal-is-worse-than-you-expected-and-
what-you-can-do-about-it

http://www.eweek.com/small-business/businesses-bedeviled-b
y-internal-security-incidents.html
From 2009 - but messages from an experienced security pro
is valid today as well i.e. Old style companies still
wrongly differentiate between "internal" and "external"
threats.:
http://informationsecurityformanagers.blogspot.ca/2009/03/
again-internal-security-threat.html
" The answer is actually simple; the technology that
builds today's security architecture does not do the job.
Most solutions are built around the notion of the
existence of an inside and an outside. Please repeat after
me...there is no difference between the inside and the
outside anymore. Security solutions has to be built
according to a model where users only have access
information "on a need to know basis" REGARDLESS of where
they happen to be for the moment (and according to how
secure the device is etc etc). Today's IT environment is
far too complex and users to mobile for an inside/outside
model."

http://www.darkreading.com/vulnerabilities---threats/repor
ts-security-pros-shift-attention-from-external-hacks-to-in
ternal-threats/d/d-id/1130530?cid=nl_dr_weekly_t
Post by Kerry Main
Not just disgruntled employees, but cell phones,
notebooks, and laptops all regularly traverse public /
home networks and then reconnect to wireless / hard
connections to internal networks in the office and/or
via
Post by Kerry Main
VPN.
And if the production VMS systems are on the same
network, then the
security policies need to be changed. (Reminds me of
the
old joke: when
the unix sysadmin talks about security, he means that of
his job.)
Post by Kerry Main
And of course, cell phones/notebooks are really just
big
Post by Kerry Main
fat PC's with big storage and little to zero security
monitoring SW on them.
Right, which is why they have no business on a
production
network.
While servers may be on a different VLAN than users, due
to internal FW zoning complexities and historical old time
security views, companies think they only need to worry
about external threats. Unfortunately, creative Trojans /
worms that make their way to laptops and cell phones via
external networks can then easily poke around on internal
networks looking for systems with known vulnerabilities
that have not been patched.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Stephen Hoffman
2016-09-01 00:24:37 UTC
Permalink
Post by Phillip Helbig (undress to reply)
At least these days, VMS at these places is only on internal networks.
If someone who shouldn't has access to the internal networks, then
there are much bigger problems to worry about.
Not a good bet, not a safe bet, and not a good starting point for
marketing a product.
http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43231.pdf
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2016-09-01 13:22:49 UTC
Permalink
Post by Kerry Main
What do think the % of hackers is that have the level of understanding to
hack an OpenVMS account?
One hell of a lot more than currently exist when VMS becomes available on
x86-64 hardware, especially if VSI do some kind of hobbyist program.
Post by Kerry Main
SMG was a biggie. Agree. Finger was an issue back 15+ years ago as I recall,
but let's be real - how many OpenVMS sites ever turn on the TCPIP Finger
service?
That's not the point; the finger problem appears to have been a format
string vulnerability; if so, it should never have passed code review
in the first place. The obvious questions is do any similar problems
exist in other parts of the stack ?
Post by Kerry Main
Commodity OS's have 20+ security patches released each and EVERY month.
Security patches - not normal bug patches. Yes, not all apply to all OS
versions. Not all apply to the Products or services these OPS group actually
use.
And VMS would be seeing a lot more patches if it's internet related
components were updated at the rate they should be.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2016-09-01 14:24:11 UTC
Permalink
Post by Simon Clubley
Post by Kerry Main
What do think the % of hackers is that have the level of understanding to
hack an OpenVMS account?
One hell of a lot more than currently exist when VMS becomes available on
x86-64 hardware, especially if VSI do some kind of hobbyist program.
Post by Kerry Main
SMG was a biggie. Agree. Finger was an issue back 15+ years ago as I recall,
but let's be real - how many OpenVMS sites ever turn on the TCPIP Finger
service?
That's not the point; the finger problem appears to have been a format
string vulnerability; if so, it should never have passed code review
in the first place. The obvious questions is do any similar problems
exist in other parts of the stack ?
Post by Kerry Main
Commodity OS's have 20+ security patches released each and EVERY month.
Security patches - not normal bug patches. Yes, not all apply to all OS
versions. Not all apply to the Products or services these OPS group actually
use.
And VMS would be seeing a lot more patches if it's internet related
components were updated at the rate they should be.
Simon.
Yeah, it's a bit hard to "hack" something you cannot make a connection to ..
Stephen Hoffman
2016-09-01 15:16:23 UTC
Permalink
Post by Simon Clubley
Post by Kerry Main
Commodity OS's have 20+ security patches released each and EVERY month.
Security patches - not normal bug patches. Yes, not all apply to all OS
versions. Not all apply to the Products or services these OPS group
actually use.
And VMS would be seeing a lot more patches if it's internet related
components were updated at the rate they should be.
Ayup.

Do I like patches that often? No. But I like patches and critical
updates that are months or years late even less. That delay just
leaves everybody open for shenanigans, from whatever activity or
exploit or disclosure triggered the original development of the patch,
or from anybody that can read the CVEs and the exploits and do a little
digging.

In areas where the sources are common — various of the web-facing
components and some security components — OpenVMS is missing a whole
lot of those patches and updates. The DNS server version on OpenVMS
— not exactly an inconsequential component of network security — is
long deprecated, for instance. It's a good bet that some of the
patches related to the DNS server also apply to OpenVMS, too.

Even what are considered high-priority security patches usually arrive
a month later on OpenVMS. On other platforms, those patches are
either immediately available, or arrive within a day or two.

Then there's how much I despise having to periodically and manually log
into a patch portal and check for new patches and download the patches
and unpack the patches and read the patch installation notes and then
copy the patches to the target servers and issue the manual patch
commands and run the rolling reboots or whatever other updates are
required. This whole patch process is patently absurd.

Pointing at dozens of patches for the other platforms might makes for
some decent vendor marketing, certainly. Pointing at a long-deprecated
DNS server version and at OpenSSL patches that are usually a month late
and that are probably then not very widely or quickly installed, or
that OpenVMS might not see some applicable fixes and patches for years
— which is what end-users such as Stark and other OpenVMS customers
encounter — not so much.

Then there's that — (should? when? if?) OpenVMS becomes more
successful, and as OpenVMS inherently increases in scope and scale, and
as OpenVMS incorporates more open source — the most probable patch
trend will be an increasing number of patches and/or the need to
install at least certain patches or updates much more quickly, and
quite probably both.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2016-08-31 15:20:59 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
Why look for (more) holes when more than a few of core network services
and tools — Apache, NTP, DHCP, php, Java, SMH, etc — are problematic,
and when there are lists of CVEs available? VSI is certainly working
on at least some of these areas, with a more recent Apache and Java
reportedly underway, and a new IP stack in development, among other
projects.
Because when you make a comment like that you are not thinking about
this in the way that you should be.
I'm not inclined to go looking for new holes. When the proverbial
"low-hanging fruit" is plentiful, looking for truly sneaky holes is
wasted effort.

The most recent version of Java available for OpenVMS, for instance,
has ancient and insecure crypto. SMNPv2 is unencrypted. Apache,
DHCP, php, SMH, etc, are down-revision and have vulnerabilities...

Get a current foundation in place, get current tools in place, then go
looking for more. Once security is more competitive and more robust —
ASLR, sandboxing, etc — and when the funding is available for it, then
start increasing the costs of the security bugs in the market through
programs such as a bug bounty.
Post by Simon Clubley
VMS itself OTOH represents something new to most security researchers
and it's an operating system that one of it's vendors says the
https://vmssoftware.com/products.html#security
Maybe I've been too subtle in my comments? I find that particular VSI
marketing problematic. For various reasons. I'm aware of the
responses it can engender.
Post by Simon Clubley
When you say things like that, some outside researchers will see that
as a challenge and as a way to make a name for themselves if they find
several exploits in an operating system described as...
I already pointed to a comment from one of the folks involved in the
DEFCON attacks that stated exactly that.
http://labs.hoffmanlabs.com/node/1004#comment-786
Post by Simon Clubley
BTW, that RMS bug is a nasty one and is also a good example of issues
that might be lying around which can blow VMS security wide open atb
any time. Imagine what could have happened if an external researcher
had found that and reported it using full disclosure instead of
responsible disclosure.
OpenVMS security has issues, and I'll (again) not comment further.

If y'all find bugs in OpenVMS, send'm to VSI. Or not.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2016-09-01 13:13:41 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
Post by Stephen Hoffman
Why look for (more) holes when more than a few of core network services
and tools ? Apache, NTP, DHCP, php, Java, SMH, etc ? are problematic,
and when there are lists of CVEs available? VSI is certainly working
on at least some of these areas, with a more recent Apache and Java
reportedly underway, and a new IP stack in development, among other
projects.
Because when you make a comment like that you are not thinking about
this in the way that you should be.
I'm not inclined to go looking for new holes. When the proverbial
"low-hanging fruit" is plentiful, looking for truly sneaky holes is
wasted effort.
The most recent version of Java available for OpenVMS, for instance,
has ancient and insecure crypto. SMNPv2 is unencrypted. Apache,
DHCP, php, SMH, etc, are down-revision and have vulnerabilities...
And I completely agree with all that. VSI (and HP) should be handling
all this automatically without it even needing to become a topic for
discussion. The fact they are not is a major failing in both of their
processes and makes a joke out of their (especially VSI's) strong
security marketing.

I'm thinking more about what's going to attract security researchers
to invest time in looking at VMS in the first place and the fact it's
something different and with this strong security message from it's
vendors is really good motiviation for those researchers.
Post by Stephen Hoffman
Get a current foundation in place, get current tools in place, then go
looking for more. Once security is more competitive and more robust ?
ASLR, sandboxing, etc ? and when the funding is available for it, then
start increasing the costs of the security bugs in the market through
programs such as a bug bounty.
Post by Simon Clubley
VMS itself OTOH represents something new to most security researchers
and it's an operating system that one of it's vendors says the
https://vmssoftware.com/products.html#security
Maybe I've been too subtle in my comments? I find that particular VSI
marketing problematic. For various reasons. I'm aware of the
responses it can engender.
Thanks for making that clear; I wasn't sure what you thought about that.
Post by Stephen Hoffman
Post by Simon Clubley
When you say things like that, some outside researchers will see that
as a challenge and as a way to make a name for themselves if they find
several exploits in an operating system described as...
I already pointed to a comment from one of the folks involved in the
DEFCON attacks that stated exactly that.
http://labs.hoffmanlabs.com/node/1004#comment-786
I wasn't aware of that comment thanks. It confirms my position that if
VSI continue saying the kinds of things that they are currently saying,
then they need to be aware of what is going to happen and how they
_seriously_ need to up their game in preparation for when it does.
Post by Stephen Hoffman
Post by Simon Clubley
BTW, that RMS bug is a nasty one and is also a good example of issues
that might be lying around which can blow VMS security wide open atb
any time. Imagine what could have happened if an external researcher
had found that and reported it using full disclosure instead of
responsible disclosure.
OpenVMS security has issues, and I'll (again) not comment further.
That's understandable given your insider insights. I hope you are
trying to push VSI to address your concerns however.
Post by Stephen Hoffman
If y'all find bugs in OpenVMS, send'm to VSI. Or not.
If I did find something then I most certainly would, bug bounty or no
bug bounty and I would do it on a responsible disclosure basis. Would
be nice to have some industry standard secure way to send sensitive
material to VSI however.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2016-09-01 14:33:02 UTC
Permalink
I'm thinking more about what's going to attract security researchers to
invest time in looking at VMS in the first place and the fact it's
something different and with this strong security message from it's
vendors is really good motiviation for those researchers.
That there's financial data or credit card data or sensitive
information on the platform is a larger incentive, these days.
Attacks are increasingly financial. Attacks are business. Attackers
can jump firewalls.

As for the future of OpenVMS and security, VSI has the talents to do a
security review of the product, and there are external entities that
offer that service. But VSI has project priorities secondary to
budget constraints, and— irrespective of the marketing, and outside of
finally deprecating that mess with the ACME and non-ACME LOGINOUT
images — I suspect security enhancements are not at the top of the
development schedule. Clair's (proverbial?) whiteboard of projects is
undoubtedly a long one, and VSI is comparatively a very tiny team with
comparatively tiny funding for a project of the scale of a proprietary
server operating system.

Cleaning up some of the proverbial low-hanging fruit will help, as will
migrating from cleartext to encrypted and authenticated data stores and
network transports. Just getting to current open source packages
will take some hunks out of the list of CVEs applicable against
OpenVMS. CVEs that aren't listed on that VSI marketing page, BTW.
I wasn't aware of that comment thanks. It confirms my position that if
VSI continue saying the kinds of things that they are currently saying,
then they need to be aware of what is going to happen and how they
_seriously_ need to up their game in preparation for when it does.
Ayup. Why do you think I've been commenting about OpenVMS security in
recent years? Was that all too staid? Too subtle?

The "integration" of certificates, SSL, encryption, TCP and related is
a complete and utter disaster, but I'm being polite.

For those that don't believe me or that reasonably wish to
independently verify my comments? Go try to use it and see how well
OpenVMS and TCP/IP Services and SSL and SSL1 and Apache and ENCRYPT and
LDAP and Kerberos and password storage and disk encryption and CDSA and
related pieces are all (not) integrated. Use the tools. I ran
into problems with the CA tools in OpenVMS, and ended up writing my own
to show how the pieces worked. And getting a subset of the disjoint
APIs semi-accessible from BASIC and Fortran is no joy, either.
http://labs.hoffmanlabs.com/node/1853

There are other areas of OpenVMS that need careful investigation and
remediation and/or updates, such as the now-seriously-far-too-efficient
Purdy password hash (e.g. too fast means too weak) and which I've
mentioned as one of the a compatibility-killing problems in OpenVMS.
There's the baroque patch notification, distribution and installation
process, and the lack of integrated (opt-in) system and application
crash uploads, ASLR and sandboxes and related. (System and
application crashes can very much be security relevant, as well as to
general stability and availability.)

Then ponder that HPE and VSI have reworked their own "secure
distribution" — formerly built on CDSA — to avoid using CDSA, so what's
that tell you about what HPE and VSI think about the security provided
by CDSA?

Programming reasonably secure server and network apps on OpenVMS is
comparatively difficult. There are only comparatively limited means
to isolate apps that are found vulnerable. You have to build and
maintain your own CA or your own root store. There's also weak
examples, and little in the way of documentation or a guide for
application development, as the security manual and the programming
concepts manual handling of app security is probably twenty years out
of date. That's before discussing the morass that is the security
APIs and the lack of integration among the various pieces.

If there's an overarching design of how the application security APIs
and tools are supposed to work, why are there so many different places
I need to put the certificates?

SSL and SSL1 is a whole 'nother issue. That adventure required more
than a little rework in build procedures.

After using systems where this better integrated, with central password
stores and integrated TLS networking and certificate verification and
revocation mechanisms integrated, the OpenVMS approach to security is
far from clear and far from simple. Sure, you can build all this and
all the pieces are certainly available, but — like working in machine
code or assembler — it's way more work, and with few (and unfortunately
very sketchy) examples. Complex and arcane and bespoke security
code usually means there will be security problems, too. That the
clarity and simplicity of the OpenVMS APIs in general also needs more
than a little remedial work work is another matter, and a different
rant.
--
Pure Personal Opinion | HoffmanLabs LLC
d***@gmail.com
2016-09-01 15:35:15 UTC
Permalink
Post by Stephen Hoffman
I suspect security enhancements are not at the top of the
development schedule.
You would be incorrect in that assumption.
Stephen Hoffman
2016-09-01 16:19:03 UTC
Permalink
Post by d***@gmail.com
I suspect security enhancements are not at the top of the development schedule.
You would be incorrect in that assumption.
Good. There are opportunities for more than a little swamp-draining
available, certainly.

Will there be (technical) information forthcoming on this work, either
in any presentations or in forthcoming documentation? There seem to
be no VSI technical sessions on security listed on the boot camp
schedule, though there's one VSI session on the "unsecure cyber-world
we live in", and a few sessions from various folks on specific products
or on using specific existing components.
--
Pure Personal Opinion | HoffmanLabs LLC
Robert A. Brooks
2016-09-01 16:47:32 UTC
Permalink
Post by Stephen Hoffman
Good. There are opportunities for more than a little swamp-draining
available, certainly.
Yeah, that exact phrasing was used during a discussion yesterday . . .
--
-- Rob
Stephen Hoffman
2016-09-01 17:08:50 UTC
Permalink
Post by Robert A. Brooks
Post by Stephen Hoffman
Good. There are opportunities for more than a little swamp-draining
available, certainly.
Yeah, that exact phrasing was used during a discussion yesterday . . .
Ayup. I've always thought those laser microphones worked great, too.

But seriously, have a look at at macOS security for some idea of how to
try to tie some of the disparate pieces together, if VSI is headed
toward draining the deeper parts of the swamp. I don't expect VSI to
implement anywhere near all of that, but the ways that the encrypted
key stores and the APIs are implemented and how the pieces work
together is very reminiscent of old-time VAX/VMS design and
integration. The way the key bags work is particularly useful, as it
avoids needing to decrypt and re-encrypt the data.
--
Pure Personal Opinion | HoffmanLabs LLC
Paul Sture
2016-09-01 19:00:40 UTC
Permalink
Post by Stephen Hoffman
Post by Robert A. Brooks
Post by Stephen Hoffman
Good. There are opportunities for more than a little swamp-draining
available, certainly.
Yeah, that exact phrasing was used during a discussion yesterday . . .
Ayup. I've always thought those laser microphones worked great, too.
But seriously, have a look at at macOS security for some idea of how to
try to tie some of the disparate pieces together, if VSI is headed
toward draining the deeper parts of the swamp. I don't expect VSI to
implement anywhere near all of that, but the ways that the encrypted
key stores and the APIs are implemented and how the pieces work
together is very reminiscent of old-time VAX/VMS design and
integration. The way the key bags work is particularly useful, as it
avoids needing to decrypt and re-encrypt the data.
Here's a real example of how that level of integration can work to
benefit both the application developer and end user.

From the latest "Release Notes for MailMate Revision 5260 (Thursday,
September 1, 2016) — Version 1.9.5 Beta 1":

New: Network code now uses CFNetwork instead of OpenSSL. This
implicitly means proxy support (System Preferences), IPv6 support,
and TLS 1.2 support.
--
It was untidy, so got unplugged.
It was unplugged, so got thrown away.
d***@gmail.com
2016-09-01 16:48:36 UTC
Permalink
Post by Stephen Hoffman
Good. There are opportunities for more than a little swamp-draining
available, certainly.
Agreed.
Post by Stephen Hoffman
Will there be (technical) information forthcoming on this work, either
in any presentations or in forthcoming documentation?
Outside my sphere of control. To the best of my knowledge you will see some indications of direction at some point soon.
John Reagan
2016-09-01 17:12:59 UTC
Permalink
Post by Stephen Hoffman
Clair's (proverbial?) whiteboard of projects is
undoubtedly a long one, and VSI is comparatively a very tiny team with
comparatively tiny funding for a project of the scale of a proprietary
server operating system.
It is quite real. Although he'll often spin his monitor around and show me something in a spreadsheet with even more detail. So I guess the answer is "both". :)
Stephen Hoffman
2016-09-02 14:56:28 UTC
Permalink
Post by John Reagan
Clair's (proverbial?) whiteboard of projects is undoubtedly a long one,
and VSI is comparatively a very tiny team with comparatively tiny
funding for a project of the scale of a proprietary server operating
system.
It is quite real. Although he'll often spin his monitor around and show
me something in a spreadsheet with even more detail. So I guess the
answer is "both". :)
https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2016-09-02 22:12:58 UTC
Permalink
Post by Stephen Hoffman
Post by John Reagan
Clair's (proverbial?) whiteboard of projects is undoubtedly a long
one, and VSI is comparatively a very tiny team with comparatively
tiny funding for a project of the scale of a proprietary server
operating system.
It is quite real. Although he'll often spin his monitor around and
show me something in a spreadsheet with even more detail. So I guess
the answer is "both". :)
https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
Whoa. Pretty soon you'll be saying crazy stuff such as that a company
that makes software ought to have a decent web site, maybe even sell
that software on the internet. ;-)
Stephen Hoffman
2016-09-05 15:34:31 UTC
Permalink
Post by Craig A. Berry
Post by Stephen Hoffman
Post by John Reagan
Clair's (proverbial?) whiteboard of projects is undoubtedly a long one,
and VSI is comparatively a very tiny team with comparatively tiny
funding for a project of the scale of a proprietary server operating
system.
It is quite real. Although he'll often spin his monitor around and show
me something in a spreadsheet with even more detail. So I guess the
answer is "both". :)
https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
Whoa. Pretty soon you'll be saying crazy stuff such as that a company
that makes software ought to have a decent web site, maybe even sell
that software on the internet. ;-)
That's crazy talk. 😜

I've found the use of spreadsheets for issue tracking and project
management tasks is a common indication of project management problems.
Too easy to hide project data from other project participants;
intentionally or otherwise. Too tedious to share and to collaborate
and to merge changes, too. There are better tools for these tasks.
If there's a bug-tracking system around — and there often is — then
I'd usually want the project plans and issues and discussions stored in
that, lest the associated knowledge be lost or forgotten or otherwise
isolated. But then management gets to make these sorts of trade-offs
all the time; whether the tools add more overhead, or reduce the wasted
effort, etc. Sometimes the most primitive and simple approach is the
best trade-off.
--
Pure Personal Opinion | HoffmanLabs LLC
c***@gmail.com
2016-09-06 10:18:53 UTC
Permalink
Post by Stephen Hoffman
Post by Craig A. Berry
Post by Stephen Hoffman
Post by John Reagan
Clair's (proverbial?) whiteboard of projects is undoubtedly a long one,
and VSI is comparatively a very tiny team with comparatively tiny
funding for a project of the scale of a proprietary server operating
system.
It is quite real. Although he'll often spin his monitor around and show
me something in a spreadsheet with even more detail. So I guess the
answer is "both". :)
https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
Whoa. Pretty soon you'll be saying crazy stuff such as that a company
that makes software ought to have a decent web site, maybe even sell
that software on the internet. ;-)
That's crazy talk. 😜
I've found the use of spreadsheets for issue tracking and project
management tasks is a common indication of project management problems.
Too easy to hide project data from other project participants;
intentionally or otherwise. Too tedious to share and to collaborate
and to merge changes, too. There are better tools for these tasks.
If there's a bug-tracking system around — and there often is — then
I'd usually want the project plans and issues and discussions stored in
that, lest the associated knowledge be lost or forgotten or otherwise
isolated. But then management gets to make these sorts of trade-offs
all the time; whether the tools add more overhead, or reduce the wasted
effort, etc. Sometimes the most primitive and simple approach is the
best trade-off.
--
Pure Personal Opinion | HoffmanLabs LLC
VSI uses ProjectLibre (open source moral equivalent of MicroSoft Project) for all project tracking.
Simon Clubley
2016-08-31 00:28:01 UTC
Permalink
Post by IanD
Post by Stephen Hoffman
Post by IanD
The 45 patches part isn't the worrying bit, it's that some of these
dated back as far as 2013 and where fairly promptly fixed when they
were discovered by the open source custodians
VSI and OpenVMS "have some issues" with security, and I'll leave it at that.
I've read some of your posts on security and agree, OpenVMS has a
lot of work, no, a sh*t load of work to do.
Security isn't just about protecting files, it's everything. I have
taken the time to watch a number of youtube lectures on security
exploits and hacking over the past 6 months and quite frankly, coming
from the typical OpenVMS mindset where you sit smug thinking that
OpenVMS is fine or mostly fine, you suddenly get a thunderbolt put
right up your backside when you realize how sophisticated some of
these exploits are.
Yes, they most certainly are and this is exactly what I have been
trying to warn people about. The types of things people were able to
do with large production systems in the heyday of VMS are only a
small subset of the security exploration techniques available today
for today's hardware and software.

The attitude that some people have here about VMS security is utterly
unjustified in today's world because that security is yet to be
seriously tested by today's standards. If VMS gets a real going over
by today's researchers and survives then the attitude will be justified
and not before.
Post by IanD
I have gone from thinking OpenVMS is secure to thinking that OpenVMS
will certainly fall IMO from a focused attack in it's current state
and anyone thinking otherwise is delusional. As they say, the only
reasonably safe system is one not connected to the network at all.
Yes! Finally! Someone else gets it! :-)

And yes, I know there are some people around here who also get this
but there are times when I really do feel like I'm in a minority of
one.
Post by IanD
I know VSI cannot fix 10 years of neglect of OpenVMS in an instant
but there are some fundamental elements that you don't want to get
wrong going forward in the revamp and one is security.
If OpenVMS announces to the world it's back and on x86 and then gets
hacked, we may as well all pack up our bags and go home, I think a
hack of OpenVMS at that critical stage will be the be-all and end-all
of OpenVMS as past quaint notions of OpenVMS being a sturgeon defense
against attack will be put to rest forever.
Actually, VMS will survive some initial security vulnerabilities
discovered by outsiders just fine provided the disclosure process
is managed properly and provided VSI demonstrate that they have
learned from any such discoveries by looking for and fixing any
related issues the researchers may not have thought of.

You have to accept Ian that security vulnerabilities _will_ be
discovered once people with new ways of looking at things get
interested in exploring VMS and you have to focus on managing
that process instead.

What is absolutely critical is the way in which the process is
managed. VSI and the VMS community _must_ conform to current
security research norms and cannot go around sticking it's head
in the sand and treating those researchers in the way the DEFCON
researchers were treated.

This means there is a very good chance that VMS exploits will be
reported in detail after giving the vendor a period of time to fix
them (ie: responsible disclosure) and that's exactly the way it
should be as this is the standard that everyone else is held to.
Responsible disclosure also gives longer term benefits in terms
of building a more robust product which is why this is the disclosure
protocol that I agree with.

This also means that processes _must_ be in place _before_ that first
exploit is discovered by the outside world in order to encourage
those researchers to follow the responsible disclosure protocol
instead of the full disclosure protocol (which is where the
researcher tells everyone else about it before giving the vendor
time to fix the issue.)

The VMS community cannot go around acting as if VMS is some special
snowflake that the rules everyone else has to follow don't apply
to VMS. If you want VMS to be taken seriously in today's world, you
need to show that VMS is being held to the same standards as everyone
else while still remaining secure. If VMS cannot achieve that, then
perhaps any security benefits VMS does offer is an illusion.

This also means the VMS community needs to learn the security
researcher's terminology and protocols (which are absolutely standard
in the security research world) and not the other way around.

Finding some VMS exploits will not in itself mean the end of VMS
but the way the exploits are managed may if the VMS world starts
treating VMS as some special snowflake in the light of the
discovery. For example, if some prat starts threating to sue
the researcher in order to stop disclosure of the exploit, then
the backlash from that will seriously damage VMS and may even
destroy it.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Kerry Main
2016-08-31 01:13:29 UTC
Permalink
-----Original Message-----
Behalf Of Simon Clubley via Info-vax
Sent: 30-Aug-16 8:28 PM
Cc: Simon Clubley
Subject: Re: [Info-vax] Should VSI create a security bug
bounty program for VMS ?
[snip...]
Post by IanD
I have gone from thinking OpenVMS is secure to
thinking that OpenVMS
Post by IanD
will certainly fall IMO from a focused attack in it's
current
state
Post by IanD
and anyone thinking otherwise is delusional. As they
say, the only
Post by IanD
reasonably safe system is one not connected to the
network at all.
Yes! Finally! Someone else gets it! :-)
Hey - you have obviously never watched the Mission
Impossible movie with Tom Cruise breaking into the sealed
CIA room.

:-)

The only real secure system is one that is powered off and
no access to power.

Course, a powered off system is also not a useable system
either, so this is where the trade-offs begin.
And yes, I know there are some people around here who
also get this
but there are times when I really do feel like I'm in a
minority of
one.
Post by IanD
I know VSI cannot fix 10 years of neglect of OpenVMS
in
an instant
Post by IanD
but there are some fundamental elements that you
don't want to get
Post by IanD
wrong going forward in the revamp and one is security.
If OpenVMS announces to the world it's back and on x86
and then gets
Post by IanD
hacked, we may as well all pack up our bags and go
home, I think a
Post by IanD
hack of OpenVMS at that critical stage will be the
be-all
and end-all
Post by IanD
of OpenVMS as past quaint notions of OpenVMS being a
sturgeon defense
Post by IanD
against attack will be put to rest forever.
Actually, VMS will survive some initial security
vulnerabilities
discovered by outsiders just fine provided the
disclosure
process
is managed properly and provided VSI demonstrate that
they have
learned from any such discoveries by looking for and
fixing
any
related issues the researchers may not have thought of.
You have to accept Ian that security vulnerabilities
_will_
be
discovered once people with new ways of looking at
things get
interested in exploring VMS and you have to focus on
managing
that process instead.
What is absolutely critical is the way in which the
process is
managed. VSI and the VMS community _must_ conform
to current
security research norms and cannot go around sticking
it's
head
in the sand and treating those researchers in the way
the
DEFCON
researchers were treated.
This means there is a very good chance that VMS exploits
will be
reported in detail after giving the vendor a period of
time
to fix
them (ie: responsible disclosure) and that's exactly the
way it
should be as this is the standard that everyone else is
held
to.
Responsible disclosure also gives longer term benefits
in
terms
of building a more robust product which is why this is
the
disclosure
protocol that I agree with.
This also means that processes _must_ be in place
_before_ that first
exploit is discovered by the outside world in order to
encourage
those researchers to follow the responsible disclosure
protocol
instead of the full disclosure protocol (which is where
the
researcher tells everyone else about it before giving
the
vendor
time to fix the issue.)
The VMS community cannot go around acting as if VMS is
some special
snowflake that the rules everyone else has to follow
don't
apply
to VMS. If you want VMS to be taken seriously in today's
world, you
need to show that VMS is being held to the same
standards as everyone
else while still remaining secure. If VMS cannot achieve
that, then
perhaps any security benefits VMS does offer is an
illusion.
This also means the VMS community needs to learn the
security
researcher's terminology and protocols (which are
absolutely standard
in the security research world) and not the other way
around.
Finding some VMS exploits will not in itself mean the
end
of VMS
but the way the exploits are managed may if the VMS
world starts
treating VMS as some special snowflake in the light of
the
discovery. For example, if some prat starts threating to
sue
the researcher in order to stop disclosure of the
exploit,
then
the backlash from that will seriously damage VMS and may
even
destroy it.
I also like the option to bring in external security
companies to try their latest cracking tools. It addresses
the biggie associated with sole source solutions - no
external eyes or testing.

However, we need to keep in mind there are 4 major pillars
to all secure solutions-
- Technology
- Process (training)
- People (awareness)
- Financial (everyone has a budget to meet)

If any one of these pillars breaks down, then the overall
secure solution is reduced.

While everyone likes to talk about the technology, a chain
is only as strong as the weakest link.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
IanD
2016-08-24 06:03:38 UTC
Permalink
Post by Simon Clubley
Post by IanD
Better to have a formal process for bug-reporting and security patching
BEFORE OpenVMS exists on easy to access hardware
I've just emailed my security bug reporting suggestion to VSI.
Post by IanD
Last thing we want in our journey to revamp OpenVMS is to have script kiddies
publishing on social media OpenVMS hacks!
You need to work on the assumption that this information will be published
in the same way as it is for all the other operating systems out there.
What we are looking for is responsible disclosure (ie: reporting the
exploit details _after_ VSI has a patch ready) instead of full
disclosure (which is reporting the details before VSI has been given
an opportunity to produce a patch).
As such VSI need to have a secure and easy to access way that allows
security researchers and the general VMS community to tell VSI about
security issues in VMS.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
I certainly wasn't advocating that security holes be yelled from the nearest rooftop :-)

That is why the bounty idea is a good one as would be an official security testers group who for their efforts get perhaps first shot at any patches as reward for their efforts

I just know that if a security hole is found by hackers, it will very quickly spread and that's the last thing we want for OpenVMS when it's trying to make a comeback

To start with OpenVMS may be able to hide under the radar somewhat because it is a low volume presence but when/if that profile starts to change, expect hackers to come knocking and probing

This is why it is so import to have these discussion now and establish a framework on how these things are to be dealt with rather than waiting until it's forced upon VSI by way of a knee-jerk reaction to a major event
Phillip Helbig (undress to reply)
2016-08-20 03:38:22 UTC
Permalink
Post by Simon Clubley
Post by Bob Gezelter
- A "bug bounty" program, where there is a reward system for new bugs
How important the bug bounty program is to someone depends on that
person. For myself it wouldn't really be a major factor as I would
report any issues found anyway. For others however, it could be the
motivation required for VSI to find out about a major bug in their
products in a controlled manner instead of finding out the hard way
when it becomes general knowledge. Certainly the bug bounty program
concept is growing so it's clearly seen as a good thing overall.
Back when patches were available to hobbyists, many hobbyists could and
did install patches, and some found bugs. No longer possible. Many
professional shops install only what they need, or what support
recommends, and often, as a matter of principle, nothing new---let
others find the bugs first.
Bob Gezelter
2016-08-15 17:47:08 UTC
Permalink
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
I think there could be a number of advantages to this, provided
people in the VMS community were prepared to deal with any bugs
found in a responsible manner and not shout down any reporters.
The correct model should be a Responsible Disclosure model IMHO
so that VSI get the chance to fix the problems but also so that
any issues found are not swept under the carpet and hidden. This
also means the VMS community can discuss the implications of any
issues found as they relate to the design of VMS.
Likewise I would expect any discovered issues to be assigned CVE
numbers rather than being silently fixed in a patch without
telling the world about the issue. That's the standard for other
products and it should be the standard for VMS as well.
I would suggest a 30 day disclosure target for simple issues to
60 days for more complex issues. If something exposes a complicated
design flaw in VMS (say for example you did something clever to
get to the kernel via RMS) then extending the disclosure period
to 4-6 months would be acceptable but this disclosure period
duration should only be used when justified by the specific issue.
The bug bounty program should only apply to products shipped by
VSI (including any layered products with security implications)
and not to any third party products such as WASD which are
downloaded by the end user.
Just to be clear: I'm not associated with VSI in any way. I just
want to see what the community thinks about this.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Simon,

VSI should (if they have not already) connect with the vulnerability reporting clearing groups (e.g., assignment of CVE indicies).

The "Bug Bounty" program is a separate question. More importantly, there should be a clear vulnerability reporting point of contact and mechanism. I understand that it is a potential drain on resources, but such a point of contact is necessary in the context of a system whose target market is critical computing. I would expect such a point of contact to commit to responding to reports within a specified time frame (NOTE: I am deliberately not saying "produce fixes"; what is more important is simply responding).

One can reasonably expect that the vulnerability point of contact will be on every CERT teams' virtual Rolodex, and should be managed accordingly.

- Bob Gezelter, http://www.rlgsc.com
Stephen Hoffman
2017-06-08 15:41:29 UTC
Permalink
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
"Kimber Dowsett on developing and maturing a vulnerability disclosure program
The O’Reilly Security Podcast: Key preparation before implementing a
vulnerability disclosure policy, the crucial role of setting scope, and
the benefits of collaborative relationships."

https://www.oreilly.com/ideas/kimber-dowsett-on-developing-and-maturing-a-vulnerability-disclosure-program


FWIW.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2017-06-08 19:19:15 UTC
Permalink
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
I liked Knuth's approach: pay a dollar for the first bug found, two for
the second, for for the third....
Simon Clubley
2017-06-09 17:38:30 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
"Kimber Dowsett on developing and maturing a vulnerability disclosure program
The O?Reilly Security Podcast: Key preparation before implementing a
vulnerability disclosure policy, the crucial role of setting scope, and
the benefits of collaborative relationships."
https://www.oreilly.com/ideas/kimber-dowsett-on-developing-and-maturing-a-vulnerability-disclosure-program
Right now, I would settle for VSI putting on its website the security
reporting mechanism that Clair said he wrote 6 months ago after I raised
the issue here in comp.os.vms.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
clair.grant@vmssoftware.com
2017-06-09 20:38:26 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
"Kimber Dowsett on developing and maturing a vulnerability disclosure program
The O?Reilly Security Podcast: Key preparation before implementing a
vulnerability disclosure policy, the crucial role of setting scope, and
the benefits of collaborative relationships."
https://www.oreilly.com/ideas/kimber-dowsett-on-developing-and-maturing-a-vulnerability-disclosure-program
Right now, I would settle for VSI putting on its website the security
reporting mechanism that Clair said he wrote 6 months ago after I raised
the issue here in comp.os.vms.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Just to be clear. I didn't write it. I pointed people at a few good examples and someone else did the work.
But you can still blame me if you don't like it when it finally appears. Comes with the territory.
Simon Clubley
2017-06-10 10:13:10 UTC
Permalink
Post by ***@vmssoftware.com
Post by Simon Clubley
Right now, I would settle for VSI putting on its website the security
reporting mechanism that Clair said he wrote 6 months ago after I raised
the issue here in comp.os.vms.
Just to be clear. I didn't write it. I pointed people at a few good examples
and someone else did the work.
Sorry for the misunderstanding.
Post by ***@vmssoftware.com
But you can still blame me if you don't like it when it finally appears.
To be honest, I don't really care what it looks like provided it does
the job. :-)

While VMS no longer has the market share it once had, it has become
_very_ clear there are still some very important customers using VMS.
Customers that may be of interest to the intelligence services.

Right now, because of what's going on over here, if I ever found
a security issue in VMS (and I still look sometimes when I want
a diversion from other hobby projects) there's a really good chance
I would not submit it to VSI but only to HPE along with a request
for HPE to send it to VSI via some secure means.

Whether HPE would actually do that is up to HPE.
Post by ***@vmssoftware.com
Comes with the territory.
:-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
u***@gmail.com
2017-06-09 21:01:10 UTC
Permalink
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
I think there could be a number of advantages to this, provided
people in the VMS community were prepared to deal with any bugs
found in a responsible manner and not shout down any reporters.
The correct model should be a Responsible Disclosure model IMHO
so that VSI get the chance to fix the problems but also so that
any issues found are not swept under the carpet and hidden. This
also means the VMS community can discuss the implications of any
issues found as they relate to the design of VMS.
Likewise I would expect any discovered issues to be assigned CVE
numbers rather than being silently fixed in a patch without
telling the world about the issue. That's the standard for other
products and it should be the standard for VMS as well.
I would suggest a 30 day disclosure target for simple issues to
60 days for more complex issues. If something exposes a complicated
design flaw in VMS (say for example you did something clever to
get to the kernel via RMS) then extending the disclosure period
to 4-6 months would be acceptable but this disclosure period
duration should only be used when justified by the specific issue.
The bug bounty program should only apply to products shipped by
VSI (including any layered products with security implications)
and not to any third party products such as WASD which are
downloaded by the end user.
Just to be clear: I'm not associated with VSI in any way. I just
want to see what the community thinks about this.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
THEY COULD, BUT IT WOULD NEVER PAY OUT ANYTHING ;)
Stephen Hoffman
2017-06-09 21:28:24 UTC
Permalink
Post by u***@gmail.com
THEY COULD, BUT IT WOULD NEVER PAY OUT ANYTHING ;)
Given I have a collection of CVEs that likely or do apply to OpenVMS
and to layered products, I'm... skeptical.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-06-10 00:37:09 UTC
Permalink
Post by u***@gmail.com
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
I think there could be a number of advantages to this, provided
people in the VMS community were prepared to deal with any bugs
found in a responsible manner and not shout down any reporters.
The correct model should be a Responsible Disclosure model IMHO
so that VSI get the chance to fix the problems but also so that
any issues found are not swept under the carpet and hidden. This
also means the VMS community can discuss the implications of any
issues found as they relate to the design of VMS.
Likewise I would expect any discovered issues to be assigned CVE
numbers rather than being silently fixed in a patch without
telling the world about the issue. That's the standard for other
products and it should be the standard for VMS as well.
I would suggest a 30 day disclosure target for simple issues to
60 days for more complex issues. If something exposes a complicated
design flaw in VMS (say for example you did something clever to
get to the kernel via RMS) then extending the disclosure period
to 4-6 months would be acceptable but this disclosure period
duration should only be used when justified by the specific issue.
The bug bounty program should only apply to products shipped by
VSI (including any layered products with security implications)
and not to any third party products such as WASD which are
downloaded by the end user.
Just to be clear: I'm not associated with VSI in any way. I just
want to see what the community thinks about this.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
THEY COULD, BUT IT WOULD NEVER PAY OUT ANYTHING ;)
Hey Bob, when you gonna post the IP address and non-prived user account
information. No problem, right, since you cannot be hacked, right?
Paul Sture
2017-06-10 08:15:47 UTC
Permalink
Post by David Froble
Post by u***@gmail.com
THEY COULD, BUT IT WOULD NEVER PAY OUT ANYTHING ;)
Hey Bob, when you gonna post the IP address and non-prived user account
information. No problem, right, since you cannot be hacked, right?
:-)
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Simon Clubley
2017-06-10 09:50:12 UTC
Permalink
Post by u***@gmail.com
THEY COULD, BUT IT WOULD NEVER PAY OUT ANYTHING ;)
The evidence says otherwise.

BTW Bob, it's 2017. You no longer need to use an ASR-33 to compose
your postings.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
u***@gmail.com
2017-06-10 12:21:28 UTC
Permalink
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
I think there could be a number of advantages to this, provided
people in the VMS community were prepared to deal with any bugs
found in a responsible manner and not shout down any reporters.
The correct model should be a Responsible Disclosure model IMHO
so that VSI get the chance to fix the problems but also so that
any issues found are not swept under the carpet and hidden. This
also means the VMS community can discuss the implications of any
issues found as they relate to the design of VMS.
Likewise I would expect any discovered issues to be assigned CVE
numbers rather than being silently fixed in a patch without
telling the world about the issue. That's the standard for other
products and it should be the standard for VMS as well.
I would suggest a 30 day disclosure target for simple issues to
60 days for more complex issues. If something exposes a complicated
design flaw in VMS (say for example you did something clever to
get to the kernel via RMS) then extending the disclosure period
to 4-6 months would be acceptable but this disclosure period
duration should only be used when justified by the specific issue.
The bug bounty program should only apply to products shipped by
VSI (including any layered products with security implications)
and not to any third party products such as WASD which are
downloaded by the end user.
Just to be clear: I'm not associated with VSI in any way. I just
want to see what the community thinks about this.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
if you keep referring to dec tcpip then maybe, but
I am referring to tcpware multinet process software
which changes the equation ;)
Kerry Main
2017-06-10 14:17:58 UTC
Permalink
-----Original Message-----
ultradwc--- via Info-vax
Sent: June 10, 2017 8:21 AM
Subject: Re: [Info-vax] Should VSI create a security bug bounty program
for VMS ?
Post by Simon Clubley
Should VSI create a security bug bounty program for VMS ?
I think there could be a number of advantages to this, provided
people in the VMS community were prepared to deal with any bugs
found in a responsible manner and not shout down any reporters.
The correct model should be a Responsible Disclosure model IMHO
so that VSI get the chance to fix the problems but also so that
any issues found are not swept under the carpet and hidden. This
also means the VMS community can discuss the implications of any
issues found as they relate to the design of VMS.
Likewise I would expect any discovered issues to be assigned CVE
numbers rather than being silently fixed in a patch without
telling the world about the issue. That's the standard for other
products and it should be the standard for VMS as well.
I would suggest a 30 day disclosure target for simple issues to
60 days for more complex issues. If something exposes a complicated
design flaw in VMS (say for example you did something clever to
get to the kernel via RMS) then extending the disclosure period
to 4-6 months would be acceptable but this disclosure period
duration should only be used when justified by the specific issue.
The bug bounty program should only apply to products shipped by
VSI (including any layered products with security implications)
and not to any third party products such as WASD which are
downloaded by the end user.
Just to be clear: I'm not associated with VSI in any way. I just
want to see what the community thinks about this.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
if you keep referring to dec tcpip then maybe, but
I am referring to tcpware multinet process software
which changes the equation ;)
Definitely have to agree on this point. Multinet is multiple years ahead of the native TCPIP stack.

I use Multinet on all my home lab systems.

Asking why would someone use the native free OpenVMS stack vs a commercial option like Multinet is like asking why does no one in business use the native Windows server backup utility.

Almost all businesses use a commercial option for Windows backup.

Bottom line - yes, other platforms offer free stacks as well, but Multinet is a much (ok, much, much) better IP stack than the native OpenVMS stack and great news for the new VSI stack coming soon.

For those that take security seriously, then other products like System Detective from PointSecure should be core baseline addons for your environment.

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-06-10 15:09:02 UTC
Permalink
Post by Kerry Main
-----Original Message-----
ultradwc--- via Info-vax
Sent: June 10, 2017 8:21 AM
Subject: Re: [Info-vax] Should VSI create a security bug bounty program
for VMS ?
if you keep referring to dec tcpip then maybe, but
I am referring to tcpware multinet process software
which changes the equation ;)
While VMS desperately needs a TCP/IP stack which brings it up to the
standards of other operating systems, that is only one very small part
of the security ecosystem.

Any network facing applications running on top of this stack can have
their own vulnerabilities and if you don't have isolation capabilities
(either MAC style or something else) then it's easier for them to
compromise the system.

Once you get down into vulnerabilities within VMS itself, it doesn't
really matter how you got there. You can do privilege escalation just
fine regardless of whether you logged in over DECnet, LAT, UCX or Multinet.
Post by Kerry Main
Definitely have to agree on this point. Multinet is multiple years ahead of
the native TCPIP stack.
I use Multinet on all my home lab systems.
Asking why would someone use the native free OpenVMS stack vs a commercial
option like Multinet is like asking why does no one in business use the
native Windows server backup utility.
A closer comparison would be the network stacks on other operating systems
and strangely enough, no-one feels the need to replace the supplied Linux
TCP/IP stack with a paid for version.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Kerry Main
2017-06-10 15:35:17 UTC
Permalink
-----Original Message-----
Simon Clubley via Info-vax
Sent: June 10, 2017 11:09 AM
Subject: Re: [Info-vax] Should VSI create a security bug bounty program
for VMS ?
Post by Kerry Main
-----Original Message-----
ultradwc--- via Info-vax
Sent: June 10, 2017 8:21 AM
Subject: Re: [Info-vax] Should VSI create a security bug bounty
program
Post by Kerry Main
for VMS ?
if you keep referring to dec tcpip then maybe, but
I am referring to tcpware multinet process software
which changes the equation ;)
While VMS desperately needs a TCP/IP stack which brings it up to the
standards of other operating systems, that is only one very small part
of the security ecosystem.
Any network facing applications running on top of this stack can have
their own vulnerabilities and if you don't have isolation capabilities
(either MAC style or something else) then it's easier for them to
compromise the system.
Once you get down into vulnerabilities within VMS itself, it doesn't
really matter how you got there. You can do privilege escalation just
fine regardless of whether you logged in over DECnet, LAT, UCX or Multinet.
Security is only as strong as its weakest link.

The new TCPIP stack goes a long way to address the lower connect layer.

Of course, there are other areas to address - no one said there wasn't.
Post by Kerry Main
Definitely have to agree on this point. Multinet is multiple years
ahead
of
Post by Kerry Main
the native TCPIP stack.
I use Multinet on all my home lab systems.
Asking why would someone use the native free OpenVMS stack vs a
commercial
Post by Kerry Main
option like Multinet is like asking why does no one in business use the
native Windows server backup utility.
A closer comparison would be the network stacks on other operating systems
and strangely enough, no-one feels the need to replace the supplied Linux
TCP/IP stack with a paid for version.
Simon.
How many Linux or Windows business Customers use the native backup
utility?

Most (even power desktop users) use a commercial option which, surprise,
surprise costs $. Not just in terms of licenses, but also in terms of
these same Linux/Windows Customers having to do their own compatibility
testing with each new backup agent release.

Many OpenVMS Customers are happy with the native OpenVMS backup utility.

Btw, the new VSI stack will be included with the OS licensing/support
model.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-06-10 16:01:34 UTC
Permalink
Post by Kerry Main
How many Linux or Windows business Customers use the native backup
utility?
Most (even power desktop users) use a commercial option which, surprise,
surprise costs $. Not just in terms of licenses, but also in terms of
these same Linux/Windows Customers having to do their own compatibility
testing with each new backup agent release.
Many OpenVMS Customers are happy with the native OpenVMS backup utility.
What has backup got to do with a TCP/IP stack ?

However, if the intent is to compare free versus paid for features,
then one might as equally well ask how many people used paid for
programming languages on Linux versus the free options.

Many Linux customers are happy with the fully featured free programming
language options available on Linux.

However, that also doesn't have anything to do with TCP/IP stacks.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Scott Dorsey
2017-06-10 16:21:13 UTC
Permalink
Post by Simon Clubley
Post by Kerry Main
How many Linux or Windows business Customers use the native backup
utility?
Under Linux, everybody does. They might use some commercial software, but
if you look closely you'll find that commercial software is really just a
front end to dump or tar.

Under Windows, for a long time there wasn't one, and so nobody did. Now
there is one, but it's not mature enough to really use yet. After a while
people might start using it, but many companies are using commercial systems
that jumped in to fill the void because there was no native utility and which
they are continuing to use from inertia.
Post by Simon Clubley
Post by Kerry Main
Most (even power desktop users) use a commercial option which, surprise,
surprise costs $. Not just in terms of licenses, but also in terms of
these same Linux/Windows Customers having to do their own compatibility
testing with each new backup agent release.
In the case of Linux, folks mostly do this because they want a fancy gui
or they want support for proprietary hardware (either proprietary disk
farms that are being backed up or proprietary tape stackers to put backups
on, or the like).
Post by Simon Clubley
Post by Kerry Main
Many OpenVMS Customers are happy with the native OpenVMS backup utility.
What has backup got to do with a TCP/IP stack ?
Nothing at all as far as I can tell. But, we are living now in the
post-4.3BSD world where people expect the IP stack to be integrated into
the OS kernel. Some arguments can be made that this is less than optimal
for security but critical for performance.
Post by Simon Clubley
However, if the intent is to compare free versus paid for features,
then one might as equally well ask how many people used paid for
programming languages on Linux versus the free options.
Many Linux customers are happy with the fully featured free programming
language options available on Linux.
The people who are using commercial compilers on Linux are either using
them because they are developing in a minority language that is not widely
supported, or because they need performance features that aren't available
in the conventional compilers.

But.... as the gnu compiler kit gets better and better every day, the demand
for commercial compilers is slowly evaporating. A decade ago, g77 was
abominable and if you cared at all about performance and debugging you spent
the money for ifort or the portland group compiler. Today, gfortran is
as fast as ifort and has most of the modern features people expect.

That said... I have one customer who keeps using an alpha with OSF/1 just
because the DEC fortran compiler delivers the best error messages for
clean debugging. They don't actually run on the Alpha, but they keep using
it as a debugging tool. If gfortran gave as good error messages, they'd
dump the Alpha in a minute.
Post by Simon Clubley
However, that also doesn't have anything to do with TCP/IP stacks.
Yes, the IP stack is a special case, being as tightly integrated with the
kernel as a filesystem would be. Maybe even more so.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Kerry Main
2017-06-10 16:59:31 UTC
Permalink
-----Original Message-----
Simon Clubley via Info-vax
Sent: June 10, 2017 12:02 PM
Subject: Re: [Info-vax] Should VSI create a security bug bounty program
for VMS ?
Post by Kerry Main
How many Linux or Windows business Customers use the native
backup
Post by Kerry Main
utility?
Most (even power desktop users) use a commercial option which,
surprise,
Post by Kerry Main
surprise costs $. Not just in terms of licenses, but also in terms of
these same Linux/Windows Customers having to do their own
compatibility
Post by Kerry Main
testing with each new backup agent release.
Many OpenVMS Customers are happy with the native OpenVMS
backup utility.
What has backup got to do with a TCP/IP stack ?
However, if the intent is to compare free versus paid for features,
then one might as equally well ask how many people used paid for
programming languages on Linux versus the free options.
Many Linux customers are happy with the fully featured free
programming
language options available on Linux.
However, that also doesn't have anything to do with TCP/IP stacks.
Simon.
The point is that every platform has some native features which its user
community is either happy with or not. If not happy with a feature or
capability, they often decide to add a commercial option to take
advantage of additional features.

As I indicated, the new VSI stack will be integrated, so talking about
the limitations of the current OpenVMS native IP stack is moot and will
soon be a historical discussion.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Loading...