On 8/4/2022 10:10 AM, Dan Cross wrote:
> In article <tcc5ih$ues$1@news.misty.com>,
> Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-08-02 16:33, Dan Cross wrote:
>>> It boggles my mind that people think that an organization that
>>> has explicitly declined to work with the VAX (for the very valid
>>> reasons mentioned elsewhere in this thread) would care if a few
>>> hobbyists run an OS, 20 years out of maintenance, they can't
>>> issue licenses for anyway.
>>>
>>> Maybe those people have the inside track with someone at at VSI
>>> who has told them that this is as big a deal as they are making
>>> it out to be, but I find that doubtful.
>>
>> I doubt it's the talking point of the day for VSI. But never the less,
>> there is a point in observing how people behave in similar situations to
>> deduce how they might behave elsewhere.
>>
>> Bill did make a good point about the non-existence of hobbyist program
>> for the PDP-11 software, which allegedly is because people were
>> misbehaving. And VSI might look at how people behave around the VAX and
>> decide how they want to continue hobbyist stuff for the platforms they
>> have made releases for.
>
> The bottom line is that absent some definitive statement from
> VSI, this is all speculation.

True.

But the day it is no longer speculation then it is too late.

It is a risk.

You could certainly argue that people willing to take a risk on
their own behalf should be allowed to do so, but here the risk applies
to the entire community.

So people are not going to the casino and betting just their
own savings - people are going to the casino and betting their
own plus everybody elses savings.

Arne

On 8/4/2022 5:22 PM, abrsvc wrote:
> On Thursday, August 4, 2022 at 4:48:23 PM UTC-4, Bill Gunshannon wrote:
>>> On 8/4/2022 1:26 PM, Simon Clubley wrote:
>>>> On 2022-08-04, Dave Froble <da...@tsoft-inc.com> wrote:
>>>>> I asked from a moral perspective. So far I detect no sympathy for
>>>>> people who
>>>>> might be in a bad place. I for one find that sad.
>>>>
>>>> These days, it is the responsibility of the organisation which has
>>>> chosen to remain on an old out of support OS version (for whatever
>>>> reason) to make sure there is enough protection around that system
>>>> to protect it from future vulnerabilities.

>> He is right. This business has had plenty of time to
>> anticipate and correct the problem. The real question is why they
>> have chosen not to.

> I would take a different approach. If the system is working and
> working well in what seems to be a secure environment, why would I
> "upgrade" to a system that is more likely than not, less secure than
> what I have?
I do not see why you consider it "more likely than not".

Software that has been in production for some years tend to
have bugs including security bugs fixed.

But the focus on security has increased dramatically over
time so modern software has been designed with way more
focus on security than ancient software.

I think the realistic expectation for number of
security vulnerabilities as a function of software age
is f''(t)>0 with a minimum in the 3-5 year range.

> A backend system processing information sent over a single secure
> line from a front facing system where the environment is less secure
> works just fine. If there is no way to get to the backend system
> other than the pipe from the front end, where is the security hole?
> Could a malformed packet cause a problem, sure but compromise the
> data on the backend, not likely. In this case, it wouldn't make a
> difference how old the system is.
I believe the IT security history is full of stories about
systems with no access and then suddenly it turned out
there were access.

There is such a thing as insider threats.

> In the emulated environment, it is the host that has the security
> problems and not the OpenVMS system.

The host covers a few security problems, but the VMS system certainly
has to cover most security problems.

Arne

On Thursday, August 4, 2022 at 3:31:35 PM UTC-7, Don North wrote:

(snip)

> If you put those cans out by the street they become public domain.
> Unless you have locks on the cans. Not likely.
> If the trash company must enter your property to collect, then not.
> Redirect complaints to SCOTUS.

I know that is true for information contained in the trash.
I am not sure it is for things with physical value.

Among others, that was part of the BALCO steroids bust:
https://www.taipeitimes.com/News/sport/archives/2004/02/14/2003098779

On 8/4/2022 6:07 PM, gah4 wrote:
> On Thursday, August 4, 2022 at 2:22:37 PM UTC-7, abrsvc wrote:
>> In the emulated environment, it is the host that has the security problems and not the OpenVMS system. Odd, no?
>
> One of the more interesting, or maybe just more surprising, attacks is SQL injection.
>
> Many attacks convince a machine to run some executable code, but SQL injection is done at a higher level.

SQL injection and XSS injection are very common problems.

> I have had web sites return SQL error messages before, which is sort of funny.

:-)

Arne

On 8/4/2022 8:29 AM, Simon Clubley wrote:
> On 2022-08-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/3/2022 11:48 AM, chris wrote:
>>> On 08/03/22 13:55, abrsvc wrote:
>>>> Running older versions of software that perform well for the task at
>>>> hand is not necessarily a problem.
>>>> Please note that VMS does NOT have the same problems that Windows does
>>>> in terms of viruses.  And the vulnerability that you seem to draw out
>>>> for every argument REQUIRES that the person already be logged in to
>>>> the VMS system in order to access it. Not the same as most of the
>>>> vulnerabilities reported for Windows.
>>>
>>> May have been true years ago, when vms ran on non X86 hardware, but
>>> not the case now. Unless vms has strong protections at system level,
>>> it could be just as vulnerable as any other X86 based system. Once an
>>> attacker with sufficient resources and time to get a X86 binary onto
>>> the system, all bets are off.
>>>
>>> X86 architecture is possibly the worst possible architecture to build
>>> a secure system with...
>>
>> The percentage of security vulnerabilities that has a directly
>> dependency on the ISA must very small.
>
> Well, in fairness to Chris, while he clearly has an ideological dislike
> for x86-64 for whatever reasons, this is also the architecture that has
> all the Intel Management Engine and other management stuff running on
> modern versions of that architecture.
>
> Stuff that runs underneath your operating system and can't be switched off.

