Discussion:
Is (Open)VMS inherently less susceptible to malware?
(too old to reply)
Jay Braun
2017-04-26 19:18:01 UTC
Permalink
Raw Message
Somewhat related to the marketing-at-40 thread:

I recall that in the last few years that we used VMS, our sysadmin claimed that the reason VMS wasn't as susceptible to malware as Windows (and *NIX) was that "Obscurity is security". Hackers didn't target VMS because it was such a niche OS.

On the other hand, is VMS inherently less susceptible to malware?

If so, could it not be branded as the ultimate cyber-defensive solution, e.g., as the server that faces the internet in a large enterprise? Or perhaps as the server of choice in classified facilities (winning back the military/government market)?

j
Stephen Hoffman
2017-04-26 20:30:49 UTC
Permalink
Raw Message
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin
claimed that the reason VMS wasn't as susceptible to malware as Windows
(and *NIX) was that "Obscurity is security". Hackers didn't target VMS
because it was such a niche OS.
On the other hand, is VMS inherently less susceptible to malware?
If so, could it not be branded as the ultimate cyber-defensive
solution, e.g., as the server that faces the internet in a large
enterprise? Or perhaps as the server of choice in classified
facilities (winning back the military/government market)?
OpenVMS security is robust against the sorts of problems and
vulnerabilities that were common in the 1990s. It's not so good in
this era.

VSI is working on many of the associated issues and areas, though
there's a whole lot of work involved. Some has been completed.
Apache and the Apache-integrated TLS support was dragged forward, for
instance. More is pending.

It's fairly easy to scrounge up a substantial list of CVEs that apply
to OpenVMS components, too.

Ponder the presence of that too-efficient password hash, the use of
unencrypted network transports including DECnet and SCS, and
down-revision network-facing software (lots of CVEs there), a
completely ad-hoc and grafted-on certificate infrastructure, a core
security subsystem that was abandoned over a decade ago, no per-user or
whole-disk encryption support (files only, and it's far from
transparent), the patch distribution and installation process is
basically entirely manual, and other such issues...

VSI is well aware of these issues, and it's going to take time to
resolve these. VSI IP will fix a number of issues. Details such as
adding encrypted email transports are somewhat overdue, for instance.
Unfortunately, there are always going to be more vulnerabilities, and
the attacks against vulnerabilities are only going to accelerate.
Sooner or later, that "cool and unhackable" mantra is going to backfire
badly, too.

Then there's the discussion of what folks are purchasing and running
servers for. What folks are familiar with and trained for and have
integrated into their environments. In many cases, OpenVMS doesn't
support various of the server applications that folks want to use, or
the sort of integration the folks want or need. Or the sorts of
frameworks and tools that folks want to use to easily develop those
services.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-04-27 00:27:35 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Sooner or later, that "cool and unhackable" mantra is going to backfire
badly, too.
Agreed. The only surprise for me is that this hasn't happened in
a major way yet.

In addition to my other comments to Jay, I should point out that
VMS also has one other problem which other operating systems do not.

This is that there's a good portion of the VMS community which thinks
that the security issues of other operating systems don't apply to them
so they don't have to worry about the things that users/sysadmins of
these other systems have to worry about.

One day they are going to find out (probably the hard way) that they
are very very wrong about this.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Simon Clubley
2017-04-27 00:21:05 UTC
Permalink
Raw Message
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin
claimed that the reason VMS wasn't as susceptible to malware as
Windows (and *NIX) was that "Obscurity is security". Hackers didn't
target VMS because it was such a niche OS.
Your sysadmin was right. As Stephen has just pointed out, VMS was
designed for the security issues of the 1980s/1990s and has not
moved forward from there.

I also suspect the obscurity factor also plays out in some of VSI's
decisions. For example, they have not implemented a secure public
way for security researchers to report issues to them in spite of
this being pointed out to them multiple times.

I suspect VSI are thinking that security researchers are not going
to probe VMS as it stands today so as far as VSI's concerned it's not
a priority for them to implement an industry standard reporting
mechanism.

They are wrong about this, but if your mindset is still stuck in the
1980s/1990s cosy club security mindset where vendors still controlled
the release schedule for patches and the details of the vulnerabilities
fixed by the patches then I can see why they would think this.
Post by Jay Braun
On the other hand, is VMS inherently less susceptible to malware?
Absolutely not; in fact it's more susceptible in some ways.

Applications share an address space with a privileged CLI (Stephen
has said in the past that if you can get into supervisor mode, then
there's probably a path to exec/kernel mode but he didn't expand
on that.)

There's lots of nice memory buffers/data cells at well known locations
in memory. (The DEFCON attack placed the attack code into a logical
which neatly avoided the issue of having to get it onto the stack.)
Brian made the attack more elegant by using the LIB$PUT_COMMON buffer.

VMS doesn't implement ASLR.

VMS doesn't have no-execute in places that I would expect it to.

VMS doesn't have any kind of a mandatory access control system.

VMS doesn't support jails.

Add to this list all the things which Stephen has mentioned in his reply.
Post by Jay Braun
If so, could it not be branded as the ultimate cyber-defensive
solution, e.g., as the server that faces the internet in a large
enterprise? Or perhaps as the server of choice in classified
facilities (winning back the military/government market)?
VMS needs to acquire the kinds of security features that Linux
has before you can even think of doing that.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
j***@yahoo.co.uk
2017-04-27 09:00:15 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin
claimed that the reason VMS wasn't as susceptible to malware as
Windows (and *NIX) was that "Obscurity is security". Hackers didn't
target VMS because it was such a niche OS.
Your sysadmin was right. As Stephen has just pointed out, VMS was
designed for the security issues of the 1980s/1990s and has not
moved forward from there.
I also suspect the obscurity factor also plays out in some of VSI's
decisions. For example, they have not implemented a secure public
way for security researchers to report issues to them in spite of
this being pointed out to them multiple times.
I suspect VSI are thinking that security researchers are not going
to probe VMS as it stands today so as far as VSI's concerned it's not
a priority for them to implement an industry standard reporting
mechanism.
They are wrong about this, but if your mindset is still stuck in the
1980s/1990s cosy club security mindset where vendors still controlled
the release schedule for patches and the details of the vulnerabilities
fixed by the patches then I can see why they would think this.
Post by Jay Braun
On the other hand, is VMS inherently less susceptible to malware?
Absolutely not; in fact it's more susceptible in some ways.
Applications share an address space with a privileged CLI (Stephen
has said in the past that if you can get into supervisor mode, then
there's probably a path to exec/kernel mode but he didn't expand
on that.)
There's lots of nice memory buffers/data cells at well known locations
in memory. (The DEFCON attack placed the attack code into a logical
which neatly avoided the issue of having to get it onto the stack.)
Brian made the attack more elegant by using the LIB$PUT_COMMON buffer.
VMS doesn't implement ASLR.
VMS doesn't have no-execute in places that I would expect it to.
VMS doesn't have any kind of a mandatory access control system.
VMS doesn't support jails.
Add to this list all the things which Stephen has mentioned in his reply.
Post by Jay Braun
If so, could it not be branded as the ultimate cyber-defensive
solution, e.g., as the server that faces the internet in a large
enterprise? Or perhaps as the server of choice in classified
facilities (winning back the military/government market)?
VMS needs to acquire the kinds of security features that Linux
has before you can even think of doing that.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
A great deal in there to agree with, thank you.

But let's go back to basics to start with, and then
add some detail (maybe too much detail - it doesn't
Fit In A Twit).

Is VMS secure? No. No non-trivial OS is, even the
ones that have been "proven" correct. See e.g. "I
have proved this program correct but I haven't
tested it" (or something very similar, courtesy
of some bloke called Knuth).

So, given that nothing is totally secure, how are
we going to define "less secure"?

