Discussion:
Time for a new Disaster Proof video ?
(too old to reply)
Simon Clubley
2017-04-24 23:53:55 UTC
Permalink
It's been 10 years since the Disaster Proof video.

Is it time for a new Disaster Proof video which shows what VMS
is capable of doing ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Alan Frisbie
2017-04-25 00:04:17 UTC
Permalink
Post by Simon Clubley
It's been 10 years since the Disaster Proof video.
Is it time for a new Disaster Proof video which shows what VMS
is capable of doing ?
I still have the mangled disk drive that was recovered after the
demonstration, probably still with C4 residue on it. I can only
wonder what VSI and/or HP can do to top that demo? The pyromaniac
in me would love to be part of it. :-)

Alan
Jan-Erik Soderholm
2017-04-25 07:24:25 UTC
Permalink
Post by Simon Clubley
It's been 10 years since the Disaster Proof video.
Is it time for a new Disaster Proof video which shows what VMS
is capable of doing ?
Simon.
Why a new? What has changed?
Simon Clubley
2017-04-25 17:02:45 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Simon Clubley
It's been 10 years since the Disaster Proof video.
Is it time for a new Disaster Proof video which shows what VMS
is capable of doing ?
Why a new? What has changed?
The competing operating system environment has completely changed.

A 10 year old Disaster Proof video is irrelevant when it coming to
comparing VMS to today's other operating systems.

It was a very good video indeed but the marketing lifetime of such
a video is probably 2-3 years tops.

OTOH, it would be very interesting to see how VMS would compare to
today's operating systems in a 2017 version of that video.

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-25 17:16:29 UTC
Permalink
Post by Simon Clubley
Post by Jan-Erik Soderholm
Post by Simon Clubley
It's been 10 years since the Disaster Proof video.
Is it time for a new Disaster Proof video which shows what VMS
is capable of doing ?
Why a new? What has changed?
The competing operating system environment has completely changed.
Yes, that was my thought also... :-)
Post by Simon Clubley
A 10 year old Disaster Proof video is irrelevant when it coming to
comparing VMS to today's other operating systems.
It was a very good video indeed but the marketing lifetime of such
a video is probably 2-3 years tops.
OTOH, it would be very interesting to see how VMS would compare to
today's operating systems in a 2017 version of that video.
Simon.
IanD
2017-04-26 08:15:11 UTC
Permalink
The fish have died 😎
IanD
2017-05-02 15:47:37 UTC
Permalink
Even though sparky and his mates would have long gone, I think a video that would turn heads and lead to sales more so than blowing up another DC, would be to show VMS surviving at a DEFCON convention

I however don't believe VMS is currently in a position to risk it yet alone survive an attack
David Froble
2017-05-02 16:27:30 UTC
Permalink
Post by IanD
Even though sparky and his mates would have long gone, I think a video that would turn heads and lead to sales more so than blowing up another DC, would be to show VMS surviving at a DEFCON convention
I however don't believe VMS is currently in a position to risk it yet alone survive an attack
"Belief" ....

I've got to wonder sometimes whether this can be a good thing, or perhaps a
really bad habit?

What actual data do you have to support this "belief"?
Simon Clubley
2017-05-02 17:17:51 UTC
Permalink
Post by David Froble
I've got to wonder sometimes whether this can be a good thing, or perhaps a
really bad habit?
What actual data do you have to support this "belief"?
For starters, has every published CVE which could affect VMS been
evaluated and patches issued for VMS when required ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-05-02 19:53:58 UTC
Permalink
Post by Simon Clubley
Post by David Froble
I've got to wonder sometimes whether this can be a good thing, or perhaps a
really bad habit?
What actual data do you have to support this "belief"?
For starters, has every published CVE which could affect VMS been
evaluated and patches issued for VMS when required ?
Simon.
That is a question, not a fact.
Simon Clubley
2017-05-02 20:24:27 UTC
Permalink
Post by David Froble
Post by Simon Clubley
Post by David Froble
I've got to wonder sometimes whether this can be a good thing, or perhaps a
really bad habit?
What actual data do you have to support this "belief"?
For starters, has every published CVE which could affect VMS been
evaluated and patches issued for VMS when required ?
That is a question, not a fact.
Based on the things you have read here recently from Stephen and others,
what do you think the answer to the question is ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-05-03 15:04:49 UTC
Permalink
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
Post by David Froble
I've got to wonder sometimes whether this can be a good thing, or perhaps a
really bad habit?
What actual data do you have to support this "belief"?
For starters, has every published CVE which could affect VMS been
evaluated and patches issued for VMS when required ?
That is a question, not a fact.
Based on the things you have read here recently from Stephen and others,
what do you think the answer to the question is ?
Simon.
I think that there are some excellent parts of VMS, that there are some not so
good parts, the TCP/IP stuff that has known issues, and some dismal things, such
as OpenSSL.

However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.

As some examples, if networking to the outside, TCP/IP is required, but the
SNMP, NTP, and such are perhaps not. A web server is not required for some
tasks. While one of the worst parts, and actually not part of the OS, OpenSSL
is too often required. (My current biggest bitch.)

I'm not saying there aren't problems. What I am saying is that for some tasks,
a VMS system can be rather secure. It depends on whether the poorer pieces are
required.
Scott Dorsey
2017-05-03 15:54:24 UTC
Permalink
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get. Unix people get it, but
increasingly the Linux systems are being run by people who don't get it.
If people could get that, a lot of security problems would go away right there.
Post by David Froble
I'm not saying there aren't problems. What I am saying is that for some tasks,
a VMS system can be rather secure. It depends on whether the poorer pieces are
required.
It's true, and we know where the efforts need to be concentrated to make things
better, too. But it requires having admins who know what they are doing. And
they won't know if we don't tell them.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2017-05-03 16:35:03 UTC
Permalink
Post by Scott Dorsey
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get. Unix people get it, but
increasingly the Linux systems are being run by people who don't get it.
If people could get that, a lot of security problems would go away right there.
MS is actually somewhat aboard with that. Windows Server Core and the
new Nano Server is driven by this aspect.

