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

[Johnny Billquist]

On 2016-11-25 14:42, 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.
>
> 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.
>
> (One of the things you are supposed to do when a vulnerability is
> reported is to review similar code written by the person or persons
> who wrote the vulnerable code and see if the same mistakes were
> made there as well.)

While you have some half points in here, I feel that this is making more 
out of it than is meaningful.

I can just as easily also pollute the ARP table of any IPv4 host. There 
is no checking of the authenticity of an ARP packet, and if can cause 
traffic to suddenly be redirected elsewhere for all IPv4 traffic you are 
sending out.

I can also easily pollute the routing table of many IPv4 hosts by 
sending bogus RIP packets. There is no authenticity there either. The 
data is just processed, and acted upon.

I fail to see that DECnet have any more problems than IP here. The big 
issue is cleartext usernames and passwords. Something IP protocols also 
have, but in IP those protocols are now considered security problems.

What you have found is that the routing table in DECnet can be 
subverted. I'd consider that very much to be the same kind of problem as 
ARP and RIP in IP.

	Johnny