In the first instance, the size of the attack surface
*might* possibly be relevant ("how big is the OS").
VMS is tiny in comparison with the IT versions of
Linux and Windows. VMS is even tiny in comparison
with many of today's "embedded" versions of Linux.
Sometimes less is more (apparently).

Once you get into the details, the picture may well
change, depending on the viewer. You've provided
some useful starting points, there are many others
to choose from.

Yes VMS doesn't do ASLR. Does it matter? Well it's a
tick missing from the tick-the-box list, but there
are ways of defeating ASLR (even where it's in use,
which is far from everywhere it might be useful, eg
many AV products on Windows had side effects of
disabling ASLR). Some of the recent ASLR defeats
seem quite plausible, e.g. look up "ASLR JavaScript"
and find an article that suits you.

VMS doesn't have no-execute on memory management (it
does have it in the general principles and in many
other places e.g. filesystem). NoEx might be good to
have, but depends on the costs ($$$ and functional).
E.g. it'll be particularly tricky in a language or
runtime which requires trampolines, as quite a few
currently do.
[Trampolines:
https://en.wikipedia.org/wiki/Trampoline_(computing)]

VMS doesn't have mandatory access controls any
more. It did have, back in the days of SEVMS, and
presumably could have again one day if it became
worthwhile again. It stands more chance of
happening now the people managing VMS development
have more interest in VMS's success, but it does
rather depend on customers being (a) aware that
VSIVMS exists (b) interested enough to dig a bit
(c) willing to pay (someone's usually got to pay).

VMS doesn't support jails. OK, but why do people
think they need jails in the first instance? Does
it solve a problem that would be relevant to the
VMS installed base in the short term? Maybe not.
Beyond the short term, looking for growth, are
jails still going to be relevant, and if so are
they something that has to be done by the OS author,
or could a trustworthy outsider do something useful?

VMS doesn't have the security features that (some)
Linuxes offer. OK, but it's had some of them in
the past, maybe one day they'll be back in VSIVMS,
with more to come, either from VSI if it needs to
be in VSIVMS itself, or from others if it's safely
doable elsewhere. VMS also doesn't have some of the
oddness that some Linuxes now require (systemd
being an obvious recent example).

The list could go on. I can't :)

More questions than answers, at the moment. Proper
answers require detail and understanding, and
unfortunately a lot of 'modern' IT decisions
haven't involved detail never mind understanding.
Hence e.g. the pathetic state of the IoT, and the
ability of Netgear's cloud/NAS storage to destroy
customers' *local* data as well as the cloudy copy,
and and and ... where/when/how does it stop?

Have a lot of fun - but don't forget to look at the
small print :)
j***@yahoo.co.uk
2017-04-27 11:20:44 UTC
Permalink
Raw Message
Post by j***@yahoo.co.uk
Post by Simon Clubley
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin
claimed that the reason VMS wasn't as susceptible to malware as
Windows (and *NIX) was that "Obscurity is security". Hackers didn't
target VMS because it was such a niche OS.
Your sysadmin was right. As Stephen has just pointed out, VMS was
designed for the security issues of the 1980s/1990s and has not
moved forward from there.
I also suspect the obscurity factor also plays out in some of VSI's
decisions. For example, they have not implemented a secure public
way for security researchers to report issues to them in spite of
this being pointed out to them multiple times.
I suspect VSI are thinking that security researchers are not going
to probe VMS as it stands today so as far as VSI's concerned it's not
a priority for them to implement an industry standard reporting
mechanism.
They are wrong about this, but if your mindset is still stuck in the
1980s/1990s cosy club security mindset where vendors still controlled
the release schedule for patches and the details of the vulnerabilities
fixed by the patches then I can see why they would think this.
Post by Jay Braun
On the other hand, is VMS inherently less susceptible to malware?
Absolutely not; in fact it's more susceptible in some ways.
Applications share an address space with a privileged CLI (Stephen
has said in the past that if you can get into supervisor mode, then
there's probably a path to exec/kernel mode but he didn't expand
on that.)
There's lots of nice memory buffers/data cells at well known locations
in memory. (The DEFCON attack placed the attack code into a logical
which neatly avoided the issue of having to get it onto the stack.)
Brian made the attack more elegant by using the LIB$PUT_COMMON buffer.
VMS doesn't implement ASLR.
VMS doesn't have no-execute in places that I would expect it to.
VMS doesn't have any kind of a mandatory access control system.
VMS doesn't support jails.
Add to this list all the things which Stephen has mentioned in his reply.
Post by Jay Braun
If so, could it not be branded as the ultimate cyber-defensive
solution, e.g., as the server that faces the internet in a large
enterprise? Or perhaps as the server of choice in classified
facilities (winning back the military/government market)?
VMS needs to acquire the kinds of security features that Linux
has before you can even think of doing that.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
A great deal in there to agree with, thank you.
But let's go back to basics to start with, and then
add some detail (maybe too much detail - it doesn't
Fit In A Twit).
Is VMS secure? No. No non-trivial OS is, even the
ones that have been "proven" correct. See e.g. "I
have proved this program correct but I haven't
tested it" (or something very similar, courtesy
of some bloke called Knuth).
So, given that nothing is totally secure, how are
we going to define "less secure"?
In the first instance, the size of the attack surface
*might* possibly be relevant ("how big is the OS").
VMS is tiny in comparison with the IT versions of
Linux and Windows. VMS is even tiny in comparison
with many of today's "embedded" versions of Linux.
Sometimes less is more (apparently).
Once you get into the details, the picture may well
change, depending on the viewer. You've provided
some useful starting points, there are many others
to choose from.
Yes VMS doesn't do ASLR. Does it matter? Well it's a
tick missing from the tick-the-box list, but there
are ways of defeating ASLR (even where it's in use,
which is far from everywhere it might be useful, eg
many AV products on Windows had side effects of
disabling ASLR). Some of the recent ASLR defeats
seem quite plausible, e.g. look up "ASLR JavaScript"
and find an article that suits you.
VMS doesn't have no-execute on memory management (it
does have it in the general principles and in many
other places e.g. filesystem). NoEx might be good to
have, but depends on the costs ($$$ and functional).
E.g. it'll be particularly tricky in a language or
runtime which requires trampolines, as quite a few
currently do.
https://en.wikipedia.org/wiki/Trampoline_(computing)]
VMS doesn't have mandatory access controls any
more. It did have, back in the days of SEVMS, and
presumably could have again one day if it became
worthwhile again. It stands more chance of
happening now the people managing VMS development
have more interest in VMS's success, but it does
rather depend on customers being (a) aware that
VSIVMS exists (b) interested enough to dig a bit
(c) willing to pay (someone's usually got to pay).
VMS doesn't support jails. OK, but why do people
think they need jails in the first instance? Does
it solve a problem that would be relevant to the
VMS installed base in the short term? Maybe not.
Beyond the short term, looking for growth, are
jails still going to be relevant, and if so are
they something that has to be done by the OS author,
or could a trustworthy outsider do something useful?
VMS doesn't have the security features that (some)
Linuxes offer. OK, but it's had some of them in
the past, maybe one day they'll be back in VSIVMS,
with more to come, either from VSI if it needs to
be in VSIVMS itself, or from others if it's safely
doable elsewhere. VMS also doesn't have some of the
oddness that some Linuxes now require (systemd
being an obvious recent example).
The list could go on. I can't :)
More questions than answers, at the moment. Proper
answers require detail and understanding, and
unfortunately a lot of 'modern' IT decisions
haven't involved detail never mind understanding.
Hence e.g. the pathetic state of the IoT, and the
ability of Netgear's cloud/NAS storage to destroy
customers' *local* data as well as the cloudy copy,
and and and ... where/when/how does it stop?
Have a lot of fun - but don't forget to look at the
small print :)
Sorry, I forgot the intended Netgear ReadyNAS hiccup
link:
https://www.theregister.co.uk/2017/04/26/netgear_customer_backups_fried/