Arne
Scott Dorsey
2017-05-03 17:14:08 UTC
Permalink
Post by Arne Vajhøj
Post by Scott Dorsey
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get. Unix people get it, but
increasingly the Linux systems are being run by people who don't get it.
If people could get that, a lot of security problems would go away right there.
MS is actually somewhat aboard with that. Windows Server Core and the
new Nano Server is driven by this aspect.
Oh, yes. It took them a long time, but they are getting with the program
at the same time the Linux people are moving to systemd and abandoning it.

But the actual folks in the field don't get it. Not yet.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Bill Gunshannon
2017-05-03 16:46:23 UTC
Permalink
Post by Scott Dorsey
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get.
Windows people certainly do get it unless you mean granny and her
laptop for exchanging kiddy and kitty pictures.

Both DISA and NIST have published extensive checklist for securing
Windows Server boxes (Desktops, too, but probably not granny's.)
Serious Sys Admins actually apply them. Not everyone relies strictly
on their MCSE bootcamp notes.

bill
David Froble
2017-05-04 00:40:07 UTC
Permalink
Post by Bill Gunshannon
Post by Scott Dorsey
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get.
Windows people certainly do get it unless you mean granny and her
laptop for exchanging kiddy and kitty pictures.
Both DISA and NIST have published extensive checklist for securing
Windows Server boxes
You got any pointers to such checklists?
Scott Dorsey
2017-05-04 00:54:36 UTC
Permalink
Post by David Froble
Post by Bill Gunshannon
Post by Scott Dorsey
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get.
Windows people certainly do get it unless you mean granny and her
laptop for exchanging kiddy and kitty pictures.
Both DISA and NIST have published extensive checklist for securing
Windows Server boxes
You got any pointers to such checklists?
http://scap.nist.gov is a good place to start looking.

However, there is a huge amount of junk in Windows that you just cannot
remove, because it's integrated into something that you need, even though
you don't need the thing itself.

It's the lack of internal modularity that is the problem.

Of course, now we have Unix distributions where you cannot remove Modem
Manager because it's integrated into gnome3....
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Paul Sture
2017-05-04 13:54:17 UTC
Permalink
Post by Scott Dorsey
Post by David Froble
Post by Bill Gunshannon
Post by Scott Dorsey
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get.
Windows people certainly do get it unless you mean granny and her
laptop for exchanging kiddy and kitty pictures.
Both DISA and NIST have published extensive checklist for securing
Windows Server boxes
You got any pointers to such checklists?
http://scap.nist.gov is a good place to start looking.
However, there is a huge amount of junk in Windows that you just cannot
remove, because it's integrated into something that you need, even though
you don't need the thing itself.
It's the lack of internal modularity that is the problem.
Of course, now we have Unix distributions where you cannot remove Modem
Manager because it's integrated into gnome3....
Suse 13.2 was that way, with Samba being baked into all sorts of things
you wouldn't expect, including the GUI login prompt, and, er,
Thunderbird (WTF?).
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
Jay E. Morris
2017-05-04 01:39:14 UTC
Permalink
Post by David Froble
Post by Bill Gunshannon
Post by Scott Dorsey
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get.
Windows people certainly do get it unless you mean granny and her
laptop for exchanging kiddy and kitty pictures.
Both DISA and NIST have published extensive checklist for securing
Windows Server boxes
You got any pointers to such checklists?
http://iase.disa.mil/stigs/Pages/index.aspx

We often had windows boxes tied down so tight we couldn't do hardly
anything. Base usually got dinged with several infractions but not
severe ones.
Bill Gunshannon
2017-05-04 11:42:01 UTC
Permalink
Post by Jay E. Morris
Post by David Froble
Post by Bill Gunshannon
Post by Scott Dorsey
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get.
Windows people certainly do get it unless you mean granny and her
laptop for exchanging kiddy and kitty pictures.
Both DISA and NIST have published extensive checklist for securing
Windows Server boxes
You got any pointers to such checklists?
http://iase.disa.mil/stigs/Pages/index.aspx
We often had windows boxes tied down so tight we couldn't do hardly
anything. Base usually got dinged with several infractions but not
severe ones.
Don't know what "base" you mean, but I was one of the guys trained to
do the "dinging". :-) But not for Windows or VMS. Mostly Network,
Unix and Wireless. Oh yeah, I was also a qualified Team Lead. I used
to like doing that stuff and it translated well to my civilian job, too.
Never had a Windows related breach in all my time at the University and
we were a prime target.

bill
Bill Gunshannon
2017-05-04 01:39:58 UTC
Permalink
Post by David Froble
Post by Bill Gunshannon
Post by Scott Dorsey
Post by David Froble
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
And that's the thing that Windows people don't get.
Windows people certainly do get it unless you mean granny and her
laptop for exchanging kiddy and kitty pictures.
Both DISA and NIST have published extensive checklist for securing
Windows Server boxes
You got any pointers to such checklists?
Not sure DISA still makes them available outside DOD but you could
search for STIGS. The NIST stuff is probably available from NIST.
They publish all the time. Being retired, I really don't chase that
stuff much anymore. But, I'll take a look and post if I find anything.
Too bad they dumped all the VMS stuff.

