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

[Simon Clubley]

The reason I've been asking about DECnet Phase IV recently is
because I decided to explore it a little bit from the security
point of view. I didn't expect to find anything major in the
limited time I allocated for this and sure enough I didn't.

However, I did find something unusual which while not an obvious
security issue caused me a little concern because it does raise
questions about the level of checking in the VMS networking code.

What I have discovered is that DECnet blindly trusts what it is
being told about the originating address, even when that information
cannot possibly be valid. For example, when the target node is 1.1,
then the target node trusts (and processes) an incoming packet which
also claims to be 1.1 instead of instantly dropping it.

While this isn't an immediate security issue (which is why I am
comfortable discussing this here), the question it raises is if VMS
networking code, which was written in a more trusting era, has all
the checks in it that one would expect to find in networking code
written in today's more hostile world.

My concern is that the next missing check might be something which
could be exploited to cause a system crash (for example) or maybe
actually compromise system security.

Comments invited.

Here's an example I sent to VSI recently. The target node is 1.1
which is VMS Alpha 8.4. The originating node is 1.2 which is a Linux
box with it's MAC address altered to appear as DECnet node 1.2.

What you are looking at are Endnode hello packets sent from a test
program running on 1.2 which alternatively claims that it's node 1.1
and node 1.2.

Also note that these are supposed to be multicast messages and VMS
blindly processed them even though they were deliberately sent to
the MAC address of 1.1 directly.

I also had another look at this last night and further discovered
that 1.1 ACKed an incoming connect-init from what was claimed to
be 1.1 in the router level s_id field before FAL rejected it due
to missing username and password.

It also ACKed an incoming packet with the s_id field set to a
multicast address (the OPCOM network login failure message showed
it as DECnet node 1.0).

---------------------------------------------------------------------
$ mcr ncp show adj node
 
 
Node Volatile Summary as of  9-NOV-2016 20:16:38
 
%NCP-E-INVRSP, invalid management response
$ 
%%%%%%%%%%%  OPCOM   9-NOV-2016 20:16:43.22  %%%%%%%%%%%
Message from user DECNET on AXPA
DECnet event 4.15, adjacency up
>From node 1.1 (AXPA),  9-NOV-2016 20:16:43.21
Circuit EWA-0, Adjacent node = 1.1 (AXPA)


$ 
%%%%%%%%%%%  OPCOM   9-NOV-2016 20:16:48.03  %%%%%%%%%%%
Message from user DECNET on AXPA
DECnet event 4.15, adjacency up
>From node 1.1 (AXPA),  9-NOV-2016 20:16:48.03
Circuit EWA-0, Adjacent node = 1.2


$ mcr ncp show adj node
 
 
Node Volatile Summary as of  9-NOV-2016 20:16:56
 
    Node           State      Active  Delay   Circuit     Next node
                              Links
 
 1.1                                          EWA-0          0
 1.2                                          EWA-0          0
$ 
%%%%%%%%%%%  OPCOM   9-NOV-2016 20:17:28.05  %%%%%%%%%%%
Message from user DECNET on AXPA
DECnet event 4.18, adjacency down
>From node 1.1 (AXPA),  9-NOV-2016 20:17:28.04
Circuit EWA-0, Adjacent node listener receive timeout
Adjacent node = 1.1 (AXPA)


$ 
%%%%%%%%%%%  OPCOM   9-NOV-2016 20:17:33.05  %%%%%%%%%%%
Message from user DECNET on AXPA
DECnet event 4.18, adjacency down
>From node 1.1 (AXPA),  9-NOV-2016 20:17:33.05
Circuit EWA-0, Adjacent node listener receive timeout
Adjacent node = 1.2


$ mcr ncp show adj node
 
 
Node Volatile Summary as of  9-NOV-2016 20:17:35
 
%NCP-E-INVRSP, invalid management response
---------------------------------------------------------------------

The following Ethernet frames are what caused the above behaviour:

---------------------------------------------------------------------
[root@[deleted] vms]# ./endnode_hello 
Interface index = 2
0000: aa 00 04 00 01 04 aa 00 04 00 02 04 60 03 22 00 ............`.".
0010: 0d 02 00 00 aa 00 04 00 01 04 03 da 05 00 00 00 ................
0020: 00 00 00 00 00 00 aa 00 04 00 00 00 0f 00 00 02 ................
0030: aa aa 00 00 00 00 00 00 00 00 00 00             ............    
[root@[deleted] vms]# make
gcc -Wall -o endnode_hello endnode_hello.c
[root@[deleted] vms]# ./endnode_hello 
Interface index = 2
0000: aa 00 04 00 01 04 aa 00 04 00 02 04 60 03 22 00 ............`.".
0010: 0d 02 00 00 aa 00 04 00 02 04 03 da 05 00 00 00 ................
0020: 00 00 00 00 00 00 aa 00 04 00 00 00 0f 00 00 02 ................
0030: aa aa 00 00 00 00 00 00 00 00 00 00             ............    
---------------------------------------------------------------------

(It was run as root so I could access the packet interface on Linux).

Simon.

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