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

[Dirk Munk]

Simon Clubley wrote:
> 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.
>

My question is, why are you interested in this very old protocol? DECnet 
Phase V was designed for let's say an OSI Internet, so I'm sure it's 
beter designed in this respect. Before some one else tries to point it 
out, yes I know it doesn't have encryption when used with the OSI 
transport layers. It could have been done, and it still can be done 
using TLS, that has been designed for the OSI transport layer. I'm sure 
VSI will look into this :-)