In article <tc16i1$3iirh$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>[snip]
>However, you may not like the results if a bunch of highly skilled
>researchers suddenly descend on an operating system that has had
>relatively little probing compared to other operating systems.

I honestly don't understand this. Surely there'd be an initial
flurry of activity as they found low-hanging security fruit and
it was patched, but the result in the medium- to long-term would
be a significantly more robust and secure operating system.

Why would that be a problem?

- Dan C.

On 2022-08-02, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <tc16i1$3iirh$3@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>[snip]
>>However, you may not like the results if a bunch of highly skilled
>>researchers suddenly descend on an operating system that has had
>>relatively little probing compared to other operating systems.
>
> I honestly don't understand this. Surely there'd be an initial
> flurry of activity as they found low-hanging security fruit and
> it was patched, but the result in the medium- to long-term would
> be a significantly more robust and secure operating system.
>

That's _my_ attitude as well, and why I am strongly in favour of
security researchers probing VMS.

Some others however have a different opinion.

> Why would that be a problem?
>

There is a mindset in the VMS world, including from VSI management
as well as elements of the VMS user community, that VMS is the most
secure operating system in the world and is somehow immune to the
security issues that affect other operating systems.

Those people are wrong, but that attitude persists.

It also means they are not prepared for the sudden influx of security
issues that would be reported in public were such research activity
to take place and may not even have a method to remedy them as a good
number of people are running VMS systems on a frozen version of VMS
that is long out of support.

When the details of my DCL research became public knowledge, a couple
of the emulator vendors had to release documents explaining how to work
around the issue on the old versions of VMS some of their customers were
running on because some customers couldn't upgrade their old VMS versions.

This assumed the workaround (removing privileges from CDU) was suitable
for them and I will point out, once again, the next VMS vulnerability
may not have such a workaround.

I will also remind people that a vulnerability found on a more modern
version of VMS may also work just fine on an older, out of support,
version of VMS.

VSI doesn't even have a public security reporting mechanism, in spite
of being asked for one multiple times. They finally put one up in the
aftermath of my DCL research a few years ago but silently removed it
sometime later. They have ignored all requests by me for them to
reinstate it.

I invite you to find a way of securely reporting a security issue on
the following web page:

https://vmssoftware.com/contact/

There are also those in the VMS user community who for some reason see
security researchers as the enemy and as not people working to help
make operating systems more secure. Turns out there are people out
there who _really_ do not like having their illusions (delusions ? :-))
about the superiority of "their" operating system called into question.

Simon.

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

In article <tcbqoo$1lh1v$1@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> There are also those in the VMS user community who for some reason
> see security researchers as the enemy and as not people working to
> help make operating systems more secure.

There are people like that throughout computing. I've seen a development
group manager complain about being "blackmailed" by only being given 90
days to release fixes before vulnerabilities are disclosed. He gradually
came to accept the idea that you should make use of the reports you get,
because there are also people who sell the vulnerabilities they find on
the dark-grey market.

John

In article <tcbqoo$1lh1v$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>There is a mindset in the VMS world, including from VSI management
>as well as elements of the VMS user community, that VMS is the most
>secure operating system in the world and is somehow immune to the
>security issues that affect other operating systems.
>
>Those people are wrong, but that attitude persists.

Well that just seems divorced from reality. It reminds me of
how people would bellyache about how mainframes and VMS were
"more secure" than Unix 30 years ago, nevermind that entirely
new categories of vulnerabilities have been discovered in the
meantime.

>It also means they are not prepared for the sudden influx of security
>issues that would be reported in public were such research activity
>to take place and may not even have a method to remedy them as a good
>number of people are running VMS systems on a frozen version of VMS
>that is long out of support.
>
>When the details of my DCL research became public knowledge, a couple
>of the emulator vendors had to release documents explaining how to work
>around the issue on the old versions of VMS some of their customers were
>running on because some customers couldn't upgrade their old VMS versions.
>
>This assumed the workaround (removing privileges from CDU) was suitable
>for them and I will point out, once again, the next VMS vulnerability
>may not have such a workaround.
>
>I will also remind people that a vulnerability found on a more modern
>version of VMS may also work just fine on an older, out of support,
>version of VMS.

And presumably VSI can't even release patches for older versions
of VMS, for similar reasons that they can't issue licenses for
those versions?