There are other software issues from the same product
range going back a while too, e.g.
https://www.theregister.co.uk/2013/10/23/netgear_users_missing_old_patch_tripwire/
c***@gmail.com
2017-04-27 11:09:49 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin
claimed that the reason VMS wasn't as susceptible to malware as
Windows (and *NIX) was that "Obscurity is security". Hackers didn't
target VMS because it was such a niche OS.
Your sysadmin was right. As Stephen has just pointed out, VMS was
designed for the security issues of the 1980s/1990s and has not
moved forward from there.
I also suspect the obscurity factor also plays out in some of VSI's
decisions. For example, they have not implemented a secure public
way for security researchers to report issues to them in spite of
this being pointed out to them multiple times.
I have never in 30 years heard a single person, engineer or manager, in VMS development DEC/COMPAQ/HP/VSI consider obscurity to be a factor in any decision. Never has, never will.
We are not that stupid.
Post by Simon Clubley
I suspect VSI are thinking that security researchers are not going
to probe VMS as it stands today so as far as VSI's concerned it's not
a priority for them to implement an industry standard reporting
mechanism.
You are dead wrong. The web page for reporting security issues has been designed and in the queue since November. Why it is not up yet is beyond my pay grade, so don't ask.
Post by Simon Clubley
They are wrong about this, but if your mindset is still stuck in the
1980s/1990s cosy club security mindset where vendors still controlled
the release schedule for patches and the details of the vulnerabilities
fixed by the patches then I can see why they would think this.
Post by Jay Braun
On the other hand, is VMS inherently less susceptible to malware?
Absolutely not; in fact it's more susceptible in some ways.
Applications share an address space with a privileged CLI (Stephen
has said in the past that if you can get into supervisor mode, then
there's probably a path to exec/kernel mode but he didn't expand
on that.)
There's lots of nice memory buffers/data cells at well known locations
in memory. (The DEFCON attack placed the attack code into a logical
which neatly avoided the issue of having to get it onto the stack.)
Brian made the attack more elegant by using the LIB$PUT_COMMON buffer.
VMS doesn't implement ASLR.
VMS doesn't have no-execute in places that I would expect it to.
VMS doesn't have any kind of a mandatory access control system.
VMS doesn't support jails.
Add to this list all the things which Stephen has mentioned in his reply.
Post by Jay Braun
If so, could it not be branded as the ultimate cyber-defensive
solution, e.g., as the server that faces the internet in a large
enterprise? Or perhaps as the server of choice in classified
facilities (winning back the military/government market)?
VMS needs to acquire the kinds of security features that Linux
has before you can even think of doing that.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Simon Clubley
2017-04-27 12:10:21 UTC
Permalink
Raw Message
Post by c***@gmail.com
Post by Simon Clubley
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin
claimed that the reason VMS wasn't as susceptible to malware as
Windows (and *NIX) was that "Obscurity is security". Hackers didn't
target VMS because it was such a niche OS.
Your sysadmin was right. As Stephen has just pointed out, VMS was
designed for the security issues of the 1980s/1990s and has not
moved forward from there.
I also suspect the obscurity factor also plays out in some of VSI's
decisions. For example, they have not implemented a secure public
way for security researchers to report issues to them in spite of
this being pointed out to them multiple times.
I have never in 30 years heard a single person, engineer or manager, in VMS
development DEC/COMPAQ/HP/VSI consider obscurity to be a factor in any
decision. Never has, never will.
We are not that stupid.
You might want to re-read what I actually said instead of what you
clearly think I said.

I did not say VMS Engineering; I said VSI. You have made it very clear
on multiple occasions that VSI is a small company and it must decide
the priorities that it gives to certain enhancement work, including
security work.
Post by c***@gmail.com
Post by Simon Clubley
I suspect VSI are thinking that security researchers are not going
to probe VMS as it stands today so as far as VSI's concerned it's not
a priority for them to implement an industry standard reporting
mechanism.
You are dead wrong. The web page for reporting security issues has been
designed and in the queue since November. Why it is not up yet is beyond
my pay grade, so don't ask.
That's excellent news Clair and no I won't ask because I understand that.

However, if it's been pending for the best part of 6 months then the
person whose job it is to update the website clearly does consider it to
be a low priority job.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
c***@gmail.com
2017-04-27 13:43:01 UTC
Permalink
Raw Message
Post by Simon Clubley
You might want to re-read what I actually said instead of what you
clearly think I said.
I did not say VMS Engineering; I said VSI. You have made it very clear
on multiple occasions that VSI is a small company and it must decide
the priorities that it gives to certain enhancement work, including
security work.
Arg. I did get it but my reply was poorly worded. When I said "or manager" I was trying to include everyone in the company but obviously one would read that as part of just engineering. (I confess to having this myopic view that VSI = VMS Engineering, which works in most cases but clearly not in this one.)

Sorry about that.
Post by Simon Clubley
Post by c***@gmail.com
Post by Simon Clubley
I suspect VSI are thinking that security researchers are not going
to probe VMS as it stands today so as far as VSI's concerned it's not
a priority for them to implement an industry standard reporting
mechanism.
You are dead wrong. The web page for reporting security issues has been
designed and in the queue since November. Why it is not up yet is beyond
my pay grade, so don't ask.
That's excellent news Clair and no I won't ask because I understand that.
However, if it's been pending for the best part of 6 months then the
person whose job it is to update the website clearly does consider it to
be a low priority job.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Simon Clubley
2017-04-27 17:36:12 UTC
Permalink
Raw Message
Post by c***@gmail.com
Post by Simon Clubley
You might want to re-read what I actually said instead of what you
clearly think I said.
I did not say VMS Engineering; I said VSI. You have made it very clear
on multiple occasions that VSI is a small company and it must decide
the priorities that it gives to certain enhancement work, including
security work.
Arg. I did get it but my reply was poorly worded. When I said "or
manager" I was trying to include everyone in the company but obviously one
would read that as part of just engineering. (I confess to having this
myopic view that VSI = VMS Engineering, which works in most cases but
clearly not in this one.)
Sorry about that.
No problem at all Clair thanks. I just didn't want you or others
thinking that I had said or implied something about you which I hadn't.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
John Reagan
2017-04-27 11:48:17 UTC
Permalink
Raw Message
Post by Simon Clubley
VMS doesn't implement ASLR.
ASLR has no value on OpenVMS and actually it sorta has it already.

OpenVMS's memory protection scheme doesn't let you "jump" into the middle of some piece of the OS like you can on other OSes. Even if you can "guess" the right system space address, do you think you can jump into the middle of $SETPRV right after the check for "do you have SETPRV?" and trick it into giving you privs you aren't authorized for? Go ahead, try it, report back.