bill
u***@gmail.com
2017-05-14 10:42:04 UTC
Permalink
Post by David Froble
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
Post by David Froble
I've got to wonder sometimes whether this can be a good thing, or perhaps a
really bad habit?
What actual data do you have to support this "belief"?
For starters, has every published CVE which could affect VMS been
evaluated and patches issued for VMS when required ?
That is a question, not a fact.
Based on the things you have read here recently from Stephen and others,
what do you think the answer to the question is ?
Simon.
I think that there are some excellent parts of VMS, that there are some not so
good parts, the TCP/IP stuff that has known issues, and some dismal things, such
as OpenSSL.
However, not all VMS installations are the same. In a production environment
you use what is required, and don't use what isn't required.
As some examples, if networking to the outside, TCP/IP is required, but the
SNMP, NTP, and such are perhaps not. A web server is not required for some
tasks. While one of the worst parts, and actually not part of the OS, OpenSSL
is too often required. (My current biggest bitch.)
I'm not saying there aren't problems. What I am saying is that for some tasks,
a VMS system can be rather secure. It depends on whether the poorer pieces are
required.
thats why you run tcpip from process software
Warren Kahle
2017-05-15 19:40:28 UTC
Permalink
I do not remember the details about the 2008 effort but I do know that the
VMS system was not running System Detective to enhance the native VMS
security.

*Warren Kahle* CISSP
CSA CSE Security+
PointSecure Technologies Inc.
Phone: 713-868-1222
Cell: 713-906-5600
***@pointsecure.com

On Sun, May 14, 2017 at 5:42 AM, ultradwc--- via Info-vax <
Post by David Froble
Post by David Froble
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
Post by David Froble
I've got to wonder sometimes whether this can be a good thing, or
perhaps a
Post by David Froble
Post by Simon Clubley
Post by David Froble
Post by Simon Clubley
Post by David Froble
really bad habit?
What actual data do you have to support this "belief"?
For starters, has every published CVE which could affect VMS been
evaluated and patches issued for VMS when required ?
That is a question, not a fact.
Based on the things you have read here recently from Stephen and
others,
Post by David Froble
Post by Simon Clubley
what do you think the answer to the question is ?
Simon.
I think that there are some excellent parts of VMS, that there are some
not so
Post by David Froble
good parts, the TCP/IP stuff that has known issues, and some dismal
things, such
Post by David Froble
as OpenSSL.
However, not all VMS installations are the same. In a production
environment
Post by David Froble
you use what is required, and don't use what isn't required.
As some examples, if networking to the outside, TCP/IP is required, but
the
Post by David Froble
SNMP, NTP, and such are perhaps not. A web server is not required for
some
Post by David Froble
tasks. While one of the worst parts, and actually not part of the OS,
OpenSSL
Post by David Froble
is too often required. (My current biggest bitch.)
I'm not saying there aren't problems. What I am saying is that for some
tasks,
Post by David Froble
a VMS system can be rather secure. It depends on whether the poorer
pieces are
Post by David Froble
required.
thats why you run tcpip from process software
_______________________________________________
Info-vax mailing list
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
Simon Clubley
2017-05-16 12:19:12 UTC
Permalink
Post by Warren Kahle
I do not remember the details about the 2008 effort but I do know that the
VMS system was not running System Detective to enhance the native VMS
security.
Basically, they found a buffer overflow in SMG which is used in some
VMS supplied programs installed with privileges.

It was exploitable because VMS does not have no-execute on data-only
pages so they were able to put their shellcode into a logical and jump
to the address of the logical.

I'm having a hard time seeing how System Detective (based on what
I have seen mentioned about it) would have stopped that.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-05-16 15:30:20 UTC
Permalink
Post by Simon Clubley
Post by Warren Kahle
I do not remember the details about the 2008 effort but I do know that the
VMS system was not running System Detective to enhance the native VMS
security.
Basically, they found a buffer overflow in SMG which is used in some
VMS supplied programs installed with privileges.
It was exploitable because VMS does not have no-execute on data-only
pages so they were able to put their shellcode into a logical and jump
to the address of the logical.
I'm having a hard time seeing how System Detective (based on what
I have seen mentioned about it) would have stopped that.
Simon.
I'm not privy to how a buffer overflow happened in SMG. Maybe someone could
report this?

However, usually when one reads about buffer overflow, it's in combination with
zero terminated strings. Perhaps using languages which do not support such
would be a beginning to a solution? It appears that wanna-be programmers just
cannot learn to "just don't use zero terminated strings".

Seems tome that it always comes back to coders who are clueless about what they
write could do?
Stephen Hoffman
2017-05-16 16:07:36 UTC
Permalink
Post by David Froble
I'm not privy to how a buffer overflow happened in SMG. Maybe someone
could report this?
However, usually when one reads about buffer overflow, it's in
combination with zero terminated strings. Perhaps using languages
which do not support such would be a beginning to a solution? It
appears that wanna-be programmers just cannot learn to "just don't use
zero terminated strings".
Seems tome that it always comes back to coders who are clueless about
what they write could do?
There's a write-up around on the flaw. Somewhere.

The SMG bug was due to not accounting for control sequences used for
sizing buffers.

https://groups.google.com/d/msg/comp.os.vms/gMJEqgbM9k8/KPCWvCCbzKIJ

That mess is also when I realized I needed to know much more about
system and network security, and that what was often the norm for
security on OpenVMS was badly dated, but I digress.

SMG has been around since the mid-1980s and a VAX/VMS release far too
long gone. The developers working on SMG and the terminal driver and
the I/O stack weren't beginners, either. Far from it. One look at
the smg$create_menu descriptor usage would indicate more than a passing
knowledge of descriptors, too.