>VSI doesn't even have a public security reporting mechanism, in spite
>of being asked for one multiple times. They finally put one up in the
>aftermath of my DCL research a few years ago but silently removed it
>sometime later. They have ignored all requests by me for them to
>reinstate it.
>
>I invite you to find a way of securely reporting a security issue on
>the following web page:
>
>https://vmssoftware.com/contact/
>
>There are also those in the VMS user community who for some reason see
>security researchers as the enemy and as not people working to help
>make operating systems more secure. Turns out there are people out
>there who _really_ do not like having their illusions (delusions ? :-))
>about the superiority of "their" operating system called into question.

Yeah, that's the part I really don't get. *shrug*

- Dan C.

On 2022-08-02 16:33, 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.

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.

Not to mention the risk that if you do not protect your rights, it can
become a point in future legal discussions elsewhere. It's not like the
VAX version is completely different than current VMS.

I would say it's a mischaracterization to say "they have choosen not to
care". They have different priorities and different goals. That do not
mean they do not care.

It is, as always, a question of prioritization and resource allocation.

With infinite money and infinite time, I would suspect that they
wouldn't mind doing something for the VAX as well.

Johnny

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>In article <tc16i1$3iirh$3@dont-email.me>,
>Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>[snip]
>>However, you may not like the results if a bunch of highly skilled
>>researchers suddenly descend on an operating system that has had
>>relatively little probing compared to other operating systems.
>
>I honestly don't understand this. Surely there'd be an initial
>flurry of activity as they found low-hanging security fruit and
>it was patched, but the result in the medium- to long-term would
>be a significantly more robust and secure operating system.

This is generally what happens. However, in the case of some (Windows)
operating systems, the patches don't actually address the initial design
problems and merely target specific (Windows) vulnerabilities. This
looks good in the short term but just leaves (Windows) systems no more
secure in the long run. This goes double for log4j on any OS.
--scott

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

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.

Arne

On Wednesday, August 3, 2022 at 11:36:14 AM UTC+12, Arne Vajhøj wrote:
> On 8/2/2022 10:33 AM, Dan Cross wrote:
> > In article <tc1d87$tnl$1...@news.misty.com>,
> > Johnny Billquist <b...@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.

These are people who were probably never going to buy VMS anyway.
Worrying about them or trying to prevent it is just a waste of time and
money and making licensing more onerous than it already is just runs
the risk of alienating people who *might* have someday contributed
to the viability of the platform (bought a license, ported software,
encouraged their company not to migrate to linux, etc)

On 03/08/2022 00:36, Arne Vajhøj 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.

People think it, but is it true? If I occasionality exceed the speed
limits, have a Ham Antenna without Planning Permission or make
structural changes to my house without notifying building control, does
that make me more likely to rob a bank?

Is it actually possible to drive a car in the UK without breaking the
law. For example what to do if your screen wash runs out on the
motorway? Stopping on the motorway except in an emergency is an offence
but so is driving with an empty screen wash bottle...

.... so as far as I can see no one has suggested running modern versions
of VMS without a valid licence. If my Alpha box worked it would have a
VSI version installed. Sadly it doesn't but thats another tale...

>
> 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.

She probably wouldn't ask? Did Bonnie Parker check with her mum before
running off with Clyde Barrow?

>
> Arne
>

Dave

On 2022-08-02, John Dallman <jgd@cix.co.uk> wrote:
> In article <tcbqoo$1lh1v$1@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> There are also those in the VMS user community who for some reason
>> see security researchers as the enemy and as not people working to
>> help make operating systems more secure.
>
> There are people like that throughout computing. I've seen a development
> group manager complain about being "blackmailed" by only being given 90
> days to release fixes before vulnerabilities are disclosed. He gradually
> came to accept the idea that you should make use of the reports you get,
> because there are also people who sell the vulnerabilities they find on
> the dark-grey market.
>

I can believe that's way possible for more bespoke software development.

However, in other operating systems (Windows, Linux, Apple, Android, etc)
the protocols around management of security issues follow well established
industry standards and are accepted by everyone, including the users.

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-02, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <tcbqoo$1lh1v$1@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>I will also remind people that a vulnerability found on a more modern
>>version of VMS may also work just fine on an older, out of support,
>>version of VMS.
>
> And presumably VSI can't even release patches for older versions
> of VMS, for similar reasons that they can't issue licenses for
> those versions?
>