And given the same distribution, different SYSGEN parameters (ie, AUTOGEN's feedback, MODPARAMS.DAT, etc) means that the EXCEPTION.EXE execlet would load at a different base address on system "A" than on system "B". Not that it helps you can, you can't just jump into the middle of it and hope something gets tricked.
Jan-Erik Soderholm
2017-04-27 12:07:31 UTC
Permalink
Raw Message
Post by John Reagan
Post by Simon Clubley
VMS doesn't implement ASLR.
ASLR has no value on OpenVMS and actually it sorta has it already.
OpenVMS's memory protection scheme doesn't let you "jump" into the
middle of some piece of the OS like you can on other OSes. Even if you
can "guess" the right system space address, do you think you can jump
into the middle of $SETPRV right after the check for "do you have
SETPRV?" and trick it into giving you privs you aren't authorized for?
Go ahead, try it, report back.
And given the same distribution, different SYSGEN parameters (ie,
AUTOGEN's feedback, MODPARAMS.DAT, etc) means that the EXCEPTION.EXE
execlet would load at a different base address on system "A" than on
system "B". Not that it helps you can, you can't just jump into the
middle of it and hope something gets tricked.
ASLR, is that this:
"https://en.wikipedia.org/wiki/Address_space_layout_randomization" ?

To me it sounds as some kind of "security by obscurity". You do not solve
the security issue at hand, you just try to hide it away.
Simon Clubley
2017-04-27 12:23:13 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
"https://en.wikipedia.org/wiki/Address_space_layout_randomization" ?
Yes.
Post by Jan-Erik Soderholm
To me it sounds as some kind of "security by obscurity". You do not solve
the security issue at hand, you just try to hide it away.
It makes it a lot harder for an attacker to determine the address they
need to use.

It's all about putting up barriers against an attacker and ASLR is
another barrier. However, as with all barriers it's better to have
multiple barriers instead of just the one, so ASLR should be just
another barrier along multiple barriers.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-04-27 12:38:29 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Jan-Erik Soderholm
"https://en.wikipedia.org/wiki/Address_space_layout_randomization" ?
Yes.
Post by Jan-Erik Soderholm
To me it sounds as some kind of "security by obscurity". You do not solve
the security issue at hand, you just try to hide it away.
It makes it a lot harder for an attacker to determine the address they
need to use.
It's all about putting up barriers against an attacker and ASLR is
another barrier. However, as with all barriers it's better to have
multiple barriers instead of just the one, so ASLR should be just
another barrier along multiple barriers.
Simon.
But if ASLR is just a lower barrier than the barriers already
in place, it doesn't add that much.

To me it just sounds as another stick to poke into the back of VSI,
now that your "secure security report" stick ot a bit damaged. :-)
Arne Vajhøj
2017-04-27 17:15:28 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Simon Clubley
Post by Jan-Erik Soderholm
To me it sounds as some kind of "security by obscurity". You do not solve
the security issue at hand, you just try to hide it away.
It makes it a lot harder for an attacker to determine the address they
need to use.
It's all about putting up barriers against an attacker and ASLR is
another barrier. However, as with all barriers it's better to have
multiple barriers instead of just the one, so ASLR should be just
another barrier along multiple barriers.
But if ASLR is just a lower barrier than the barriers already
in place, it doesn't add that much.
It is not important whether a security feature set a low or
high bar.

It is important whether the features is covered by something
else.

It is not. That makes it useful.

Arne
David Froble
2017-04-27 20:12:24 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Simon Clubley
Post by Jan-Erik Soderholm
"https://en.wikipedia.org/wiki/Address_space_layout_randomization" ?
Yes.
Post by Jan-Erik Soderholm
To me it sounds as some kind of "security by obscurity". You do not solve
the security issue at hand, you just try to hide it away.
It makes it a lot harder for an attacker to determine the address they
need to use.
It's all about putting up barriers against an attacker and ASLR is
another barrier. However, as with all barriers it's better to have
multiple barriers instead of just the one, so ASLR should be just
another barrier along multiple barriers.
Simon.
But if ASLR is just a lower barrier than the barriers already
in place, it doesn't add that much.
To me it just sounds as another stick to poke into the back of VSI,
now that your "secure security report" stick ot a bit damaged. :-)
Ah, I see that I'm not the only one who was getting a bit irritated ...

:-)
Stephen Hoffman
2017-04-27 23:53:19 UTC
Permalink
Raw Message
Post by David Froble
Ah, I see that I'm not the only one who was getting a bit irritated ...
:-)
Think of it as a few folks trying to assist others that are apparently
somewhat unfamiliar with or are inexperienced with security features
and techniques used on other operating systems and platforms, and with
the sorts of recent security and networks attacks and malware, and the
phishing, that routinely arise.