Code of that era within OpenVMS was written in Bliss or Macro, and both
Bliss and Macro32 are akin to C in terms of the pointer messes
possible. SMG well predates the era of C usage in OpenVMS, too.

Given that OpenVMS is now written in C with somewhat lesser and
still-substantial amounts of Bliss and Macro32, rewriting the whole
operating system into some other language is a non-starter, too.
Which means that implementing and using fuzzing, implementing
code-scanning tools, and other techniques, are likely to be involved
sooner or later in automated-scanning for issues. Maybe incrementally
reworking and writing new code in different languages with better
robustness.

Developers make mistakes. Even experienced developers make mistakes.
This is why I've been pointing to newer programming languages, and
toward sandboxes and pledges, at mechanisms for easier and faster
patches, and at other related techniques for improving security and app
isolation. At two-factor authentication, for that matter. At ways
of reducing and isolating the sorts of problems that can and do and
will arise, and at increasing the effort involved for the attackers
seeking to exploit security vulnerabilities. Pointing at developers
and at end-users has worked so well for us all, after all. We all
make mistakes. Which means... pragmatically, how do we deal with that,
and how do we harden our systems and applications and our end-user and
network environments?
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2017-05-16 20:18:08 UTC
Permalink
Post by Stephen Hoffman
Post by David Froble
I'm not privy to how a buffer overflow happened in SMG. Maybe someone
could report this?
However, usually when one reads about buffer overflow, it's in
combination with zero terminated strings. Perhaps using languages
which do not support such would be a beginning to a solution? It
appears that wanna-be programmers just cannot learn to "just don't use
zero terminated strings".
Seems tome that it always comes back to coders who are clueless about
what they write could do?
There's a write-up around on the flaw. Somewhere.
The SMG bug was due to not accounting for control sequences used for
sizing buffers.
I've looked at the edit. It has nothing to do with nul-terminated strings. It has nothing to do with descriptors. It is dealing with the return data from a $QIOW dealing with escape sequences. It was overwriting a buffer in an internal data structure. Feel free to blame $QIO or the terminal driver.
David Froble
2017-05-17 00:36:53 UTC
Permalink
Post by John Reagan
Post by Stephen Hoffman
Post by David Froble
I'm not privy to how a buffer overflow happened in SMG. Maybe someone
could report this?
However, usually when one reads about buffer overflow, it's in
combination with zero terminated strings. Perhaps using languages
which do not support such would be a beginning to a solution? It
appears that wanna-be programmers just cannot learn to "just don't use
zero terminated strings".
Seems tome that it always comes back to coders who are clueless about
what they write could do?
There's a write-up around on the flaw. Somewhere.
The SMG bug was due to not accounting for control sequences used for
sizing buffers.
I've looked at the edit. It has nothing to do with nul-terminated strings. It has nothing to do with descriptors. It is dealing with the return data from a $QIOW dealing with escape sequences. It was overwriting a buffer in an internal data structure. Feel free to blame $QIO or the terminal driver.
Thanks John. I had no knowledge of the problem.

And yes Steve, I've made more mistakes than I care to count. Probably the
biggest ones are when I make assumptions.
Steven Schweda
2017-05-16 18:56:23 UTC
Permalink
Post by David Froble
However, usually when one reads about buffer overflow, it's
in combination with zero terminated strings. [...]
Not this one. Info-ZIP UnZip has earned some such
complaints in recent years, none of which, as I recall,
involved NUL-terminated strings. Most involved invalid (or
very unlikely) data in an archive, and programmers who were
more concerned with getting good output from expected data
than with staying inside a buffer when unexpected data were
processed. For example, the biggest known zip compression
method code is 99 (actually denoting AES encryption), so
what's wrong with using a two- or three-character field for
displaying it? Nothing, except that it's really a 16-bit
number, so, even in hexadecimal, you might need four
characters for it.
Post by David Froble
Perhaps using languages which do not support such
would be a beginning to a solution? It appears that
wanna-be programmers just cannot learn to "just don't use
zero terminated strings".
And some seem to believe that C is the source of all evil,
and that all programming errors involve NUL-terminated
strings. Self-delusion is popular, but "wisdom" is spelled
differently for a reason.
Arne Vajhøj
2017-05-16 23:38:44 UTC
Permalink
Post by Steven Schweda
Post by David Froble
However, usually when one reads about buffer overflow, it's
in combination with zero terminated strings. [...]
Not this one. Info-ZIP UnZip has earned some such
complaints in recent years, none of which, as I recall,
involved NUL-terminated strings.
Post by David Froble
Perhaps using languages which do not support such
would be a beginning to a solution? It appears that
wanna-be programmers just cannot learn to "just don't use
zero terminated strings".
And some seem to believe that C is the source of all evil,
and that all programming errors involve NUL-terminated
strings. Self-delusion is popular, but "wisdom" is spelled
differently for a reason.
Buffer overflows are just one of many possible vulnerabilities.

But it is one of the more common types.

And I am pretty sure that a large portion of those
come from C char arrays and various string processing.

There are of course also other ways. I remember moving
Fortran code from VMS VAX where everything was zero initialized
to another platform where not so - instead of just using
the position just before array start which the program survived
then we got an access violation for being way out of
used memory space. It made it a lot easier to find bugs.

Arne
Warren Kahle
2017-05-16 15:46:17 UTC
Permalink
System Detective will not detect the buffer overflow itself. The code
executed would have to violate some security rule in System Detective and
then System Detective could take action based on the rule violated. For
example, if the code tried to open a file that was protected by a System
Detective rule then System Detective could take action which might include
creating a security event, sending a message to the user to not do that,
and running down the image. System Detective can detect a lot of things
and take a wide variety of actions but it can not detect a buffer overflow
allowed by the programmer. The programmer should still treat any input
field carefully and not allow a buffer overflow.