Correct. In addition to the HPE versus VSI issue, VMS support has always
gone through a versioning system, where older versions have dropped out
of support.

The difference is that there's a culture in VMS land where people don't
really see a problem with running an old out-of-support version of VMS
provided the hardware issues are dealt with.

Simon.

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

> The difference is that there's a culture in VMS land where people don't
> really see a problem with running an old out-of-support version of VMS
> provided the hardware issues are dealt with.
> Simon.
>

Well, I still run Windows 98 for some stuff that is still useful to me. Granted, it is not internet connected...

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.

How about we compare situational apples to apples here. Lets look at vulnerabilities on both systems that do not require prior connection to the system and see how that does.

The lack of support means nothing. In many cases, support was continued strictly for access to newer versions that often were never used. I new of many clients that remained at V7.3-2 for Alpha systems because it was stable and did what they needed with no problems at all. Moving to newer versions was a cost (validation work) that couldn't be justified since there were no benefits to the upgrade. I can cite other clients with different hardware and OS levels with similar status too. Stabile application software that does the job does not usually need newer OS versions. Compare the VMS environment with that of Windows where updates are constantly required because of the instability of the OS or external vulnerabilities that just don't exist for VMS.

On 8/3/2022 8:55 AM, abrsvc wrote:
>
>> The difference is that there's a culture in VMS land where people don't
>> really see a problem with running an old out-of-support version of VMS
>> provided the hardware issues are dealt with.
>> Simon.
>>
>
> Well, I still run Windows 98 for some stuff that is still useful to me. Granted, it is not internet connected...
>
> 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.
>
> How about we compare situational apples to apples here. Lets look at vulnerabilities on both systems that do not require prior connection to the system and see how that does.
>
> The lack of support means nothing. In many cases, support was continued strictly for access to newer versions that often were never used. I new of many clients that remained at V7.3-2 for Alpha systems because it was stable and did what they needed with no problems at all. Moving to newer versions was a cost (validation work) that couldn't be justified since there were no benefits to the upgrade. I can cite other clients with different hardware and OS levels with similar status too. Stabile application software that does the job does not usually need newer OS versions. Compare the VMS environment with that of Windows where updates are constantly required because of the instability of the OS or external vulnerabilities that just don't exist for VMS.
>

There can be arguments for and against running old versions of VMS. All can be
valid.

It is possible for errors to be introduced in a new version. I believe it has
happened, however I cannot remember any details.

For the user, there may be things that insist on total validation before
anything new is used. This can be a tremendous cost. People don't like such costs.

For the OS vendor, new versions are a method of introducing new capabilities.
Perhaps some fixes could be applied to older versions, sometimes not. How much
extra cost should the OS vendor incur? At some point it becomes prohibitive.

For something as old as VMS, with the expectation of continued compatibility,
there are some issues that just cannot be solved. Alpha may not be able to
perform some VAX capabilities. VAX does not have 64 bit addresses. Some people
may be using capabilities that do not exist on newer hardware. Anything that
counts on PDP-11 compatibility mode is an example, though not a practice I'd
recommend.

The issue seems to be one with no good answers. Continual deprecation of
capabilities will result in lost customers and remaining on old OS versions.
Both are rather bad. Continual upgrading of applications may be a good idea for
those being paid to do so, but is a rather bad idea for those doing the paying.

--
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 08/03/22 13:55, abrsvc wrote:
>
>> The difference is that there's a culture in VMS land where people don't
>> really see a problem with running an old out-of-support version of VMS
>> provided the hardware issues are dealt with.
>> Simon.
>>
>
> Well, I still run Windows 98 for some stuff that is still useful to me. Granted, it is not internet connected...
>
> 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...

Chris

> How about we compare situational apples to apples here. Lets look at vulnerabilities on both systems that do not require prior connection to the system and see how that does.
>
> The lack of support means nothing. In many cases, support was continued strictly for access to newer versions that often were never used. I new of many clients that remained at V7.3-2 for Alpha systems because it was stable and did what they needed with no problems at all. Moving to newer versions was a cost (validation work) that couldn't be justified since there were no benefits to the upgrade. I can cite other clients with different hardware and OS levels with similar status too. Stabile application software that does the job does not usually need newer OS versions. Compare the VMS environment with that of Windows where updates are constantly required because of the instability of the OS or external vulnerabilities that just don't exist for VMS.