ME are not really ISA specific.

ME is AFAIK only available for x86-64 chipsets.

But you could design an Alpha with ME - it comes with its
own CPU and OS.

Arne

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Dan Cross via
> Info-vax
> Sent: August-04-22 7:08 PM
> To: info-vax@rbnsn.com
> Cc: Dan Cross <cross@spitfire.i.gajendra.net>
> Subject: Re: [Info-vax] VMS VAX License for personal Microvax 3100 Model
> 40
>
> In article <tcgp5e$2rgld$1@dont-email.me>, Dave Froble <davef@tsoft-
> inc.com> wrote:
> >[snip]
> >I asked from a moral perspective. So far I detect no sympathy for
> >people who might be in a bad place. I for one find that sad.
>
> The thing is, those folks are in a bad place whether they know it or not.
> Ancient versions of VMS probably have exploitable flaws that are known to
> state-level actors and others beyond the script-kiddies. Just because the
> operator of some application hosted on some ancient version of VMS
> doesn't know that doesn't make them safe. They may exist in a state of
> blissful ignorance and still be vulnerable.
>
> Now the calculus changes: is it better for the flaws to be known publicly
or
> not, given that they may exist and may be actively exploitable? Would you
> rather know you had terminal cancer? Is it moral for a doctor to tell
you?
>
> - Dan C.
>

Well, you can substitute OpenVMS in that statement with any OS. Lots of W2K8
and old versions of Linux, Solaris, AIX, HP-UX etc. around big datacenters
today.

The issue of old OS support is not specific to OpenVMS.

In many, likely most, OPS teams know the issues with old OS version support.

However - App vendors gone out of business, dropped App support,
knowledgeable staff long since retired / laid off .. just many of the
reasons why some Customers have App's on very old OS versions still running.

Yes, one might ask "why not spend the $'s into replacing that App?", but if
the Senior Mgrs have no budget, then OPS teams are left to protect that
environment with whatever tools they have e.g. put in firewall zone and
restrict flows and other means.

Unless one has spent time in OPS support dealing with on-the-floor
realities, one should not be to quick to criticize these folks.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 8/4/2022 10:53 AM, Mark Berryman wrote:
> On 8/3/22 11:30 AM, Simon Clubley wrote:
>> This isn't a discussion about the DCL vulnerability. It's a discussion
>> about what is likely to happen if security researchers take a serious
>> interest in probing VMS in general and find a series of vulnerabilities
>> which they then disclose in public after giving VSI time (about 3 months
>> usually) to fix the vulnerabilities.
>>
>> Your last sentence above is a perfect example of the mindset I am
>> warning about.
>
> Simon's assumption is that, because he found a vulnerability, there must
> be a multitude of other as yet undiscovered vulnerabilities lying in
> wait because VMS just hasn't seen the kind of security probing that
> other OSes have.  He makes this assumption clear in many of his posts.
>
> His assumption is unfounded.
>
> Simon has no idea what sort of security testing various organizations
> have done to VMS, especially by those that needed to have confidence in
> the platform's security before deploying it in a security-demanding
> environment.  He also has no idea of what security-related SPRs were
> sent to Digital, or of the issues that were found and fixed strictly
> internally.
>
> Having been a part of such testing, I think I have a better
> understanding of the situation than Simon does.  I will state here that
> such testing is why I have such definite opinions on running Multinet
> vs. TCPIP Services if one is concerned about security.  I really hope
> the version VSI is releasing addresses these issues.  I will also state
> that I have run VMS systems wide-open to the Internet, something I would
> not do with any other platform.  They invited attacks and definitely
> received them.  They were heavily probed but never penetrated even
> though they ran services that are typically vulnerable on other
> platforms such as web services (WASD, not Apache) and anonymous FTP.
> They even ran *gasp* DECnet (phase V).
>
> The truth is, there have been security issues found within VMS.  Some of
> them were never known by the public.  Once found, they tended to be
> fixed very quickly (which is all you can ask of any platform), which has
> not always been the case in other now more popular platforms.  However,
> the idea that VMS is a rickety platform just waiting to be exploited
> once security researchers "finally" start seriously probing it is just
> plain ridiculous.

It seems very plausible that DEC, to some extent Compaq and HP,
US DoD, NSA and a bunch of big companies that relied (or still
relying) on VMS did extensive security testing. That makes sense.

But it does not seem plausible that they tested VMS to the
same extent as Linux and Windows are beeing tested today. The
money and the people was not there (US DoD and NSA may have had
the money, but they had many other priorities).

The number of people involved in security research today is
huge. I don't know how many, but it must be in the tens of
thousands of people.

