Discussion:
CVE counts, was: Re: VMS Software needs to port VAX DIBOL to OpenVMS X86 platform
(too old to reply)
Simon Clubley
2020-12-16 18:44:46 UTC
Permalink
Sreve do you keep track of the CERT counts for linux and windows. If I was a customer that is the last choice I would make.
[I've put this into its own thread to avoid filling the original
thread with off-topic replies for that thread and to allow people
to easily skip over this discussion.]

Bob, comparing CVE counts is a very poor method when you are
comparing operating systems which are very actively probed every
day by an army of researchers (for Unix/Windows) versus an
operating system which might be probed one in a blue moon (at least
until someone sees the VSI marketing).

My previous one-off attempt to probe VMS for vulnerabilities found
something that could have been used to compromise VAX/VMS and Alpha
VMS over a 33 year period.

That doesn't exactly give me confidence that VMS has had any serious
modern third-party security probing, at least by today's standards.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
m***@gmail.com
2020-12-16 19:15:53 UTC
Permalink
Post by Simon Clubley
Sreve do you keep track of the CERT counts for linux and windows. If I was a customer that is the last choice I would make.
[I've put this into its own thread to avoid filling the original
thread with off-topic replies for that thread and to allow people
to easily skip over this discussion.]
Bob, comparing CVE counts is a very poor method when you are
comparing operating systems which are very actively probed every
day by an army of researchers (for Unix/Windows) versus an
operating system which might be probed one in a blue moon (at least
until someone sees the VSI marketing).
My previous one-off attempt to probe VMS for vulnerabilities found
something that could have been used to compromise VAX/VMS and Alpha
VMS over a 33 year period.
That doesn't exactly give me confidence that VMS has had any serious
modern third-party security probing, at least by today's standards.
Simon.
--
Walking destinations on a map are further away than they appear.
but that bug was only if your were on a local terminal wasn't it?

It had no effect on webservers, telnet or any other remote access correct?
Simon Clubley
2020-12-17 02:04:46 UTC
Permalink
Post by m***@gmail.com
but that bug was only if your were on a local terminal wasn't it?
No.
Post by m***@gmail.com
It had no effect on webservers, telnet or any other remote access correct?
Any remote access method, provided you had access to the DCL command
line, could be used. In fact, that's how I did my research and developed
the example exploit because I connect to VMS over my home LAN.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John Dallman
1970-01-01 00:00:00 UTC
Permalink
Post by Simon Clubley
That doesn't exactly give me confidence that VMS has had any serious
modern third-party security probing, at least by today's standards.
A bit of explaining how the probing is done might help. I only know the
outlines, never having done it, but I have had to fix bugs discovered
using this way.

"Security researchers" are often individuals or very small organisations.
What they do with the security problems they find varies widely.

Some seek "bug bounties" from software publishers, as a way of getting
income. The ones who do this normally publish their finds after a few
months. This may seem unhelpful, but experience has shown that many
software companies never fix security bugs without a deadline, letting
them accumulate, and then getting burned when someone else discovers them.


Others researchers sell their finds to criminals or intelligence agencies,
who have identical needs.

So, how do you do "security research"? One basic technique is "fuzzing",
calling APIs with invalid parameters, sending invalid packets to network
servers, or corrupting files and trying to load them into applications.
This is too slow and tedious for humans, but software can do it just fine,
and looks for crashes and other undesirable behaviour. The modern kind of
statistics-based AI can be applied effectively to this work, and speeds
things up a lot.

Obviously, to do this effectively, you need to be able to run the
software you're attacking, preferably lots of copies, at high speed.
That's why VMS has not been subjected to much of this kind of attack:
small security researchers don't have farms of HP Integrity servers to
use for it.

But when VMS can be run in VMs on commodity x86-64 hardware, attacking it
becomes possible for anyone. Claiming it is "the most secure operating
system on the planet" gives attackers extra motivation.

John
Simon Clubley
2020-12-18 13:36:36 UTC
Permalink
Post by John Dallman
But when VMS can be run in VMs on commodity x86-64 hardware, attacking it
becomes possible for anyone. Claiming it is "the most secure operating
system on the planet" gives attackers extra motivation.
Thank you for the last sentence (seriously). Take note everyone, it's not
just me saying these things. VSI are painting a huge target on the backs
of the VMS community if a researcher notices the idiotic things that VSI
are saying. This is something the VMS community is ill prepared for.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John Dallman
1970-01-01 00:00:00 UTC
Permalink
Post by Simon Clubley
Post by John Dallman
But when VMS can be run in VMs on commodity x86-64 hardware,
attacking it becomes possible for anyone. Claiming it is
"the most secure operating system on the planet" gives
attackers extra motivation.
Thank you for the last sentence (seriously). Take note everyone,
it's not just me saying these things. VSI are painting a huge
target on the backs of the VMS community if a researcher notices
the idiotic things that VSI are saying. This is something the
VMS community is ill prepared for.
A bit more on security researchers might help. They are usually
individuals, or very small organisations. A few large and wealthy
software companies (notably Google) do this work on a large scale, but
most of them see it as expenditure with uncertain returns, and don't
bother.

So the people who are doing the security research often have quite
personal motives. Proving extravagant claims wrong is something many of
them will positively enjoy, so some of them will find VMS worth attacking
if VSI carries on making such claims.

They could work on Windows, or any of the Linuxes, or BSD, or any other
OS that they can run in VMs on x86-64. That includes VMS, and while it
may take them a day or two to port their tools to it, it isn't that
different from more mainstream OSes at the function-call level.

This is part of the price of being in the software business these days.
One has to accept it and deal with it. Denial is useless.

John
Stephen Hoffman
2020-12-18 21:11:38 UTC
Permalink
Post by John Dallman
So, how do you do "security research"? One basic technique is "fuzzing",
Fuzzing is certainly on the list of things to try. Fuzzing isn't
particularly difficult, but it's also not particularly efficient. There
are many APIs, and may permutations to fuzz.
I'd try a few other things first, such as verifying previous fixes are
complete and correct and have not regressed,
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...