But then I'm still trying to drag various folks off of telnet and ftp
and DECnet, so there's that. With various of the security messes I've
encountered, there's little point in adding ASLR to the kernel, as the
baseline security of the server configurations is so weak. Why bother
expending the effort to ROP past ASLR or figuring out how to exercise a
buffer overflow deep in SMGRTL when cleartext user and password
credentials are flying around the 'net? Or when you can easily phish
some credentials and replace some binaries or similar shenanigans?
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Gezelter
2017-04-27 14:26:54 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by John Reagan
Post by Simon Clubley
VMS doesn't implement ASLR.
ASLR has no value on OpenVMS and actually it sorta has it already.
OpenVMS's memory protection scheme doesn't let you "jump" into the
middle of some piece of the OS like you can on other OSes. Even if you
can "guess" the right system space address, do you think you can jump
into the middle of $SETPRV right after the check for "do you have
SETPRV?" and trick it into giving you privs you aren't authorized for?
Go ahead, try it, report back.
And given the same distribution, different SYSGEN parameters (ie,
AUTOGEN's feedback, MODPARAMS.DAT, etc) means that the EXCEPTION.EXE
execlet would load at a different base address on system "A" than on
system "B". Not that it helps you can, you can't just jump into the
middle of it and hope something gets tricked.
"https://en.wikipedia.org/wiki/Address_space_layout_randomization" ?
To me it sounds as some kind of "security by obscurity". You do not solve
the security issue at hand, you just try to hide it away.
Jan,

ASLR is basically aimed at preventing pro-forma attacks. The term also covers a number of different techniques. Which of these techniques are relevant in an OpenVMS context is a long and detailed analysis.

For example, QIO uses buffer descriptors, and overflows thereof are not permitted. This avenue of generating a buffer overflow is effectively foreclosed. However, many transported C programs do use the C library, therefore overruns are possible. Similarly, while SYS$FAO(L) uses descriptors, the C string library does not.

Then again, the impact of ASLR techniques on user mode toolsets would need to be checked. ASLR would mean that profiling tools would have obtain and generate some sort of mapping to cross identify areas of code which appear at different addresses in different executions. For that matter, a traceback without the map of the particular execution would be similarly useless.

- Bob Gezelter, http://www.rlgsc.com
Arne Vajhøj
2017-04-27 17:12:57 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
"https://en.wikipedia.org/wiki/Address_space_layout_randomization" ?
To me it sounds as some kind of "security by obscurity". You do not solve
the security issue at hand, you just try to hide it away.
The features is well and openly documented so the bad guys are
very much aware of how it works. So it is not security by obscurity.

And it achieve what it tries to achieve and that is making it a little
bit more difficult to access some critical location.

It obviously does not provide a 100% sure way to prevent any buffer
overflows in the hundreds of millions lines of code in a modern system.
But that is a very difficult one.

Arne
Simon Clubley
2017-04-27 12:12:29 UTC
Permalink
Raw Message
Post by John Reagan
Post by Simon Clubley
VMS doesn't implement ASLR.
ASLR has no value on OpenVMS and actually it sorta has it already.
Yes, it does have value on VMS. What about the applications that run
under VMS ?
Post by John Reagan
OpenVMS's memory protection scheme doesn't let you "jump" into the middle of
some piece of the OS like you can on other OSes. Even if you can "guess" the
right system space address, do you think you can jump into the middle of
$SETPRV right after the check for "do you have SETPRV?" and trick it into
giving you privs you aren't authorized for? Go ahead, try it, report back.
And given the same distribution, different SYSGEN parameters (ie, AUTOGEN's
feedback, MODPARAMS.DAT, etc) means that the EXCEPTION.EXE execlet would load
at a different base address on system "A" than on system "B". Not that it
helps you can, you can't just jump into the middle of it and hope something
gets tricked.
And what about the user level applications ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
John Reagan
2017-04-27 14:05:54 UTC
Permalink
Raw Message
What about user applications? It is all user-mode code right? You want to jump into the middle of the Fortran RTL? Want to call some private routine in the COBOL RTL? Have at it. The worst thing you'll do is ACCVIO, corrupt your own data, delete a file you can already access, etc. So having the image activator to load things at different base addresses doesn't add any additional protection to the system.
Bob Gezelter
2017-04-27 14:36:35 UTC
Permalink
Raw Message
Post by John Reagan
What about user applications? It is all user-mode code right? You want to jump into the middle of the Fortran RTL? Want to call some private routine in the COBOL RTL? Have at it. The worst thing you'll do is ACCVIO, corrupt your own data, delete a file you can already access, etc. So having the image activator to load things at different base addresses doesn't add any additional protection to the system.
John,

With all due respect, I disagree with "with the worst you can do is ACCVIO". Au contraire, it can result in an escalation.

If the image involved is privileged, then the sky is the limit. The "Heartbleed" bug in OpenSSL was of this genre (Heartbleed allowed one to extract private keys and other information from the corresponding process). If the process is non-privileged, the worst that can happen is that the process' private data is compromised. This is a serious problem (legally, PII disclosure is the problem, not whether the attacker compromised the system).

Similarly, getting a server to bypass its internal security checks is useful to an attacker. Privilege escalation is not necessary.

Does the C library "feature" of zero-terminated strings, often located on the stack exacerbate the problem, undoubtedly. Are OpenVMS descriptors safer, undoubtedly. Is is useful to make applications less vulnerable? Unfortunately, yes.

Note that I am not convinced that ASLR is effective in this regard. Merely that the danger that provoked ASLR is credible, and it does not only affect direct escalation into system state.

- Bob Gezelter, http://www.rlgsc.com
John Reagan
2017-04-27 15:30:09 UTC
Permalink
Raw Message
Post by Bob Gezelter
Post by John Reagan
What about user applications? It is all user-mode code right? You want to jump into the middle of the Fortran RTL? Want to call some private routine in the COBOL RTL? Have at it. The worst thing you'll do is ACCVIO, corrupt your own data, delete a file you can already access, etc. So having the image activator to load things at different base addresses doesn't add any additional protection to the system.
John,
With all due respect, I disagree with "with the worst you can do is ACCVIO". Au contraire, it can result in an escalation.
If the image involved is privileged, then the sky is the limit. The "Heartbleed" bug in OpenSSL was of this genre (Heartbleed allowed one to extract private keys and other information from the corresponding process). If the process is non-privileged, the worst that can happen is that the process' private data is compromised. This is a serious problem (legally, PII disclosure is the problem, not whether the attacker compromised the system).
Most data spilling has been due to buffer overruns with the knowledge that some compiler has stored interesting private data nearby some exploited buffer. I don't see ASLR protecting from that.

So lets assume you can trick some by-definition broken, privileged, user-mode application to jumping somewhere it shouldn't. You really can't jump into the middle of a existing routine (especially on Itanium where if you skip the 'alloc', all sorts of things rattle apart quickly - x86's shadow stack in future chips can help protect against that return-oriented-hack). You could trick it to return somewhere else (again Itanium sorta protects you in that the saved return address is rarely on the stack, but in some other register and x86's shadow stack protects as well). If you can actually do code insertion, the ASLR doesn't matter either. I'd just insert a call to $SETPRV to enable more privs if possible or perhaps open additional backdoors (ie, change file protections, etc.)

I'll admit that some form of ASLR might help but if the intrusion code has a hardcoded address of, 0x21234, for example, all that ALSR would do is change the base address. It makes the hacker simply figure out some way to trick the broken program to expose the base code address and then they could compute the new hardcoded address. (perhaps easier said than done).

Of course OpenVMS on x86 won't have memory layouts like Linux, Windows, Chromium, etc. The stack will still be in 32-bit space. Static data in 32-bit space. "Procedure values" in 32-bit space (the code may be in 64-bit space).

And how many people on Linux boxes forget to specify a user account in their httpd.conf file and let the server to continue to run as 'root'.
Post by Bob Gezelter
Similarly, getting a server to bypass its internal security checks is useful to an attacker. Privilege escalation is not necessary.
Again, that is often done via buffer overruns to clear/set some adjacent flag. ASLR not involved.
Post by Bob Gezelter
Does the C library "feature" of zero-terminated strings, often located on the stack exacerbate the problem, undoubtedly. Are OpenVMS descriptors safer, undoubtedly. Is is useful to make applications less vulnerable? Unfortunately, yes.
I'll agree that a system where a string's length is dependent on its contents vs some separate meta-data (ie, descriptor) is more prone to buffer overrun attacks.
Post by Bob Gezelter
Note that I am not convinced that ASLR is effective in this regard. Merely that the danger that provoked ASLR is credible, and it does not only affect direct escalation into system state.
- Bob Gezelter, http://www.rlgsc.com
Stephen Hoffman
2017-04-27 16:16:49 UTC
Permalink
Raw Message
Post by Bob Gezelter
Post by John Reagan
What about user applications? It is all user-mode code right? You
want to jump into the middle of the Fortran RTL? Want to call some
private routine in the COBOL RTL? Have at it. The worst thing you'll
do is ACCVIO, corrupt your own data, delete a file you can already
access, etc. So having the image activator to load things at different
base addresses doesn't add any additional protection to the system.
With all due respect, I disagree with "with the worst you can do is
ACCVIO". Au contraire, it can result in an escalation.
Ayup. Many ACCVIOs are harmless. Some are not.

I'll happily relate a rather hilarious example that arose in OpenVMS
long ago. Over a nice steaming mug of tea. Someday. But not today.

Opinion: all application and all system crashes should be captured and
analyzed, and no app crashes should be dumped to an end-user; to dev or
ops or vendor, only.

Something (related) to ponder:
http://cert.europa.eu/static/WhitePapers/CERT-EU_SWP_17-002_Lateral_Movements.pdf
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-04-27 18:28:42 UTC
Permalink
Raw Message
Post by Bob Gezelter
Post by John Reagan
What about user applications? It is all user-mode code right? You want
to jump into the middle of the Fortran RTL? Want to call some private
routine in the COBOL RTL? Have at it. The worst thing you'll do is
ACCVIO, corrupt your own data, delete a file you can already access, etc.
So having the image activator to load things at different base addresses
doesn't add any additional protection to the system.
It's also involves randomising the stack and heap locations (for example).

The idea is that if you manage to blow through a buffer and dump your
shellcode into the process memory, then ASLR is supposed to make it
much more difficult to find out where your shellcode is located.
Post by Bob Gezelter
John,
With all due respect, I disagree with "with the worst you can do is ACCVIO".
Au contraire, it can result in an escalation.
As the DEFCON security researchers proved very nicely.

As a reminder to people, the DEFCON researchers placed their shellcode
into a logical using normal non-privileged means and then found a
vulnerability in SMG. They then invoked a privileged program and
then simply set the return address to the address of the logical in
question. There was no need to load the shellcode onto the stack and
then find it.

I've actually had a bit of a re-think about ASLR on VMS. I still think
it would be a good idea, but there are some VMS issues which make ASLR
less useful on VMS it should be (or even non-effective in some cases)
that need to be addressed first.

The main problem is that data structures in VMS which should be marked
as non-executable are executable. This includes the memory assigned to
the values in the logical name tables and the LIB$PUT_COMMON buffer and
the other program accessible data only storage locations.

When combined with the fact that DCL and the application share the same
address space and that state is preserved when a non-privileged image
activation is followed by a privileged image activation, this gives
a very easy to use home for shellcode which completely avoids the need
for the shellcode to be injected onto the stack, at least for an
interactive session.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
j***@yahoo.co.uk
2017-04-27 14:41:26 UTC
Permalink
Raw Message
Post by John Reagan
What about user applications? It is all user-mode code right? You want to jump into the middle of the Fortran RTL? Want to call some private routine in the COBOL RTL? Have at it. The worst thing you'll do is ACCVIO, corrupt your own data, delete a file you can already access, etc. So having the image activator to load things at different base addresses doesn't add any additional protection to the system.
That's a statement I'm technically happy with. I'm also
happy if a plausible expert wants to show (explain or
demonstrate) why it's wrong. Details matter. It doesn't
even have to be done in public, in fact might be better
initially if not.

It looks like Bob G may have just volunteered (intentionally
or otherwise) for part of the job :)

