[Info-vax] DECnet Phase IV and VMS code comments

[Dirk Munk]

Kerry Main wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
>> Of Dirk Munk via Info-vax
>> Sent: 26-Nov-16 3:53 AM
>> To: info-vax at rbnsn.com
>> Cc: Dirk Munk <munk at home.nl>
>> Subject: Re: [Info-vax] DECnet Phase IV and VMS code comments
>>
>> Simon Clubley wrote:
>>> On 2016-11-25, Dirk Munk <munk at home.nl> wrote:
>>>>
>>>> My question is, why are you interested in this very old
>> protocol?
>>>
>>> If you were thinking like a security researcher, then it
> would be
>>> obvious why. :-) However, since it's probably not clear to
>> various
>>> people, here is the explanation.
>>>
>>> First off, I'm not interested in DECnet Phase IV as a
> protocol to
>> be
>>> used. It's an insecure and obsolete protocol and if you are
>> actually
>>> using it (as opposed to just having it enabled) on a network
> that
>> you
>>> don't 100% control then you don't really care about the
> security
>> of
>>> your VMS boxes.
>>
>> I would never enable Phase IV on a VMS system, or Phase V in
>> Phase IV compatibility mode, if it was only to prevent the same
>> MAC address appearing on all Ethernet interfaces. In the past
>> there were more network protocols that used the MAC address
>> to identify systems with that protocol. A very obsolete method,
>> dating from the time that is was unheard of to use more then
> one
>> Ethernet interface on one network segment.
>>
>>>
>>> What I _am_ interested in, and what a security researcher
>> would be
>>> interested in, is that it's a piece of software that's
> enabled
>>> routinely on many VMS systems, even when it's not really
> used,
>> which
>>> makes it a possible attack vector against a VMS system
> (either a
>>> system crasher (more likely) or actual unauthorised access
> (less
>>> likely)) if an implementation flaw could be found.
>>>
>>> Thankfully, in the limited time I decided to allocate to
> this, I was
>>> not to find such an exploit.
>>>
>>> However, the other reason a security researcher would be
>> interested in
>>> DECnet Phase IV would be to find clues about the
>> implementation that
>>> might help them when probing other parts of VMS for
>> vulnerabilities.
>>>
>>> Here, I was more successful. If I were a security researcher,
> I
>> would
>>> now know that some basic checks which I would expect in a
>> network
>>> stack written today simply don't exist in the VMS
>> implementation of
>>> DECnet Phase IV so I would now have motivation to explore the
>> other
>>> VMS network stacks for similar issues.
>>>
>>> I would now know that when information is reproduced within
>> the
>>> different layers within a packet, that different parts of the
> code
>> use
>>> different weightings for which of those fields to trust.
> That's
>> _very_
>>> useful information when you are looking for vulnerabilities.
>>>
>>> I would now know that the code was written in a more trusting
>> era and
>>> that at least some of the assumptions and checks in the code
>> had not
>>> been reviewed as networks became more hostile over the
>> years.
>>>
>>> In summary, no actual exploits found in DECnet Phase IV, but
> a
>> good
>>> set of useful clues to consider when looking at the other
>> network
>>> stacks were found, especially when you consider that the same
>> people
>>> who implemented DECnet Phase IV may have also
>> implemented those other
>>> network stacks and made similar mistakes or omissions.
>>>
>>
>> I suppose DEC/Compaq/HP never envisioned that people would
>> still be using the antique Phase IV on a VMS system many years
>> after they introduced the replacement Phase V. So it may well
> be
>> that the engineers were quite aware of vulnerabilities in Phase
>> IV, but didn't care to fix them. The reasoning being that if
> the
>> customer doesn't want to use the replacement product, then any
>> security problem arising from him using the old stack is his
>> problem. We (DEC/Compaq/HP) are not going to spend time and
>> money in improving an antique network stack.
>>
>
> [snip..]
>
> Regardless of the company logo, my experience (including often
> working closely with CSSE - WW interface for DEC Field Services
> to Engineering) with the culture in OpenVMS engineering was/is
> that security was always a top priority. If the issue was OpenVMS
> related, I highly doubt the statement "the security issue is
> their problem" ever came up.

I get your point, but if it would have meant a complete rewrite of the 
stack, or even changes in the protocol itself, then maybe it was another 
matter.

>
> Re: DECnet Phase IV - Hindsight is always 20-20.
>
> However, it's fair to say that those who developed a new
> networking architecture 35+ years ago (when the design started -
> not when it was released) had no idea of the chaotic world
> networks would evolve into today.
>
> In a similar vein, what will the folks in the year 2050 think of
> our discussions today on our "next gen" protocol - IPV6?
>
> :-)
>
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com