But no I do not expect those tens of thousands to get any
interest in VMS due to the arrival of VMS x86-64 or whatever
VSI web site contain. The money is still not there.

Arne

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: August-04-22 8:56 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] VMS VAX License for personal Microvax 3100 Model
> 40
>
> On 8/4/2022 5:22 PM, abrsvc wrote:
> > On Thursday, August 4, 2022 at 4:48:23 PM UTC-4, Bill Gunshannon wrote:
> >>> On 8/4/2022 1:26 PM, Simon Clubley wrote:
> >>>> On 2022-08-04, Dave Froble <da...@tsoft-inc.com> wrote:
> >>>>> I asked from a moral perspective. So far I detect no sympathy for
> >>>>> people who might be in a bad place. I for one find that sad.
> >>>>
> >>>> These days, it is the responsibility of the organisation which has
> >>>> chosen to remain on an old out of support OS version (for whatever
> >>>> reason) to make sure there is enough protection around that system
> >>>> to protect it from future vulnerabilities.
>
> >> He is right. This business has had plenty of time to
> >> anticipate and correct the problem. The real question is why they
> >> have chosen not to.
>
> > I would take a different approach. If the system is working and
> > working well in what seems to be a secure environment, why would I
> > "upgrade" to a system that is more likely than not, less secure than
> > what I have?
> I do not see why you consider it "more likely than not".
>
> Software that has been in production for some years tend to have bugs
> including security bugs fixed.
>
> But the focus on security has increased dramatically over time so modern
> software has been designed with way more focus on security than ancient
> software.
>
> I think the realistic expectation for number of security vulnerabilities
as a
> function of software age is f''(t)>0 with a minimum in the 3-5 year range.
>
> > A backend system processing information sent over a single secure line
> > from a front facing system where the environment is less secure works
> > just fine. If there is no way to get to the backend system other than
> > the pipe from the front end, where is the security hole?
> > Could a malformed packet cause a problem, sure but compromise the data
> > on the backend, not likely. In this case, it wouldn't make a
> > difference how old the system is.
> I believe the IT security history is full of stories about systems with no
access
> and then suddenly it turned out there were access.
>
> There is such a thing as insider threats.
>
> > In the emulated environment, it is the host that has the security
> > problems and not the OpenVMS system.
>
> The host covers a few security problems, but the VMS system certainly has
> to cover most security problems.
>
> Arne
>

While any virtual OS certainly needs to be able to protect itself, one of
the big disadvantages of virtual systems is the increased ADDITIONAL
security risks posed by the virtual platform.

As example, just a sample reference:
<https://www.vmware.com/ca/security/advisories.html>

And semi-related - there are many VMWare environments in DC's still running
really old versions of VMWare. This includes old versions of VMWare Tools
(VMware mgmt. process running on each virtual host).

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 8/4/2022 8:09 PM, Kerry Main wrote:
> Well, you can substitute OpenVMS in that statement with any OS. Lots of W2K8
> and old versions of Linux, Solaris, AIX, HP-UX etc. around big datacenters
> today.
>
> The issue of old OS support is not specific to OpenVMS.

And it is not just old OS.

Old databases. Old application servers. Old compilers/libraries/runtimes.

> In many, likely most, OPS teams know the issues with old OS version support.
>
> However - App vendors gone out of business, dropped App support,
> knowledgeable staff long since retired / laid off .. just many of the
> reasons why some Customers have App's on very old OS versions still running.
>
> Yes, one might ask "why not spend the $'s into replacing that App?", but if
> the Senior Mgrs have no budget, then OPS teams are left to protect that
> environment with whatever tools they have e.g. put in firewall zone and
> restrict flows and other means.
>
> Unless one has spent time in OPS support dealing with on-the-floor
> realities, one should not be to quick to criticize these folks.

Definitely not fair to blame OPS.

The responsibility belongs to senior management.