*Warren Kahle* CISSP
CSA CSE Security+
PointSecure Technologies Inc.
Phone: 713-868-1222
Cell: 713-906-5600
***@pointsecure.com

On Tue, May 16, 2017 at 7:19 AM, Simon Clubley via Info-vax <
Post by Simon Clubley
Post by Warren Kahle
I do not remember the details about the 2008 effort but I do know that
the
Post by Warren Kahle
VMS system was not running System Detective to enhance the native VMS
security.
Basically, they found a buffer overflow in SMG which is used in some
VMS supplied programs installed with privileges.
It was exploitable because VMS does not have no-execute on data-only
pages so they were able to put their shellcode into a logical and jump
to the address of the logical.
I'm having a hard time seeing how System Detective (based on what
I have seen mentioned about it) would have stopped that.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
_______________________________________________
Info-vax mailing list
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
Stephen Hoffman
2017-05-16 16:19:31 UTC
Permalink
Post by Warren Kahle
System Detective will not detect the buffer overflow itself. The code
executed would have to violate some security rule in System Detective
and then System Detective could take action based on the rule violated.
For example, if the code tried to open a file that was protected by a
System Detective rule then System Detective could take action which
might include creating a security event, sending a message to the user
to not do that, and running down the image. System Detective can
detect a lot of things and take a wide variety of actions but it can
not detect a buffer overflow allowed by the programmer. The programmer
should still treat any input field carefully and not allow a buffer
overflow.
Barring (maybe) running in an enclave and routing the scans through
that enclave... When the exploit is already running code in kernel
mode, then internal security and any add-on security is game over.

With kernel-mode access, I can reset the System Detective interception
hooks or otherwise pass the scanner or the auditing mechanisms
innocuous data or can pretend to be an authorized accessor, which means
the tools are unreliable at best. Toss nefarious PKASTs at some
authorized-to-access process or tool, and away we go...

That presumes I don't simply attack the security and the tools
directly, and shut off the logging mechanisms, for instance. Which
means the tools then get mired into detect these cases and these
attacks, which means conflicting hackery in the kernel, which usually
ends up looking like the weird hangs and instabilities and crashes that
anti-malware and malware always tend to get into on various platforms.

Anti-malware tools are hugely popular targets right now, too. Within
Windows environments, the anti-malware tools are themselves exploited.

Or do I entirely misunderstand the sorts of attacks against OpenVMS
security and against add-on security packages that are possible, given
an attacker with kernel-mode write and execute access?
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2017-05-17 01:44:17 UTC
Permalink
Post by Simon Clubley
It was exploitable because VMS does not have no-execute on data-only
pages so they were able to put their shellcode into a logical and jump
to the address of the logical.
VMS has some of the required stuff to implement it
in place. psect noexe and PTE fault-on-execute bit.

But something is missing.

Arne
hb
2017-05-17 07:28:13 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
It was exploitable because VMS does not have no-execute on data-only
pages so they were able to put their shellcode into a logical and jump
to the address of the logical.
VMS has some of the required stuff to implement it
in place. psect noexe and PTE fault-on-execute bit.
But something is missing.
https://groups.google.com/d/msg/comp.os.vms/SxbdqiNfk9M/Twassj19BQAJ
Stephen Hoffman
2017-05-17 12:58:00 UTC
Permalink
Post by Simon Clubley
It was exploitable because VMS does not have no-execute on data-only
pages so they were able to put their shellcode into a logical and jump
to the address of the logical.
VMS has some of the required stuff to implement it in place. psect
noexe and PTE fault-on-execute bit.
But something is missing.
W^X, ASLR, etc

Write or Execute page protections by default, and Address Space Layout
Randomization at compile and/or at run-time, and sandboxing, and
pledges, and stack canaries, and...

Write-up on OpenBSD exploit mitigation from a dozen years ago, and an update:
http://www.openbsd.org/papers/ven05-deraadt/index.html
https://events.yandex.com/lib/talks/103/

Apps containing JITs are going to need remedial work or an exception if
W^X is to be used, and there are poorly-written apps that blow up when
security features are enabled.

Getting to sandboxed and signed code, or to implement pledges for that
matter, takes some work in the app source code, too. That starts out
in the vendor apps and (hopefully) spreads.

Sandboxes are useful for various reasons beyond app and network
security, as it makes those apps far easier to stuff together and
coexist on a box via containers or PCSI or whatever, and easier to
remove from the system, and easier to verify the integrity of the app
files.

Then there's getting updates tested and deployed expeditiously, too.
Pragmatically, a number of the OpenVMS servers and network-facing
applications are no better off than those under-patched Windows XP
systems.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2017-05-03 15:01:33 UTC
Permalink
Post by Simon Clubley
Post by David Froble
I've got to wonder sometimes whether this can be a good thing, or
perhaps a really bad habit?
What actual data do you have to support this "belief"?
For starters, has every published CVE which could affect VMS been
evaluated and patches issued for VMS when required ?
Nope. VSI IP will help with some of that backlog, certainly.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2017-05-02 17:54:44 UTC
Permalink
Post by David Froble
Post by IanD
Even though sparky and his mates would have long gone, I think a video
that would turn heads and lead to sales more so than blowing up
another DC, would be to show VMS surviving at a DEFCON convention
I however don't believe VMS is currently in a position to risk it yet
alone survive an attack
"Belief" ....
I've got to wonder sometimes whether this can be a good thing, or
perhaps a really bad habit?
What actual data do you have to support this "belief"?
Hoff has posted a list of several not so good things security
wise several times.

And VMS has not been tested nearly as much as some other OS'es.

