Time for a new Disaster Proof video ?

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

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Alan Frisbie]

On 04/24/2017 04:53 PM, Simon Clubley wrote:
> 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]

Den 2017-04-25 kl. 01:53, skrev 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]

On 2017-04-25, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
> Den 2017-04-25 kl. 01:53, skrev 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.

[Jan-Erik Soderholm]

Den 2017-04-25 kl. 19:02, skrev Simon Clubley:
> On 2017-04-25, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>> Den 2017-04-25 kl. 01:53, skrev 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... :-)

[IanD]

The fish have died 😎

[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

[David Froble]

IanD wrote:
> 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"?

[Bill Gunshannon]

On 5/2/2017 11:47 AM, IanD wrote:
> 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

[Simon Clubley]

On 2017-05-02, David Froble <da...@tsoft-inc.com> wrote:
>
> 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 ?

[Arne Vajhøj]

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]

Simon Clubley wrote:
> On 2017-05-02, David Froble <da...@tsoft-inc.com> wrote:
>> 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.

[David Froble]

Arne Vajhøj wrote:
> On 5/2/2017 12:27 PM, David Froble wrote:
>> IanD wrote:
>>> 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.

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

No, it hasn't.

[David Froble]

Not into casting down gauntlets, huh?

[Simon Clubley]

On 2017-05-02, David Froble <da...@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> On 2017-05-02, David Froble <da...@tsoft-inc.com> wrote:
>>> 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 ?

[Arne Vajhøj]

On 5/2/2017 3:58 PM, David Froble wrote:
> Arne Vajhøj wrote:
>> On 5/2/2017 12:27 PM, David Froble wrote:
>>> 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]

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

[John Reagan]

On Tuesday, May 2, 2017 at 3:58:49 PM UTC-4, David Froble wrote:

> Don't know if the SMG issue was ever resolved.
>

Fix checked in June 2008.

[Simon Clubley]

On 2017-05-02, IanD <iloveo...@gmail.com> wrote:
>
> 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.

[Stephen Hoffman]

On 2017-05-02 17:17:51 +0000, Simon Clubley said:

> On 2017-05-02, David Froble <da...@tsoft-inc.com> wrote:
>>
>> 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

[David Froble]

Simon Clubley wrote:
> On 2017-05-02, David Froble <da...@tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> On 2017-05-02, David Froble <da...@tsoft-inc.com> wrote:
>>>> 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.

[Stephen Hoffman]

On 2017-05-02 17:54:44 +0000, Arne Vajh j said:

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

[Stephen Hoffman]

On 2017-05-02 19:58:46 +0000, David Froble said:

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

[Scott Dorsey]

David Froble <da...@tsoft-inc.com> wrote:
>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.

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

On 5/3/2017 11:54 AM, Scott Dorsey wrote:
> David Froble <da...@tsoft-inc.com> wrote:
>> 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

[Bill Gunshannon]

On 5/3/2017 11:54 AM, Scott Dorsey wrote:

> David Froble <da...@tsoft-inc.com> wrote:
>> 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

[Scott Dorsey]

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.

[David Froble]

Bill Gunshannon wrote:
> On 5/3/2017 11:54 AM, Scott Dorsey wrote:
>> David Froble <da...@tsoft-inc.com> wrote:
>>> 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?

[David Froble]

Stephen Hoffman wrote:
> On 2017-05-02 19:58:46 +0000, David Froble said:
>
>>> 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.

[Scott Dorsey]

In article <oedt34$7n7$3...@dont-email.me>,

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

[Jay E. Morris]

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]

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

[Stephen Hoffman]

On 2017-05-04 00:44:37 +0000, David Froble said:

> Stephen Hoffman wrote:
>> On 2017-05-02 19:58:46 +0000, David Froble said:
>>
>>>> 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.

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

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

[Bill Gunshannon]

On 5/3/2017 10:07 PM, Stephen Hoffman wrote:
> On 2017-05-04 00:44:37 +0000, David Froble said:
>
>> Stephen Hoffman wrote:
>>> On 2017-05-02 19:58:46 +0000, David Froble said:
>>>
>>>>> 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.
>
>> 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

[Bill Gunshannon]

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

[Paul Sture]

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.

[IanD]

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]

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
warren...@pointsecure.com

[Stephen Hoffman]

On 2017-05-10 19:20:37 +0000, Warren Kahle said:

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

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Warren Kahle via Info-vax
> Sent: May 10, 2017 3:21 PM
> To: comp.os.vms to email gateway <info...@rbnsn.com>
> Cc: Warren Kahle <warren...@pointsecure.com>
> 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
> warren...@pointsecure.com
>

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

[Simon Clubley]

On 2017-05-10, Warren Kahle <warren...@pointsecure.com> wrote:
> 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.

[ultr...@gmail.com]

thats why you run tcpip from process software

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

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

> _______________________________________________
> Info-vax mailing list
> Info...@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>

[Simon Clubley]

On 2017-05-15, Warren Kahle <warren...@pointsecure.com> wrote:
> 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.

[David Froble]

Simon Clubley wrote:
> On 2017-05-15, Warren Kahle <warren...@pointsecure.com> wrote:
>> 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?

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

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

[Stephen Hoffman]

On 2017-05-16 15:30:20 +0000, David Froble said:

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

[Stephen Hoffman]

On 2017-05-16 15:46:17 +0000, Warren Kahle said:

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

[Steven Schweda]

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

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

[John Reagan]

On Tuesday, May 16, 2017 at 12:07:39 PM UTC-4, Stephen Hoffman wrote:
> On 2017-05-16 15:30:20 +0000, David Froble said:
>
> > 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.

[Arne Vajhøj]

On 5/16/2017 2:56 PM, Steven Schweda wrote:
>> 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.

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

[David Froble]

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.

[Arne Vajhøj]

On 5/16/2017 8:19 AM, Simon Clubley wrote:
> 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]

https://groups.google.com/d/msg/comp.os.vms/SxbdqiNfk9M/Twassj19BQAJ

[Stephen Hoffman]

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.