Arne

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: August-04-22 9:28 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] VMS VAX License for personal Microvax 3100 Model
> 40
>
> On 8/4/2022 10:53 AM, Mark Berryman wrote:
> > On 8/3/22 11:30 AM, Simon Clubley wrote:
> >> This isn't a discussion about the DCL vulnerability. It's a
> >> discussion about what is likely to happen if security researchers
> >> take a serious interest in probing VMS in general and find a series
> >> of vulnerabilities which they then disclose in public after giving
> >> VSI time (about 3 months
> >> usually) to fix the vulnerabilities.
> >>
> >> Your last sentence above is a perfect example of the mindset I am
> >> warning about.
> >
> > Simon's assumption is that, because he found a vulnerability, there
> > must be a multitude of other as yet undiscovered vulnerabilities lying
> > in wait because VMS just hasn't seen the kind of security probing that
> > other OSes have. He makes this assumption clear in many of his posts.
> >
> > His assumption is unfounded.
> >
> > Simon has no idea what sort of security testing various organizations
> > have done to VMS, especially by those that needed to have confidence
> > in the platform's security before deploying it in a security-demanding
> > environment. He also has no idea of what security-related SPRs were
> > sent to Digital, or of the issues that were found and fixed strictly
> > internally.
> >
> > Having been a part of such testing, I think I have a better
> > understanding of the situation than Simon does. I will state here
> > that such testing is why I have such definite opinions on running
> > Multinet vs. TCPIP Services if one is concerned about security. I
> > really hope the version VSI is releasing addresses these issues. I
> > will also state that I have run VMS systems wide-open to the Internet,
> > something I would not do with any other platform. They invited
> > attacks and definitely received them. They were heavily probed but
> > never penetrated even though they ran services that are typically
> > vulnerable on other platforms such as web services (WASD, not Apache)
> and anonymous FTP.
> > They even ran *gasp* DECnet (phase V).
> >
> > The truth is, there have been security issues found within VMS. Some
> > of them were never known by the public. Once found, they tended to be
> > fixed very quickly (which is all you can ask of any platform), which
> > has not always been the case in other now more popular platforms.
> > However, the idea that VMS is a rickety platform just waiting to be
> > exploited once security researchers "finally" start seriously probing
> > it is just plain ridiculous.
>
> It seems very plausible that DEC, to some extent Compaq and HP, US DoD,
> NSA and a bunch of big companies that relied (or still
> relying) on VMS did extensive security testing. That makes sense.
>
> But it does not seem plausible that they tested VMS to the same extent as
> Linux and Windows are beeing tested today. The money and the people was
> not there (US DoD and NSA may have had the money, but they had many
> other priorities).
>
> The number of people involved in security research today is huge. I don't
> know how many, but it must be in the tens of thousands of people.
>
> But no I do not expect those tens of thousands to get any interest in VMS
> due to the arrival of VMS x86-64 or whatever VSI web site contain. The
> money is still not there.
>
> Arne
>

re: past Customers putting OpenVMS through the ringer from a security perspective..

In approx. 2005 timeframe, the Shanghai Stock Exchange dropped their previous mission critical trading platform for what they called their "Next Generation" trading platform that was based on an OpenVMS Integrity based multi-site cluster. Disclosure - I do not know if this platform is still in place or not.

Btw, at the time, some predicted the Shanghai Stock Exchange might eventually replace the NYSE in terms of WW importance.

Does anyone think this next generation trading platform based on OpenVMS Integrity was not put through many, many security scenarios before this final decision was made?

Reference:
<https://blog.csdn.net/bjoker/article/details/1890554>
<https://community.hpe.com/t5/Operating-System-OpenVMS/OpenVMS-in-China/td-p/4655695#.YuxphxzMJhE>

Btw, it was kind of ironic, but the OS environment supporting their old platform that OpenVMS replaced was HP-UX. 😊

Course, at the time, HP internal politics meant that this big "Integrity win" could not be marketed much (HP-UX was the "golden child"), but that was the state of HP OS religion at the time.

Ah well, water under the bridge stuff ..

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On Friday, August 5, 2022 at 11:31:51 AM UTC+12, Arne Vajhøj wrote:
> On 8/4/2022 10:10 AM, Dan Cross wrote:
> > In article <tcc5ih$ues$1...@news.misty.com>,
> > Johnny Billquist <b...@softjar.se> wrote:
> >> On 2022-08-02 16:33, Dan Cross wrote:
> >>> It boggles my mind that people think that an organization that
> >>> has explicitly declined to work with the VAX (for the very valid
> >>> reasons mentioned elsewhere in this thread) would care if a few
> >>> hobbyists run an OS, 20 years out of maintenance, they can't
> >>> issue licenses for anyway.
> >>>
> >>> Maybe those people have the inside track with someone at at VSI
> >>> who has told them that this is as big a deal as they are making
> >>> it out to be, but I find that doubtful.
> >>
> >> I doubt it's the talking point of the day for VSI. But never the less,
> >> there is a point in observing how people behave in similar situations to
> >> deduce how they might behave elsewhere.
> >>
> >> Bill did make a good point about the non-existence of hobbyist program
> >> for the PDP-11 software, which allegedly is because people were
> >> misbehaving. And VSI might look at how people behave around the VAX and
> >> decide how they want to continue hobbyist stuff for the platforms they
> >> have made releases for.
> >
> > The bottom line is that absent some definitive statement from
> > VSI, this is all speculation.
> True.
>
> But the day it is no longer speculation then it is too late.
>
> It is a risk.
>
> You could certainly argue that people willing to take a risk on
> their own behalf should be allowed to do so, but here the risk applies
> to the entire community.
>
> So people are not going to the casino and betting just their
> own savings - people are going to the casino and betting their
> own plus everybody elses savings.

Its not a risk. The community license is necessary for the viability
of OpenVMS as a platform. If VSI takes it away that's them saying
they see no future for OpenVMS and therefore no need to increase
the number of people with OpenVMS skills.

And if there is no future for OpenVMS then those temporary
community licenses are going away sooner or later whether people
use VAX/VMS without a license or not.