You can call expecting security bugs to be present in limited tested
code base a "belief". But I think it is a justified belief. Programmers
make mistakes. All programmers.

Arne
David Froble
2017-05-02 19:58:46 UTC
Permalink
Post by Arne Vajhøj
Post by David Froble
Post by IanD
Even though sparky and his mates would have long gone, I think a video
that would turn heads and lead to sales more so than blowing up
another DC, would be to show VMS surviving at a DEFCON convention
I however don't believe VMS is currently in a position to risk it yet
alone survive an attack
"Belief" ....
I've got to wonder sometimes whether this can be a good thing, or
perhaps a really bad habit?
What actual data do you have to support this "belief"?
Hoff has posted a list of several not so good things security
wise several times.
Yes, he has. But I don't recall any being part of the OS. A bunch in the
TCP/IP package. Don't know if the SMG issue was ever resolved.

But without a web server, and the questionable TCP/IP stuff, is it all that
dangerous?

Yeah, yeah, I know, if you're not running TCP/IP, it's secure cause nobody can
access the system, at least via the internet.
Post by Arne Vajhøj
And VMS has not been tested nearly as much as some other OS'es.
No, it hasn't.
Post by Arne Vajhøj
You can call expecting security bugs to be present in limited tested
code base a "belief". But I think it is a justified belief. Programmers
make mistakes. All programmers.
Arne Vajhøj
2017-05-02 20:28:23 UTC
Permalink
Post by David Froble
Post by Arne Vajhøj
Post by David Froble
What actual data do you have to support this "belief"?
Hoff has posted a list of several not so good things security
wise several times.
Yes, he has. But I don't recall any being part of the OS. A bunch in
the TCP/IP package. Don't know if the SMG issue was ever resolved.
But without a web server, and the questionable TCP/IP stuff, is it all
that dangerous?
Yeah, yeah, I know, if you're not running TCP/IP, it's secure cause
nobody can access the system, at least via the internet.
Time has changed.

I remember when the VMS people was laughing at Windows because
to get NT (3.1 or 3.5 not sure) C2 certified they had to remove
all networking.

Now we want to claim VMS is secure by removing network
support (DECNet is typical not routed anywhere today - and
it has its own problems as well).

Arne
IanD
2017-05-02 21:15:40 UTC
Permalink
First let's understand the context of what I posted

It was to say that a demonstration of VMS surviving at DEFCON would produce more sales than a video displaying a DC being blown up. I based this 'fact' on annecdotal evidence that the IT security industry spending exceeds disaster tolerance spending by orders of magnitude

I.e. If you want to bolster future income for VMS then security would be a great focus

I then when on to give a method by which one may demonstrate this in a forum and context that is world recognised, DEFCON

I then listed a caviet, namely that VMS would however need work and gave my personal view

Let's look at other factors. VMS fell to attack rather easily and by methods long patched beforehand on other TCP stacks, indicating the VMS code base was behind and probably by indication not being maintained from a security perspective

Oh, it's a TCP problem. I remember years ago, a hacker who got into Citibank and did so by a simple decnet tweak at the time. He simply joined the network and went from there. I don't have the interview he gave though. So it is not just the evil TCP, security holes have existed elsewhere

More frightening was the mentality of Dec and others after them that took the approach of hiding security issues unless they either were on the verge of being made public and become embarrassing or were the result of a specific hack

This security by obscurity mindset was intrenched in Dec and the others after them for a very long time. Who knows what other ignored security holes exists elsewhere.

The world moved on. Security is no longer something done on secret. Cryptography is a classic example of how opening up security to scrutiny has fortified the technology. No algorithm today would ever see the light of day unless it was peer reviewed, this is in essence what DEFCON has become, a place where you can gather and have the tyres of your system kicked

Hoff has given some specific areas where security attack vectors exist

I've seen no evidence that VMS has been tested against vonrabilities to this types of attacks, only obscurity, which is no defense against them at all

We are looking for positive verification that a system has passed testing, not verification that it should seems to be ok because no one has actually tested it against attack
Simon Clubley
2017-05-03 12:32:47 UTC
Permalink
Post by IanD
More frightening was the mentality of Dec and others after them that took
the approach of hiding security issues unless they either were on the verge
of being made public and become embarrassing or were the result of a
specific hack
I wonder if VSI will undertake to submit CVE reports (and in a timely
manner) for any VMS security issues they receive which are not already
going through the CVE process.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
John Reagan
2017-05-02 23:34:14 UTC
Permalink
Post by David Froble
Don't know if the SMG issue was ever resolved.
Fix checked in June 2008.
Stephen Hoffman
2017-05-03 15:53:26 UTC
Permalink
Post by David Froble
Hoff has posted a list of several not so good things security wise
several times.
Yes, he has. But I don't recall any being part of the OS.
Is there a salient difference between getting owned by an OS-level flaw
— which do exist, and have been discussed here, BTW — and getting owned
by a network service?

The defender has to keep everything locked down and secure, and the
attacker has to find but one hole — possibly in a down-revision printer
or a down-revision AMT instance, for instance — and can then seek to
extend that access, and the attacker doesn't care if it's the use of
telnet or DECnet or FTP SCS that allowed further access, or if it is a
flaw in some down-revision network server.

This is also why I rant about even having telnet and FTP in the default
set, why I rant about software updates and mechanisms, and why I think
VSI IP is going to help, too... Because the attackers don't
differentiate what and where they're willing to look for
vulnerabilities in the target systems.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-05-04 00:44:37 UTC
Permalink
Post by Stephen Hoffman
Post by David Froble
Hoff has posted a list of several not so good things security wise
several times.
Yes, he has. But I don't recall any being part of the OS.
Is there a salient difference between getting owned by an OS-level flaw
— which do exist, and have been discussed here, BTW — and getting owned
by a network service?
From the perspective of being hacked, no.