On 2022-08-03, abrsvc <dansabrservices@yahoo.com> wrote:
>
> The lack of support means nothing. In many cases, support was continued strictly for access to newer versions that often were never used. I new of many clients that remained at V7.3-2 for Alpha systems because it was stable and did what they needed with no problems at all. Moving to newer versions was a cost (validation work) that couldn't be justified since there were no benefits to the upgrade. I can cite other clients with different hardware and OS levels with similar status too. Stabile application software that does the job does not usually need newer OS versions. Compare the VMS environment with that of Windows where updates are constantly required because of the instability of the OS or external vulnerabilities that just don't exist for VMS.

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.

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

On Wednesday, August 3, 2022 at 1:30:02 PM UTC-4, Simon Clubley wrote:
> On 2022-08-03, abrsvc <dansabr...@yahoo.com> wrote:
> >
> > The lack of support means nothing. In many cases, support was continued strictly for access to newer versions that often were never used. I new of many clients that remained at V7.3-2 for Alpha systems because it was stable and did what they needed with no problems at all. Moving to newer versions was a cost (validation work) that couldn't be justified since there were no benefits to the upgrade. I can cite other clients with different hardware and OS levels with similar status too. Stabile application software that does the job does not usually need newer OS versions. Compare the VMS environment with that of Windows where updates are constantly required because of the instability of the OS or external vulnerabilities that just don't exist for VMS.
> 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.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
I welcome such an effort. And I doubt there will be much found. Call it attitude if you want, but VMS works differently than Windows and doesn't have the opportunities that Windows has for exploitation.

On 8/3/2022 4:06 AM, David Wade wrote:
> On 03/08/2022 00:36, Arne Vajhøj wrote:
>> On 8/2/2022 10:33 AM, 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.
>>
>> It is quite common to suspect that people known to be willing to
>> break one law is more willing to break another law.
>
> People think it, but is it true?

Interesting question.

But it does not matter.

If people believe it to be so then they will act accordingly
and the fact that they may have been wrong does not change
their actions.

Arne

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.

Arne

On 8/3/2022 8:55 AM, 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.

Isn't Windows virus'es a bit 00'ish?

> 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.
>
> How about we compare situational apples to apples here. Lets look at
> vulnerabilities on both systems that do not require prior connection
> to the system and see how that does.

I don't think it is correct to say that the known VMS problems
are privilege escalation problems.

The frequently mentioned DCL issue is.

But password sent unencrypted via DECnet is not.

> The lack of support means nothing. In many cases, support was
> continued strictly for access to newer versions that often were never
> used. I new of many clients that remained at V7.3-2 for Alpha
> systems because it was stable and did what they needed with no
> problems at all. Moving to newer versions was a cost (validation
> work) that couldn't be justified since there were no benefits to the
> upgrade. I can cite other clients with different hardware and OS
> levels with similar status too. Stabile application software that
> does the job does not usually need newer OS versions.

It is a potential problem - a risk.

If a problem is found (security vulnerability or functional) then
it will not be fixed.

Some people like to go into the casino and put all chips on red.

Some people like to assume that there will never be a problem with
their IT system.

> Compare the
> VMS environment with that of Windows where updates are constantly
> required because of the instability of the OS or external
> vulnerabilities that just don't exist for VMS.

All large systems that get probed in detail get security fixes.

Windows, Linux, Java, Oracle DB.

Nobody expect a bugs/KLOC ratio of zero.

Arne

On 08/03/22 21:29, Arne Vajhøj 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.
>
> Arne
>

That may be true, but there are literally decades of hacker experience
with X86, because of the ubiquity of the hardware and operating
systems, windows, for example. In comparison, how
often do we hear of destructive and expensive hacks of power, sparc or
mainframe systems ?. Yes, the cpu arch is only one brick in a security
model, but a pretty substantial one given the potential for hacking
with X86. It means that extra work is needed at all levels of os and
application design...

Chris

On Wednesday, August 3, 2022 at 4:03:31 PM UTC-7, chris wrote:

(snip)

> That may be true, but there are literally decades of hacker experience
> with X86, because of the ubiquity of the hardware and operating
> systems, windows, for example. In comparison, how
> often do we hear of destructive and expensive hacks of power, sparc or
> mainframe systems ?. Yes, the cpu arch is only one brick in a security
> model, but a pretty substantial one given the potential for hacking
> with X86. It means that extra work is needed at all levels of os and
> application design...

