[Info-vax] IS everyone waiting?

Simon Clubley clubley at remove_me.eisner.decus.org-Earth.UFP
Fri Oct 21 16:07:45 EDT 2016


On 2016-10-20, David Froble <davef at tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> 
>> Situation 1:
>> 
>> A flaw is discovered in a network stack (whether it's TCP/IP, LAT or
>> DECnet doesn't matter) which allows someone to take down a VMS system
>> remotely at will by exploiting this flaw in the stack without requiring
>> any authentication. This network stack is required for your production
>> operations however and cannot be disabled.
>> 
>> What do you do ?
>
> I'll adopt Jan-Erik's attitude, first, let's see such a flaw.
>

Wait-and-see (and do nothing in the mean time) is certainly an option
open to you, but have you considered how little time you may have to
react once an exploit becomes public ?

What you have to understand is that in today's world, the security
researcher, and not the vendor, is the one in charge of the
disclosure timeline and hence is the one who gets to decide when
details of a vulnerability will be released.

Fortunately, the responsible disclosure protocol also gives the
vendor a reasonable amount of time to create patches before the
researcher makes the vulnerability details public.

Like it or not (and I know you don't) that's the world as it exists
today (and for _very_ good reasons) and it's the world that VSI
voluntarily joined when VSI started writing the stuff they did on
their own website.

An example vulnerability workflow might go something like this:

1) The researcher will contact the vendor with details of the
vulnerability and give them, for example, 2 months to fix it before
announcing the vulnerability details. This might be extended a bit
if the vendor requests more time to fix the problem but that's up
to the researcher to decide.

During this time, you, the owner of the software in question, will
know nothing about this vulnerability and hence cannot do any planning.

2) After a couple of months (or earlier if the patches are released
sooner) the top level details of the vulnerability will become public
knowledge. At this point one of two things will happen:

2a) The security researcher chooses to give the user community some
time to apply the patches before releasing the details. This extra
time might be in the 1-2 months timeframe so this gives you 1-2 months
to decide what you are going to do if you don't have a supported
system.

or

2b) The security researcher chooses to release the exploit details,
along with example code, right away. If you don't have a supported
system, you now have a system with a vulnerability which has now
suddenly become public knowledge without any chance for you to prepare.

> Note, not all internal networks need to be accessible from the internet.
>
> Frankly, I'm sure I'd devise some way to keep the bad guys away from that system.
>
> And, if you have HP support, are you confident they could fix the problem?  Or 
> are you just looking for someone to sue?
>

Suing people seems to be _your_ obsession David, not mine. :-)

No, my goal here is simple: to make people consider various things
instead of just allowing them to stick their head in the sand.

As for the HPE question, no, it's actually a concern of mine about
whether HPE would be able to respond in the timeframe required
when third party researchers start getting involved in probing
VMS security.

However, if you have a support contract, and if your systems are
running a supported VMS version, then you are still going to be
better off than if you are running without support on an old VMS
version.

Oh, and the detailed disclosure of vulnerabilities is normal practice
these days; here's a writeup from The Register from earlier this year:

http://www.theregister.co.uk/2016/02/16/glibc_linux_dns_vulernability/

on the glibc DNS problem.

Simon.

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



More information about the Info-vax mailing list