From the perspective of what allowed it to happen, yes, there is a big
difference. For one thing, it points to what needs some attention.

I've basically stopped doing any work on network communications until VSI has
their IP product and SSL product available. I'm hoping that will be a huge
improvement.
Stephen Hoffman
2017-05-04 02:07:58 UTC
Permalink
Post by David Froble
Post by Stephen Hoffman
Post by David Froble
Hoff has posted a list of several not so good things security wise
several times.
Yes, he has. But I don't recall any being part of the OS.
Is there a salient difference between getting owned by an OS-level flaw
— which do exist, and have been discussed here, BTW — and getting owned
by a network service?
From the perspective of being hacked, no.
From most any perspective. Attackers don't care where the hole is.
Post by David Froble
From the perspective of what allowed it to happen, yes, there is a big
difference. For one thing, it points to what needs some attention.
Ayup. Why do you think I've been grumbling about ftp, telnet and
DECnet available in the default configuration, too? When the easy
stuff is wide open and when the users are not guided to more secure
configurations, expending much development effort on ASLR and
execute-disable support is wasted. Fixing the simple holes. As for
remedial and refactoring work on the platform itself, bug counts are
useful metrics for scheduling remedial work, but not so useful for
scheduling security work. Not unless the testing folks involved have
some experience cracking systems and are correspondingly ruthless about
finding and logging security bugs, and get the time to run API and
protocol and file-format fuzzers and network protocol analysis tools
and simulated attacks against... everything. Again, defenders get to
try to find and plug all the holes.

No, I don't believe that all OpenVMS servers will always have skilled
teams managing and tracking the security, nor security-focused
developers working to update and securing the applications. Look
around for how many servers have telnet and ftp configured, after all.
Look around at how many developers either have code in production that
is — given a little thought — known to be insecure, or that haven't
even had the time to consider application security, for that matter.
Post by David Froble
I've basically stopped doing any work on network communications until
VSI has their IP product and SSL product available. I'm hoping that
will be a huge improvement.
There's already a VSI TLS kit around, though we'll see what the VSI IP
and the sockets and TLS and certificates APIs look like. The current
"design" of these areas and APIs is... problematic. This as anybody
that's actually used what's available and has tried to implement
certificate chains and pinning and revocation handling can certainly
attest. Heaps and heaps of glue code, and more than a few
opportunities for vulnerabilities, and the available example code is...
lacking.
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2017-05-04 11:37:18 UTC
Permalink
Post by Stephen Hoffman
Post by David Froble
Post by Stephen Hoffman
Post by David Froble
Hoff has posted a list of several not so good things security wise
several times.
Yes, he has. But I don't recall any being part of the OS.
Is there a salient difference between getting owned by an OS-level
flaw — which do exist, and have been discussed here, BTW — and
getting owned by a network service?
From the perspective of being hacked, no.
From most any perspective. Attackers don't care where the hole is.
Post by David Froble
From the perspective of what allowed it to happen, yes, there is a big
difference. For one thing, it points to what needs some attention.
Ayup. Why do you think I've been grumbling about ftp, telnet and
DECnet available in the default configuration, too? When the easy
stuff is wide open and when the users are not guided to more secure
configurations, expending much development effort on ASLR and
execute-disable support is wasted. Fixing the simple holes.
While people here insisted that VMS was totally secure I repeatedly
mentioned the (now defunct) DISA STIG for VMS. What do you think was
in it? All the things that VMS shipped with insecure default entries.

By the way, a Google search for STIG will find all the available ones
(sans VMS).

bill
Stephen Hoffman
2017-05-03 15:24:11 UTC
Permalink
Hoff has posted a list of several not so good things security wise
several times.
Accumulating a lengthy list of CVEs that likely apply to OpenVMS
components isn't difficult, either. I've a hundred or two that either
do apply, or that I suspect apply and haven't bothered verifying. A
far longer list than what was (is?) posted on the VSI web site. VSI
IP will address a number of those, but the effort is ongoing. Not
that comparing CVE counts is anything other than a snow job. Known
and fundamental security issues in many common OpenVMS configurations,
too, such as the unencrypted DECnet and SCS transports. Which don't
currently have CVEs assigned.
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2017-05-02 17:02:19 UTC
Permalink
Post by IanD
Even though sparky and his mates would have long gone, I think a video that would turn heads and lead to sales more so than blowing up another DC, would be to show VMS surviving at a DEFCON convention
I however don't believe VMS is currently in a position to risk it yet alone survive an attack
Just how hard would it be for VMS to survive being totally ignored
at DEFCON? People have to see VMS as relevant before you can expect
DEFCON to pay any attention to it at all.

bill
David Froble
2017-05-02 19:59:46 UTC
Permalink
Post by Bill Gunshannon
Post by IanD
Even though sparky and his mates would have long gone, I think a video
that would turn heads and lead to sales more so than blowing up
another DC, would be to show VMS surviving at a DEFCON convention
I however don't believe VMS is currently in a position to risk it yet
alone survive an attack
Just how hard would it be for VMS to survive being totally ignored
at DEFCON? People have to see VMS as relevant before you can expect
DEFCON to pay any attention to it at all.
bill
Not into casting down gauntlets, huh?
IanD
2017-05-10 12:39:02 UTC
Permalink
Post by Bill Gunshannon
Post by IanD
Even though sparky and his mates would have long gone, I think a video that would turn heads and lead to sales more so than blowing up another DC, would be to show VMS surviving at a DEFCON convention
I however don't believe VMS is currently in a position to risk it yet alone survive an attack
Just how hard would it be for VMS to survive being totally ignored
at DEFCON? People have to see VMS as relevant before you can expect
DEFCON to pay any attention to it at all.
bill
How will people see VMS as relevant?