On 8/4/2022 3:56 PM, Bill Gunshannon wrote:
> On 8/4/22 15:01, Dave Froble wrote:
>> On 8/4/2022 11:56 AM, Dave Froble wrote:
>>> On 8/4/2022 10:12 AM, Dan Cross wrote:
>>>> In article <62e9b4ec$0$699$14726298@news.sunsite.dk>,
>>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 8/2/2022 10:33 AM, Dan Cross wrote:
>>>>>> In article <tc1d87$tnl$1@news.misty.com>,
>>>>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>>>>> On 2022-07-26 13:32, Dan Cross wrote:
>>>>>>>> But again, why should VSI care? They have nothing to do
>>>>>>>> with VAX. If people started doing this for Alpha, Itanium
>>>>>>>> or x86, I could see it since VSI has interest in those
>>>>>>>> platforms. But VAX is explicitly out of their domain.
>>>>>>>
>>>>>>> I should point out that VSI have nothing to do with VAX out of choice.
>>>>>>> They could technically make a VAX release if they wanted to. They do
>>>>>>> have the rights, and the code.
>>>>>>
>>>>>> A fair point, but regardless, they have chosen not to care.
>>>>>>
>>>>>> It boggles my mind that people think that an organization that
>>>>>> has explicitly declined to work with the VAX (for the very valid
>>>>>> reasons mentioned elsewhere in this thread) would care if a few
>>>>>> hobbyists run an OS, 20 years out of maintenance, they can't
>>>>>> issue licenses for anyway.
>>>>>>
>>>>>> Maybe those people have the inside track with someone at at VSI
>>>>>> who has told them that this is as big a deal as they are making
>>>>>> it out to be, but I find that doubtful.
>>>>>
>>>>> It is quite common to suspect that people known to be willing to
>>>>> break one law is more willing to break another law.
>>>>>
>>>>> Most people would not let their daughter go on a date with
>>>>> a convicted bank robber - even though the daughter is obviously
>>>>> not a bank.
>>>>
>>>> This is very much a strawman. A better analogy might be, if
>>>> someone picks something out of the trash and gets it working
>>>> again, is that technically theft?
>>>>
>>>> - Dan C.
>>>>
>>>
>>> Yes !!!
>>>
>>
>> Uh, not yes as in it is theft. Yes as in a great example. I should re-read
>> what I type several times before hitting the SEND button.
>>
>
> Sorry Dave, you were right the first time. It is theft and
> has been upheld by the courts in most states.
>
> bill
>

Ok, theft from whom?

The people who put something out as trash?
The trash haulers?
The landfill?

How about referring me to some of those cases. Cause I'm flat not believing you.

Any judge who would rule like that deserves what the current supreme court
deserves, impeachment.

The very thought is preposterous.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 8/4/2022 4:00 PM, Simon Clubley wrote:
> On 2022-08-04, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 8/4/2022 1:26 PM, Simon Clubley wrote:
>>> On 2022-08-04, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> David and Simon insist on making other people's decisions for them. Sort of
>>>> "devil take the hindmost" if their solutions are not followed. Even if there
>>>> are some who might be aware, publishing the problem will insure many will then
>>>> know about it. And it might be totally unknown, until David/Simon publish it to
>>>> the entire world.
>>>>
>>>
>>> No, Simon believes in following industry-standard protocols, which are
>>> give the vendor 3 months to fix it and then reveal the details.
>>>
>>> In the same way as it has become socially unacceptable to smoke in an
>>> office environment, it has now become socially unacceptable for a vendor
>>> not to fix a confirmed vulnerability within a reasonable amount of time.
>>
>> Simon, what part of VAX/VMS V5.2.??? didn't you understand. Perhaps you need
>> some reading lessons?
>>
>> Simon, WHAT VENDOR?
>>
>> VSI doesn't do VAX, nor V5.???
>> HPe doesn't do VMS
>>
>> You just keep on with your standard rhetoric, whether it makes any sense or not.
>>
>>> This is a good thing.
>>>
>>> Oh, and vulnerabilities very rarely exist only on one specific out of
>>> support point release. They generally exist across of range of supported
>>> and unsupported OS versions.
>>
>> You choose to ignore the specific question.
>>
>
> Because the specific question doesn't make any sense and shows a lack
> of understanding about how security research is done.

The question wasn't about hackers, it was about an old version of VMS.

You refuse to answer the question as asked.

> No security researcher looking for vulnerabilities in general would
> start with a decades old version of VMS. They would start with the
> current version and look for vulnerabilities in that version.
>
> If they find something, they may choose to look at older versions to see
> if it's in those versions as well, but it's the vendor's responsibility
> to determine how far back a vulnerability goes.
>
> The only time I can think of a security researcher looking at a specific
> decades old version is if they have been commissioned to do so by
> a client and then it's the client that sets the ground rules about
> disclosure.
>
>>>
>>> These days, it is the responsibility of the organisation which has
>>> chosen to remain on an old out of support OS version (for whatever
>>> reason) to make sure there is enough protection around that system
>>> to protect it from future vulnerabilities.
>>
>> And from the likes of you, I guess ...
>>
>
> That's extremely uncalled for David and I would like an apology for that.