Even if it's not technically important on VMS, it's become a
"tick the box" item for some folk (rightly or wrongly).

But in general and in the short term, I suspect it's not
going to be that near the top of VSI's own "to do" list.
And to me that's understandable even if it's not ideal.
Others are welcome to disagree :)
Bob Gezelter
2017-04-27 14:52:00 UTC
Permalink
Raw Message
Post by j***@yahoo.co.uk
Post by John Reagan
What about user applications? It is all user-mode code right? You want to jump into the middle of the Fortran RTL? Want to call some private routine in the COBOL RTL? Have at it. The worst thing you'll do is ACCVIO, corrupt your own data, delete a file you can already access, etc. So having the image activator to load things at different base addresses doesn't add any additional protection to the system.
That's a statement I'm technically happy with. I'm also
happy if a plausible expert wants to show (explain or
demonstrate) why it's wrong. Details matter. It doesn't
even have to be done in public, in fact might be better
initially if not.
It looks like Bob G may have just volunteered (intentionally
or otherwise) for part of the job :)
Even if it's not technically important on VMS, it's become a
"tick the box" item for some folk (rightly or wrongly).
But in general and in the short term, I suspect it's not
going to be that near the top of VSI's own "to do" list.
And to me that's understandable even if it's not ideal.
Others are welcome to disagree :)
John,

While it is not, strictly speaking, a stack overflow attack, Heartbleed is a good example of the seriousness of a user mode vulnerability.

Altering the stack only requires a touch of sloppy coding practice. It is different from the environment on *IX, but an attacker with access to an external system could figure out the details.

- Bob Gezelter, http://www.rlgsc.com
Simon Clubley
2017-04-27 18:45:28 UTC
Permalink
Raw Message
Post by j***@yahoo.co.uk
That's a statement I'm technically happy with. I'm also
happy if a plausible expert wants to show (explain or
demonstrate) why it's wrong. Details matter. It doesn't
even have to be done in public, in fact might be better
initially if not.
I've just posted a summary of how the DEFCON researchers did it.

Pure data areas (such as the logical name table) are executable,
are in the same address space as the application and survive
multiple image activations.
Post by j***@yahoo.co.uk
But in general and in the short term, I suspect it's not
going to be that near the top of VSI's own "to do" list.
And to me that's understandable even if it's not ideal.
Others are welcome to disagree :)
I agree with that. There are other security issues which need to
be addressed first.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2017-04-27 15:50:22 UTC
Permalink
Raw Message
Post by John Reagan
What about user applications? It is all user-mode code right? You
want to jump into the middle of the Fortran RTL? Want to call some
private routine in the COBOL RTL? Have at it. The worst thing you'll
do is ACCVIO, corrupt your own data, delete a file you can already
access, etc. So having the image activator to load things at different
base addresses doesn't add any additional protection to the system.
This is why folks instrument and collect crashes. Why it'll be likely
VSI starts seeking to upload OpenVMS application and system crashes,
and potentially even end-user application failures, yes, opt-in,
encrypted, et al, yada yada. Because jumping around doesn't always
work, as John correctly indicates. Because ASLR and no-execute aren't
a panacea. But ASLR and no-execute does serve as an impediment.
Without ASLR, getting code executing using these approaches is easier.
It's code that's often stitched together from the instruction sequences
ending various subroutines or ending in a register-based jump,
subroutines and random code for a wide variety of purposes. (Without
no-execute coverage, it's feasible to load and execute code directly
without bothering to have to dig around for instructions, too. That's
easier.) With these instruction sequences, creating an attack becomes
feasible. A program based on the bad data that the attacker can
somehow feed in. This data whether from a buggy ASN.1 or JSON parser,
from a deliberately wonky executable or database, from network buffer
errors, maybe even into MOUNT from a deliberately corrupt file system.
Pretty much anything past plain text, and I wouldn't entirely write off
the possibility of latent bugs in a UTF-8 parser these days, and there
have been exploits against some RTF tools. (RTF is even sort-of
available on OpenVMS via at least one of the CDA toolkits around, too.)
Because once the attacker has that repurposed and now-hostile code
executing, the attacker can then write or modify memory elsewhere, or
write to files, or connect to a remote server and download something.
This all might seem an effort and it most certainly is, though there
are tools specifically created and intended to scan for these gadgets;
these instruction streams. It's all happening on Microsoft Windows,
too. Once some code is executing — and getting to this stage is
tougher on Itanium, due to the use of separate stacks for the call
frames and the stack frames — then the local system is going to permit
the attacker to execute whatever is permissible within the run-time
context. What can then be executed in that context can be constrained
by sandboxes/jails and by BSD-style pledge mechanisms. Sandboxes and
pledges are also not panaceas, though they too increase the cost of the
attack, they increase the likelihood of failures, and the likelihood
that the activities might be detected by either local folks watching
crashes — some OpenVMS environments do watch crashes, but those sites
have created their own infrastructure to do that as OpenVMS completely
lacks this.

Related:
http://www.syssec-project.eu/m/page-media/3/lobotomy_ares2014.pdf
https://github.com/sslab-gatech/DrK
https://github.com/0vercl0k/rp/

Related reading:
https://blog.zynamics.com/2010/03/12/a-gentle-introduction-to-return-oriented-programming/

https://crypto.stanford.edu/~blynn/rop/
https://ketansingh.net/Introduction-to-Return-Oriented-Programming-ROP/

Files can be more hazardous than many realize, parsers can be buggy,
and here's some information related to that Microsoft Wordpad RTF
Remote Command Execution (RCE) mentioned earlier:
https://github.com/bhdresh/CVE-2017-0199
Also CVE-2015-1641.
Unzip and other archival tools have been targeted, too. I've certainly
not fuzzed BACKUP or PCSI, and the "secure" delivery implementation on
OpenVMS installers really... isn't. Sure, it checks. But I can print
an official-looking DVD or can generate a disk image that always passes
those checks. Or can change the binary checker to simply disable those
checks. These are not easy problems, either. It'll take time to sort
out.

Like the tools to look for ROP gadgets, many of checks for security
errors are now automated, too. Here's one of many examples:

https://github.com/dxa4481/truffleHog

But all of this is somewhat ahead of where VSI and OpenVMS are.
Because details such as getting CVEs sorted out — VSI IP goes a long
way, but there'll be ongoing maintenance with that. Faster and more
efficient patches, when security problems are identified and need
faster patching. Encrypting application data. Authenticating
connections. Far slower and far less efficient password hashes.
Because no attacker is going to bother with a ROP gadget search or
compromising a tool download at Process Software or DECUServe
(developer signing, et al), or when the telnet and FTP servers and SCS
are open and spewing credentials around the 'net, or phishing for
credentials from VSI users, or can spoof other folks into thinking that
mail from or to ***@gmail.example.com or
***@gmail.example.com are folks that they can send OpenVMS
security reports or credentials to. There's more than a little work
involved with security on any operating system, it never ends, and the
attacks continue to evolve. ASLR and sandboxes and other pieces are
certainly parts of this puzzle, too, and VSI will likely be determining
whether or even if those or other updates are feasible, and are
marketable and profitable.