What aspects of VMS are people going to say is unique and worth throwing money at?

What is / will be VMS's unique branding? (The branding question I have asked before. General purpose isn't a brand, its a loose category and like loose clothing can look shabby when compared to a sharp looking suite that fits the occasion, such is the nature of branding)

It used to be clustering that was VMS's forte but the world built its own solution that far exceeds the capabilities of a VMS cluster now, especially at scale

Uptime? No one really cares about that old metric anymore not when you have the likes of VM's and besides that, OS's like BSD flavors have incredible uptime now. Even windows supports rolling upgrades, another VMS differentiator mitigated away.

I've said something akin to what Tandem used to have, fault tolerance at the process level. Unstoppable compute processes would be nice, although even this concept now has by somewhat bypassed with the likes of Hadoop spinning up multiple processes, some in redundancy so that should some fail the compute operation can simply continue

Security is one area that VMS did have a good reputation in, so bolstering this would be easier than establishing something from scratch

As to the requirements of DEFCON, there is no reputation needed to compete or be of interest there

Register, enter a competition and then they'll come and probe your system, you don't need a reputation before someone will bother looking for a weakness in your system

If you want to get ignored then enter perhaps an abacus and ask for a security review

Are people really that confident that VMS would stand up to a modern attack at DEFCON? I'm not. I used to be until I started doing courses in security and got woken up to the incredible sophistication that attackers will go to now. Its no longer script kiddies performing these attacks but highly resourced entities with deep pockets and with political and/or financial motivation

At least the journey has begun for the VMS journey to modernisation but no-one should be thinking that VMS in its current state would survive a dedicated hacking attempt
Warren Kahle
2017-05-10 19:20:37 UTC
Permalink
Old times bring back old memories. Many years ago, PointSecure took a VMS
system with its security augmented by PointSecure's System Detective
security product to DEFCON where it was declared to be "cool and
unhackable". They invited us not to come back and I understand that they
changed the rules to require that the system to be hacked had to be some
flavor of Windows or UNIX. VMS, System Detective, and hackers have come a
long way since those days.

*Warren Kahle* CISSP
CSA CSE Security+
PointSecure Technologies Inc.
Phone: 713-868-1222
Cell: 713-906-5600
***@pointsecure.com
Stephen Hoffman
2017-05-10 19:56:53 UTC
Permalink
Post by Warren Kahle
Old times bring back old memories. Many years ago, PointSecure took a
VMS system with its security augmented by PointSecure's System
Detective security product to DEFCON where it was declared to be "cool
and unhackable". They invited us not to come back and I understand
that they changed the rules to require that the system to be hacked had
to be some flavor of Windows or UNIX. VMS, System Detective, and
hackers have come a long way since those days.
It was and remains common to subset computer configurations into
security. The euphemism here is the "evaluated configuration".
This still arises in discussions, when key hunks of the server
configuration — such as networking or clustering — are excluded from
the evaluated configuration or from the security discussions, or when
the network is assumed to be secure. An isolated and non-networked
OpenVMS server is still secure against most attacks, too. Most
servers are not in and cannot use those isolated configurations though,
and it's a whole lot less certain that even the supposedly-isolated
network segments actually remain as such. If the network segments even
started out as secure. Everybody has loaded those just-released Cisco
switch patches, right? And if the OpenVMS servers are running SCS,
DECnet, telnet, or ftp... Even running OpenVMS servers in those
subsetted and properly-locked-down configurations is increasingly
interesting as the exploits are arriving as fast or faster than the
patches, too.

The goal has to be what's expected and necessary for current systems
and particularly for 2021 and 2027. About what's needed now and going
forward. Not about some DEFCON slogan that's now old enough to have
a driver's license in many US jurisdictions.

VSI knows about many of these issues — and undoubtedly also knows about
some issues that most of us don't, too — and they're working on what
they can, and as fast as they can. The necessary work — and whatever
great new ideas and implementations VSI designs and builds — will take
a while to become available, though. But the port and the profits
come first.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-05-13 19:30:33 UTC
Permalink
Post by Warren Kahle
Old times bring back old memories. Many years ago, PointSecure took a VMS
system with its security augmented by PointSecure's System Detective
security product to DEFCON where it was declared to be "cool and
unhackable". They invited us not to come back and I understand that they
changed the rules to require that the system to be hacked had to be some
flavor of Windows or UNIX. VMS, System Detective, and hackers have come a
long way since those days.
I don't know if you are aware, but several years later (in 2008)
a team did find vulnerabilities in VMS at DEFCON.

The resulting fallout was well discussed in comp.os.vms at the time.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Kerry Main
2017-05-12 01:12:46 UTC
Permalink
-----Original Message-----
Warren Kahle via Info-vax
Sent: May 10, 2017 3:21 PM
Subject: Re: [Info-vax] Time for a new Disaster Proof video ?
Old times bring back old memories. Many years ago, PointSecure took a
VMS
system with its security augmented by PointSecure's System Detective
security product to DEFCON where it was declared to be "cool and
unhackable". They invited us not to come back and I understand that
they
changed the rules to require that the system to be hacked had to be
some
flavor of Windows or UNIX. VMS, System Detective, and hackers have OpenVMS
come a
long way since those days.
*Warren Kahle* CISSP
CSA CSE Security+
PointSecure Technologies Inc.
Phone: 713-868-1222
Cell: 713-906-5600
I would love to see a future DEFCON event with a I4 system running the latest versions of VSI OpenVMS, WASD and System Detective releases installed.

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Loading...