When you start to have some compassion for victims ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Friday, August 5, 2022 at 3:19:51 PM UTC+12, Dave Froble wrote:
> On 8/4/2022 4:00 PM, Simon Clubley wrote:
> > On 2022-08-04, Dave Froble <da...@tsoft-inc.com> wrote:
> >> On 8/4/2022 1:26 PM, Simon Clubley wrote:
> >>> On 2022-08-04, Dave Froble <da...@tsoft-inc.com> wrote:
> >>>>
> >>>> David and Simon insist on making other people's decisions for them. Sort of
> >>>> "devil take the hindmost" if their solutions are not followed. Even if there
> >>>> are some who might be aware, publishing the problem will insure many will then
> >>>> know about it. And it might be totally unknown, until David/Simon publish it to
> >>>> the entire world.
> >>>>
> >>>
> >>> No, Simon believes in following industry-standard protocols, which are
> >>> give the vendor 3 months to fix it and then reveal the details.
> >>>
> >>> In the same way as it has become socially unacceptable to smoke in an
> >>> office environment, it has now become socially unacceptable for a vendor
> >>> not to fix a confirmed vulnerability within a reasonable amount of time.
> >>
> >> Simon, what part of VAX/VMS V5.2.??? didn't you understand. Perhaps you need
> >> some reading lessons?
> >>
> >> Simon, WHAT VENDOR?
> >>
> >> VSI doesn't do VAX, nor V5.???
> >> HPe doesn't do VMS
> >>
> >> You just keep on with your standard rhetoric, whether it makes any sense or not.
> >>
> >>> This is a good thing.
> >>>
> >>> Oh, and vulnerabilities very rarely exist only on one specific out of
> >>> support point release. They generally exist across of range of supported
> >>> and unsupported OS versions.
> >>
> >> You choose to ignore the specific question.
> >>
> >
> > Because the specific question doesn't make any sense and shows a lack
> > of understanding about how security research is done.
> The question wasn't about hackers, it was about an old version of VMS.
>
> You refuse to answer the question as asked.
> > No security researcher looking for vulnerabilities in general would
> > start with a decades old version of VMS. They would start with the
> > current version and look for vulnerabilities in that version.
> >
> > If they find something, they may choose to look at older versions to see
> > if it's in those versions as well, but it's the vendor's responsibility
> > to determine how far back a vulnerability goes.
> >
> > The only time I can think of a security researcher looking at a specific
> > decades old version is if they have been commissioned to do so by
> > a client and then it's the client that sets the ground rules about
> > disclosure.
> >
> >>>
> >>> These days, it is the responsibility of the organisation which has
> >>> chosen to remain on an old out of support OS version (for whatever
> >>> reason) to make sure there is enough protection around that system
> >>> to protect it from future vulnerabilities.
> >>
> >> And from the likes of you, I guess ...
> >>
> >
> > That's extremely uncalled for David and I would like an apology for that.
> When you start to have some compassion for victims ...

What if this hypothetical security hole is being actively exploited but the
user has no idea because, as far as they know, there is no security hole?

Keeping the security flaw secret doesn't stop it from being exploited, it
just makes it easier for anyone who knows about the flaw to exploit it
while making it harder for organisations running older versions to
protect their systems. No one wins by pretending the flaw doesn't exist.

On 8/4/2022 6:07 PM, gah4 wrote:
> On Thursday, August 4, 2022 at 2:22:37 PM UTC-7, abrsvc wrote:
>
> (snip)
>
>> In the emulated environment, it is the host that has the security problems and not the OpenVMS system. Odd, no?
>
> One of the more interesting, or maybe just more surprising, attacks is SQL injection.

Only if one is using and processing SQL ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-08-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 8/4/2022 8:29 AM, Simon Clubley wrote:
>>
>> Well, in fairness to Chris, while he clearly has an ideological dislike
>> for x86-64 for whatever reasons, this is also the architecture that has
>> all the Intel Management Engine and other management stuff running on
>> modern versions of that architecture.
>>
>> Stuff that runs underneath your operating system and can't be switched off.
>
> ME are not really ISA specific.
>
> ME is AFAIK only available for x86-64 chipsets.
>