About the delay on getting the updated security page and related
posted, getting the security contact and related posted, and the delays
in getting important and good-news announcements and collateral such as
the 2L1 LP availability announcement posted? That might be necessary
for business or financial reasons — tradeoffs are never fun — but...
these are missed opportunities to show off the quality and efficacy and
effectiveness of VSI staff and of the OpenVMS products, and of making
it clear to all what VSI has already achieved through your substantial
efforts.

Want more ideas? Discussions on how you can harden your OpenVMS
installation? Contact me offline.

Developers often like to think that they're creating programs to
manipulate data. But pragmatically, the data manipulates the programs.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Koehler
2017-04-27 13:32:22 UTC
Permalink
Raw Message
OpenVMS's memory protection scheme doesn't let you "jump" into the middle o=
f some piece of the OS like you can on other OSes.
People are still building those for non-embedded applications? I
thought that ended with MS-DOS, except within the embedded community.
y***@hotmail.com
2017-05-06 01:29:02 UTC
Permalink
Raw Message
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin claimed that the reason VMS wasn't as susceptible to malware as Windows (and *NIX) was that "Obscurity is security". Hackers didn't target VMS because it was such a niche OS.
On the other hand, is VMS inherently less susceptible to malware?
If so, could it not be branded as the ultimate cyber-defensive solution, e.g., as the server that faces the internet in a large enterprise? Or perhaps as the server of choice in classified facilities (winning back the military/government market)?
j
I don't think there has been any common IA-64 exploits, right? In fact IA-64 has features making exploits more difficult such as having two stacks.
u***@gmail.com
2017-05-14 10:33:20 UTC
Permalink
Raw Message
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin claimed that the reason VMS wasn't as susceptible to malware as Windows (and *NIX) was that "Obscurity is security". Hackers didn't target VMS because it was such a niche OS.
On the other hand, is VMS inherently less susceptible to malware?
If so, could it not be branded as the ultimate cyber-defensive solution, e.g., as the server that faces the internet in a large enterprise? Or perhaps as the server of choice in classified facilities (winning back the military/government market)?
j
Jay for basic data server and maailserver functions, OpenVMS is
the best period. The webserver is another matter as encryption lags,
but for basic data and mail it is superior.

And yes there are jails on openvms. I can put you in a user accout
with absolutely no privileges so you only read the data I place there.

There is also products like this


Two-factor authentication solution for OpenVMS systems
Read the latest issue of the (IN)SECURE Magazine

Process Software announced that it has achieved technical interoperability certification between the VMS Authentication Module and RSA SecurID two-factor authentication solution. This RSA Secured partner program certification signifies that a technical partnership has been extended to increase security for OpenVMS customers.

The VMS Authentication Module is being used at a large financial institution in Switzerland to give more than 1,000 customers secure access to a banking application running on several OpenVMS systems. “This organization provides customers with RSA SecurID cards for access to their personal financial information which is more secure than the use of static passwords,” said Heinz Genhart, GFR Software Solutions AG. “Process Software’s VMS Authentication Module API allowed us to easily integrate RSA SecurID agent software with this financial institution’s application.”

Process Software’s VMS Authentication Module software provides two implementation options. It can be incorporated into the normal OpenVMS login procedure or used to protect a particular application on the OpenVMS system. Once a user logs into the OpenVMS operating system using normal procedures, access to a specific applications is granted with a RSA SecurID card. The RSA SecurID agent is one of several authentication methods available that can be integrated into third-party applications using the VMS Authentication Module’s API.
Ian Miller
2017-05-15 09:04:15 UTC
Permalink
Raw Message
On Sunday, May 14, 2017 at 11:33:22 AM UTC+1, ***@gmail.com wrote:
...
Post by u***@gmail.com
Two-factor authentication solution for OpenVMS systems
Read the latest issue of the (IN)SECURE Magazine
Process Software announced that it has achieved technical interoperability certification between the VMS Authentication Module and RSA SecurID two-factor authentication solution. This RSA Secured partner program certification signifies that a technical partnership has been extended to increase security for OpenVMS customers.
The VMS Authentication Module is being used at a large financial institution in Switzerland to give more than 1,000 customers secure access to a banking application running on several OpenVMS systems. “This organization provides customers with RSA SecurID cards for access to their personal financial information which is more secure than the use of static passwords,” said Heinz Genhart, GFR Software Solutions AG. “Process Software’s VMS Authentication Module API allowed us to easily integrate RSA SecurID agent software with this financial institution’s application.”
Process Software’s VMS Authentication Module software provides two implementation options. It can be incorporated into the normal OpenVMS login procedure or used to protect a particular application on the OpenVMS system. Once a user logs into the OpenVMS operating system using normal procedures, access to a specific applications is granted with a RSA SecurID card. The RSA SecurID agent is one of several authentication methods available that can be integrated into third-party applications using the VMS Authentication Module’s API.
Two-factor authentication solution for OpenVMS systems
https://www.helpnetsecurity.com/2006/08/07/two-factor-authentication-solution-for-openvms-systems/
Published - August 7, 2006
Stephen Hoffman
2017-05-15 16:19:35 UTC
Permalink
Raw Message
Jay for basic data server and maailserver functions, OpenVMS isthe best
period. The webserver is another matter as encryption lags, but for
basic data and mail it is superior.
The currently-available SMTP server from VSI and HPE does lack
encrypted connection support and a submission port, though VSI IP —
when that becomes available — or an added-cost third-party add-on can
address that.
And yes there are jails on openvms. I can put you in a user accoutwith
absolutely no privileges so you only read the data I place there.
That's closer to mandatory access controls — a capability OpenVMS once
had, and pieces are still present — and not analogous to a jail or a
sandbox.

https://en.wikipedia.org/wiki/FreeBSD_jail
There is also products like this
Add-on third-party products add costs and complexities and risks, and
various features — such as jails — are best as part of the base distro
and not an add-on.
--
Pure Personal Opinion | HoffmanLabs LLC
Jason Howe
2017-05-15 17:54:00 UTC
Permalink
Raw Message
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin claimed
that the reason VMS wasn't as susceptible to malware as Windows (and *NIX)
was that "Obscurity is security". Hackers didn't target VMS because it was
such a niche OS.
On the other hand, is VMS inherently less susceptible to malware?
If so, could it not be branded as the ultimate cyber-defensive solution,
e.g., as the server that faces the internet in a large enterprise? Or
perhaps as the server of choice in classified facilities (winning back the
military/government market)?
j
Jay for basic data server and maailserver functions, OpenVMS is the best
period. The webserver is another matter as encryption lags, but for basic data
and mail it is superior.
As a mailserver admin, I'm not sure I agree with your assessment of the
mailservices available on VMS vs a Postgres/Dovecot setup on *nix or even a
Windows Exchange Server.

Just as a quick example, and I'm happy to be wrong here, can a mailserver on
OpenVMS hook into a native virus scanner (like clamav) and a native Baysian spam
filter that can be trained? Can I run server-side mail filtering rules easily
through my Client? Again, I'm happy to be wrong here, but my impression is that
mail on OpenVMS is stuck in the 90's. I've only ever been comfortable using it
with an incoming mail firewall in front, and sending it out via a replay SMTP
server.

-- Jason
Stephen Hoffman
2017-05-15 18:27:40 UTC
Permalink
Raw Message
Post by Jason Howe
As a mailserver admin, I'm not sure I agree with your assessment of the
mailservices available on VMS vs a Postgres/Dovecot setup on *nix or
even a Windows Exchange Server.
Just as a quick example, and I'm happy to be wrong here, can a
mailserver on OpenVMS hook into a native virus scanner (like clamav)
and a native Baysian spam filter that can be trained?
Not the VSI/HPE stack. Not without hacking together a whole lot of
pieces and parts, or going third-party, or both.
Post by Jason Howe
Can I run server-side mail filtering rules easily through my Client?
Nope. Not with the available VSI/HPE stack.
Post by Jason Howe
Again, I'm happy to be wrong here, but my impression is that mail on
OpenVMS is stuck in the 90's. I've only ever been comfortable using it
with an incoming mail firewall in front, and sending it out via a
replay SMTP server.
Ayup.