I was working with Sun machines around the time of the SunOS to
Solaris transition. Early in the Solaris years, there were more attacks
on Solaris than SunOS, second only to Windows.

It seems that, at the time, Solaris was popular for web servers,
and so were interesting to hackers.

There are some favorite tricks to get x86 systems to write data onto
the stack, and then execute it. There are now hardware features to
make that harder. I don't know if the same tricks would work for
other x86 OS, but in any case, would need to exploit OS features
once the code was running.

On 8/3/2022 1:30 PM, Simon Clubley wrote:
> On 2022-08-03, abrsvc <dansabrservices@yahoo.com> wrote:
>>
>> The lack of support means nothing. In many cases, support was continued strictly for access to newer versions that often were never used. I new of many clients that remained at V7.3-2 for Alpha systems because it was stable and did what they needed with no problems at all. Moving to newer versions was a cost (validation work) that couldn't be justified since there were no benefits to the upgrade. I can cite other clients with different hardware and OS levels with similar status too. Stabile application software that does the job does not usually need newer OS versions. Compare the VMS environment with that of Windows where updates are constantly required because of the instability of the OS or external vulnerabilities that just don't exist for VMS.
>
> 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.
>

Ok Simon, a question for you.

Suppose someone finds a vulnerability in VAX/VMS V5.2H4, and that someone knows
that there is very little, or no, chance of a fix. And that someone also is
aware that some users are still using that old software.

So now the moral question. Knowing there will not be a fix, and knowing that
exposure just might cause problems for said user running that old software, is
it Ok to expose the vulnerability?

--
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/3/2022 7:03 PM, chris wrote:
> On 08/03/22 21:29, Arne Vajhøj 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.
>
> That may be true, but there are literally decades of hacker experience
> with X86, because of the ubiquity of the hardware and operating
> systems, windows, for example. In comparison, how
> often do we hear of destructive and expensive hacks of power, sparc or
> mainframe systems ?. Yes, the cpu arch is only one brick in a security
> model, but a pretty substantial one given the potential for hacking
> with X86. It means that extra work is needed at all levels of os and
> application design...

Hackers tend to focus on common ISA and common OS.That
makes sense. So Linux, Windows and x86-64.

But I would be hard pressed to name any specific problems
due to x86-64. Even the cache issues existed on other
ISA. And as we all know then ILO are not x86-64 specific
either.

The reality is that there are close to nothing ISA
related, some OS related, some standard application related
and the vast majority custom application related.

Arne

On Thursday, August 4, 2022 at 1:28:20 PM UTC+12, Dave Froble wrote:
> On 8/3/2022 1:30 PM, Simon Clubley wrote:
> > On 2022-08-03, abrsvc <dansabr...@yahoo.com> wrote:
> >>
> >> The lack of support means nothing. In many cases, support was continued strictly for access to newer versions that often were never used. I new of many clients that remained at V7.3-2 for Alpha systems because it was stable and did what they needed with no problems at all. Moving to newer versions was a cost (validation work) that couldn't be justified since there were no benefits to the upgrade. I can cite other clients with different hardware and OS levels with similar status too. Stabile application software that does the job does not usually need newer OS versions. Compare the VMS environment with that of Windows where updates are constantly required because of the instability of the OS or external vulnerabilities that just don't exist for VMS.
> >
> > 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.
> >
> Ok Simon, a question for you.
>
> Suppose someone finds a vulnerability in VAX/VMS V5.2H4, and that someone knows
> that there is very little, or no, chance of a fix. And that someone also is
> aware that some users are still using that old software.
>
> So now the moral question. Knowing there will not be a fix, and knowing that
> exposure just might cause problems for said user running that old software, is
> it Ok to expose the vulnerability?

If you find a vulnerability you have no way to be sure that you were the first to discover it
or that you are the only one who will ever discover it. For all you know someone else
discovered that vulnerability years ago and has been quietly exploiting it ever since.

By exposing the vulnerability users can at least be aware it exists and take appropriate
steps to mitigate the risk even if there is no chance of it ever being properly fixed. By
keeping it secret you're just giving anyone else who is aware of the issue the opportunity
to continue exploiting it.

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.

Simon.

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