Unfortunately, AMD has its own version as well: :-(

https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-08-04, Kerry Main <kemain.nospam@gmail.com> wrote:
>
> re: past Customers putting OpenVMS through the ringer from a security perspective..
>
> In approx. 2005 timeframe, the Shanghai Stock Exchange dropped their previous mission critical trading platform for what they called their "Next Generation" trading platform that was based on an OpenVMS Integrity based multi-site cluster. Disclosure - I do not know if this platform is still in place or not.
>
> Btw, at the time, some predicted the Shanghai Stock Exchange might eventually replace the NYSE in terms of WW importance.
>
> Does anyone think this next generation trading platform based on OpenVMS Integrity was not put through many, many security scenarios before this final decision was made?
>

The problem with that argument Kerry is that we now know there is at
least one major security flaw they missed.

How many more did they miss ?

(Although my version of the exploit only caused a process crash on
Itanium, the underlying flaw was still there in Itanium VMS, so if
you are relying on those stock exchange audits to say that VMS has
been audited, it's reasonable to ask why they didn't discover this
flaw and it's reasonable to ask what else they may have missed.)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 08/04/22 16:56, Dave Froble wrote:
> On 8/4/2022 10:12 AM, Dan Cross wrote:
>> In article <62e9b4ec$0$699$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 8/2/2022 10:33 AM, Dan Cross wrote:
>>>> In article <tc1d87$tnl$1@news.misty.com>,
>>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>>> On 2022-07-26 13:32, Dan Cross wrote:
>>>>>> But again, why should VSI care? They have nothing to do
>>>>>> with VAX. If people started doing this for Alpha, Itanium
>>>>>> or x86, I could see it since VSI has interest in those
>>>>>> platforms. But VAX is explicitly out of their domain.
>>>>>
>>>>> I should point out that VSI have nothing to do with VAX out of choice.
>>>>> They could technically make a VAX release if they wanted to. They do
>>>>> have the rights, and the code.
>>>>
>>>> A fair point, but regardless, they have chosen not to care.
>>>>
>>>> It boggles my mind that people think that an organization that
>>>> has explicitly declined to work with the VAX (for the very valid
>>>> reasons mentioned elsewhere in this thread) would care if a few
>>>> hobbyists run an OS, 20 years out of maintenance, they can't
>>>> issue licenses for anyway.
>>>>
>>>> Maybe those people have the inside track with someone at at VSI
>>>> who has told them that this is as big a deal as they are making
>>>> it out to be, but I find that doubtful.
>>>
>>> It is quite common to suspect that people known to be willing to
>>> break one law is more willing to break another law.
>>>
>>> Most people would not let their daughter go on a date with
>>> a convicted bank robber - even though the daughter is obviously
>>> not a bank.
>>
>> This is very much a strawman. A better analogy might be, if
>> someone picks something out of the trash and gets it working
>> again, is that technically theft?
>>
>> - Dan C.
>>
>
> Yes !!!
>

I was expecting a smiley there David, but there wasn't one ^-)...

Chris

On 08/05/22 13:13, Simon Clubley wrote:
> On 2022-08-04, Arne Vajhøj<arne@vajhoej.dk> wrote:
>> On 8/4/2022 8:29 AM, Simon Clubley wrote:
>>>
>>> Well, in fairness to Chris, while he clearly has an ideological dislike
>>> for x86-64 for whatever reasons, this is also the architecture that has
>>> all the Intel Management Engine and other management stuff running on
>>> modern versions of that architecture.
>>>
>>> Stuff that runs underneath your operating system and can't be switched off.
>>
>> ME are not really ISA specific.
>>
>> ME is AFAIK only available for x86-64 chipsets.
>>
>
> Unfortunately, AMD has its own version as well: :-(
>
> https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor
>
> Simon.
>

The problem with that, of course, is that the internals are
not fully disclosed, so cannot be fully secured. Should be
some way to disable it, but no way to tell how it interacts
with the rest of the system. A glaring security hole, but
no doubt some government agencies have the full story and
how to compromise it...

Chris

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
> via Info-vax
> Sent: August-05-22 9:22 AM
> To: info-vax@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] VMS VAX License for personal Microvax 3100 Model
> 40
>
> On 2022-08-04, Kerry Main <kemain.nospam@gmail.com> wrote:
> >
> > re: past Customers putting OpenVMS through the ringer from a security
> perspective..
> >
> > In approx. 2005 timeframe, the Shanghai Stock Exchange dropped their
> previous mission critical trading platform for what they called their
"Next
> Generation" trading platform that was based on an OpenVMS Integrity
> based multi-site cluster. Disclosure - I do not know if this platform is
still in
> place or not.
> >
> > Btw, at the time, some predicted the Shanghai Stock Exchange might
> eventually replace the NYSE in terms of WW importance.
> >
> > Does anyone think this next generation trading platform based on
> OpenVMS Integrity was not put through many, many security scenarios
> before this final decision was made?
> >
>
> The problem with that argument Kerry is that we now know there is at least
> one major security flaw they missed.
>
> How many more did they miss ?
>
> (Although my version of the exploit only caused a process crash on
Itanium,
> the underlying flaw was still there in Itanium VMS, so if you are relying
on
> those stock exchange audits to say that VMS has been audited, it's
> reasonable to ask why they didn't discover this flaw and it's reasonable
to ask
> what else they may have missed.)
>
> Simon.
>

So, just because you found a hole (that was subsequently fixed), you infer
there are still major issues with "how many more did they miss?"

However, the same can be stated for every OS platform.

History has shown that every OS platform will eventually have security
issues that will need to be fixed. No OS platform is 100% secure.

None.

As far as "relying on those stock exchange audits to say that VMS has been
audited" ...

I never stated this. I simply provided this as one example of a highly
mission critical Customer environment that, in the 2005 timeframe, did
thoroughly analyze the OpenVMS platform.

After this review, the Stock Exchange dropped their old HP-UX trading
platform and adopted OpenVMS Integrity in a active-active multi-site config
as their Next Generation trading platform.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 2022-08-05, Kerry Main <kemain.nospam@gmail.com> wrote:
>
> So, just because you found a hole (that was subsequently fixed), you infer
> there are still major issues with "how many more did they miss?"
>
> However, the same can be stated for every OS platform.
>

I completely agree Kerry. Unfortunately, there are those who believe that
absence of probing is somehow the same thing as there being no more flaws
to find.

> History has shown that every OS platform will eventually have security
> issues that will need to be fixed. No OS platform is 100% secure.
>
> None.
>

Agreed.

> As far as "relying on those stock exchange audits to say that VMS has been
> audited" ...
>
> I never stated this. I simply provided this as one example of a highly
> mission critical Customer environment that, in the 2005 timeframe, did
> thoroughly analyze the OpenVMS platform.
>

Not directly, but that's what you came across as strongly implying.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

chris <chris-nospam@tridac.net> wrote:
>
>The problem with that, of course, is that the internals are
>not fully disclosed, so cannot be fully secured. Should be
>some way to disable it, but no way to tell how it interacts
>with the rest of the system. A glaring security hole, but
>no doubt some government agencies have the full story and
>how to compromise it...

The x86_64 architecture really isn't documented inside at all, so things like
the management processor which starts up and initializes the CPU (and which
appears to be able to do a lot more) and the firmware built into that
management processor are pretty much undocumented. Some folks have managed
to reverse-engineer the 8051-like management engine in 1980s x86 processors
but everyone suspects that we have come a long way.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <tcj1gk$34t5l$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-08-04, Arne Vajh�j <arne@vajhoej.dk> wrote:
>> On 8/4/2022 8:29 AM, Simon Clubley wrote:
>>>
>>> Well, in fairness to Chris, while he clearly has an ideological dislike
>>> for x86-64 for whatever reasons, this is also the architecture that has
>>> all the Intel Management Engine and other management stuff running on
>>> modern versions of that architecture.
>>>
>>> Stuff that runs underneath your operating system and can't be switched off.
>>
>> ME are not really ISA specific.
>>
>> ME is AFAIK only available for x86-64 chipsets.
>>
>
>Unfortunately, AMD has its own version as well: :-(
>
>https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor

Yup. At the moment, not much you can do about the PSP, though
once it's trained DRAM and loaded the code that runs at the x86
reset vector, you can pretty much turn it off and ignore it.

- Dan C.

In article <mailman.4.1659713637.674.info-vax_rbnsn.com@rbnsn.com>,
Kerry Main <kemain.nospam@gmail.com> wrote:
>[snip]
>So, just because you found a hole (that was subsequently fixed), you infer
>there are still major issues with "how many more did they miss?"

Yes, absolutely. Of course. We know from decades of software
engineering research that the presence of bugs tends to indicate
more bugs in the affected system; the exact classification of
those bugs is immaterial.

>However, the same can be stated for every OS platform.
>
>History has shown that every OS platform will eventually have security
>issues that will need to be fixed. No OS platform is 100% secure.
>
>None.

Yes. Precisely why people _should_ audit VMS. Either they find
bugs that are then fixed, or they don't. In either case, you've
learned something useful.

>As far as "relying on those stock exchange audits to say that VMS has been
>audited" ...
>
>I never stated this. I simply provided this as one example of a highly
>mission critical Customer environment that, in the 2005 timeframe, did
>thoroughly analyze the OpenVMS platform.
>
>After this review, the Stock Exchange dropped their old HP-UX trading
>platform and adopted OpenVMS Integrity in a active-active multi-site config
>as their Next Generation trading platform.

That's great. But that doesn't mean that there are not security
bugs lurking in VMS. Entirely new categories of security bugs
have been discovered since 2005.

- Dan C.

In article <mailman.1.1659658224.674.info-vax_rbnsn.com@rbnsn.com>,
Kerry Main <kemain.nospam@gmail.com> wrote:
>> Cc: Dan Cross <cross@spitfire.i.gajendra.net>
>> In article <tcgp5e$2rgld$1@dont-email.me>, Dave Froble <davef@tsoft-
>> inc.com> wrote:
>> >[snip]
>> >I asked from a moral perspective. So far I detect no sympathy for
>> >people who might be in a bad place. I for one find that sad.
>>
>> The thing is, those folks are in a bad place whether they know it or not.
>> Ancient versions of VMS probably have exploitable flaws that are known to
>> state-level actors and others beyond the script-kiddies. Just because the
>> operator of some application hosted on some ancient version of VMS
>> doesn't know that doesn't make them safe. They may exist in a state of
>> blissful ignorance and still be vulnerable.
>>
>> Now the calculus changes: is it better for the flaws to be known publicly
>or
>> not, given that they may exist and may be actively exploitable? Would you
>> rather know you had terminal cancer? Is it moral for a doctor to tell
>you?
>
>Well, you can substitute OpenVMS in that statement with any OS. Lots of W2K8
>and old versions of Linux, Solaris, AIX, HP-UX etc. around big datacenters
>today.

Yes, you surely could.

>The issue of old OS support is not specific to OpenVMS.

No, not at all.

>In many, likely most, OPS teams know the issues with old OS version support.

Well, only if someone has done the work to find the issues, and
that is what is under discussion here.

>However - App vendors gone out of business, dropped App support,
>knowledgeable staff long since retired / laid off .. just many of the
>reasons why some Customers have App's on very old OS versions still running.

No arguments there, but I'm not sure I understand the relevance
to whether it's morally correct or not to look for
vulnerabilities in OpenVMS.

>Yes, one might ask "why not spend the $'s into replacing that App?", but if
>the Senior Mgrs have no budget, then OPS teams are left to protect that
>environment with whatever tools they have e.g. put in firewall zone and
>restrict flows and other means.

Well if I was one of those operations folks, I's sure what to
know where the potential problems I had to look out for were
lurking.

>Unless one has spent time in OPS support dealing with on-the-floor
>realities, one should not be to quick to criticize these folks.

I don't believe anyone was. A question of morality was raised,
and the answer (as in many questions of morality) is nuanced.

- Dan C.