As for Exchange Server, there's integration with Active Directory LDAP
servers, ease of access to trained staff or staff training and
documentation for the product, push notifications and activesync,
calendar integration, and many other details. Replication and
clustering has been getting better with each Exchange Server release,
too.

There are some rather large organizations that are migrating to
Microsoft-hosted Exchange, too; to Microsoft Exchange Online. That
and Office 365 work well for folks that don't want to deal with this
stuff in-house.

What VSI IP might provide here — and it'll almost certainly be
substantially better than what is presently available — we will learn
as it becomes available.

But I don't see OpenVMS drawing any folks away from Exchange Server in
the near to mid-term, either.

Pending VSI IP and a whole lot of work past what's expected with that,
suggesting that OpenVMS as a viable competitor for Exchange Server is
just not going to get enough folks interested in any product offerings
or into any sales meetings. That whether it's the current VSI or HPE
TCP/IP Services stack or a third-party add-on stack, though the Process
mail tools do manage to do quite well here.

I really want to see OpenVMS do well here and really want to see VSI
succeed. That won't happen by going up against Exchange Server. Too
many other products have died on that quest. Anybody remember what
happened with HP's OpenMail, or DEC's MailWorks and ALL-IN-1 products,
or IBM PROFS, for instance? Those markets were largely ceded to
Windows Server and Exchange Server and Microsoft Office and SharePoint
and related products ~twenty years ago. And now to the
hosted-services offerings from Microsoft and others. To have any
reasonable competitive chance in that market, OpenVMS needs to be much
better than it is, and VSI is certainly working on what amounts to the
foundations necessary for that and for many other markets; VSI IP,
security, networking, etc; of much of what's already in the roadmap and
some of what's presently beyond the VSI roadmap. (Not to imply that I
believe VSI is seriously looking to replace Exchange Server right now,
either.)
--
Pure Personal Opinion | HoffmanLabs LLC
u***@gmail.com
2017-05-15 21:51:54 UTC
Permalink
Raw Message
Post by Jason Howe
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin claimed
that the reason VMS wasn't as susceptible to malware as Windows (and *NIX)
was that "Obscurity is security". Hackers didn't target VMS because it was
such a niche OS.
On the other hand, is VMS inherently less susceptible to malware?
If so, could it not be branded as the ultimate cyber-defensive solution,
e.g., as the server that faces the internet in a large enterprise? Or
perhaps as the server of choice in classified facilities (winning back the
military/government market)?
j
Jay for basic data server and maailserver functions, OpenVMS is the best
period. The webserver is another matter as encryption lags, but for basic data
and mail it is superior.
As a mailserver admin, I'm not sure I agree with your assessment of the
mailservices available on VMS vs a Postgres/Dovecot setup on *nix or even a
Windows Exchange Server.
Just as a quick example, and I'm happy to be wrong here, can a mailserver on
OpenVMS hook into a native virus scanner (like clamav) and a native Baysian spam
filter that can be trained? Can I run server-side mail filtering rules easily
through my Client? Again, I'm happy to be wrong here, but my impression is that
mail on OpenVMS is stuck in the 90's. I've only ever been comfortable using it
with an incoming mail firewall in front, and sending it out via a replay SMTP
server.
-- Jason
ever hear of precisemail. I used it for years with virus scan and had zero
problems. it is sold by process software. also used tcpware ip stack.
wrote my own packet filters. no hacks. try it.
Jason Howe
2017-05-15 23:51:37 UTC
Permalink
Raw Message
Post by u***@gmail.com
ever hear of precisemail. I used it for years with virus scan and had zero
my own packet filters. no hacks. try it.
Thanks for the pointer to that. While I'm familiar with some of Process
Software's wares, I was not with this one. The interesting thing to me is that
Process claims they have "over 3000" customers. That seems like a vanishingly
small number of customers in today's market, but if they are able to keep the
lights on with it, good for them.

The following is not really meant as a criticism, but merely as an observation.
Basically, for additional reasonable mail handling, I need to buy 3 add-on
products (TCPWare/PMDF/Precise) from a different vendor? In a world where stuff
like this is LCD infrastructure (which folks are giving away for free), that's
quite the anachronism.

Now, to be perfectly honest, unless something drastic changes in the world, I'm
unlikely ever to run any my critical home infrastructure (such as
email/DHCP/DNS/NAT/Firewall) on VMS. Not saying, I wounldn't, but pesky things
like cost keep me on BSD/Linux for my personal stuff.
--
Jason
u***@gmail.com
2017-05-15 21:55:16 UTC
Permalink
Raw Message
Post by Jason Howe
Post by Jay Braun
I recall that in the last few years that we used VMS, our sysadmin claimed
that the reason VMS wasn't as susceptible to malware as Windows (and *NIX)
was that "Obscurity is security". Hackers didn't target VMS because it was
such a niche OS.
On the other hand, is VMS inherently less susceptible to malware?
If so, could it not be branded as the ultimate cyber-defensive solution,
e.g., as the server that faces the internet in a large enterprise? Or
perhaps as the server of choice in classified facilities (winning back the
military/government market)?
j
Jay for basic data server and maailserver functions, OpenVMS is the best
period. The webserver is another matter as encryption lags, but for basic data
and mail it is superior.
As a mailserver admin, I'm not sure I agree with your assessment of the
mailservices available on VMS vs a Postgres/Dovecot setup on *nix or even a
Windows Exchange Server.
Just as a quick example, and I'm happy to be wrong here, can a mailserver on
OpenVMS hook into a native virus scanner (like clamav) and a native Baysian spam
filter that can be trained? Can I run server-side mail filtering rules easily
through my Client? Again, I'm happy to be wrong here, but my impression is that
mail on OpenVMS is stuck in the 90's. I've only ever been comfortable using it
with an incoming mail firewall in front, and sending it out via a replay SMTP
server.
-- Jason
PreciseMail Anti-Spam Gateway



PreciseMail Anti-Spam Gateway is an enterprise email security solution that eliminates spam, phishing and virus threats at the Internet gateway or mail server.


Advantages:

Provides complete integrated email security
Proven out-of the-box spam detection accuracy rate of 98% with zero loss of legitimate messages
Easy centralized web-based administration
Intuitive user-controlled spam management
Flexible deployment options for any mail environment
Reliably manages email filtering on multiple MTAs
Comprehensive graphical reporting
Optional Sophos Anti-Virus module
Over 20 years of experience providing messaging solutions to mission critical environments

Why Customers Like PreciseMail

Effective: PreciseMail Anti-Spam Gateway blocks spam, viruses, and phishing threats at the Internet gateway or on the mail server. PreciseMail combines several best-of-breed spam filtering methods to achieve a high spam detection rate - an impressive 98% out-of-the-box in a recent Network World product review - with zero loss of legitimate messages.

Flexible: PreciseMail is a software solution that works with any mail server. PreciseMail can also be integrated directly with Sendmail, Sun's Messaging Server, or Process Software's PMDF.

Easy: PreciseMail's intuitive web-based interface provides each user access to their quarantined messages, and allows easy creation of block lists, allow lists, and modification of spam filtering preferences. The web-based administrator interface centralizes all configuration, reporting, and management tasks.

Process Software is focused on networking and messaging products and services for mission critical networks. In 20 years of business, we've grown our base to over 3,000 customers, which include many Fortune 1000 companies, educational institutes, and government agencies. Some customers include BDP International, Pennsylvania State University, Pride Industries, and Elias Sports Bureau. All our products are backed by a team of sales and support professionals with significant experience assisting organizations with their mission-critical networks.
Loading...