Multiple issues found with DECnet Phase IV EVL

[Simon Clubley]

I've discovered multiple issues in DECnet Phase IV EVL. I reported these to
VSI during December, but as none of them appear to offer an immediate direct
compromise, VSI has not done any work on them due to more urgent matters.

However, as VSI have now had these findings for the standard 3 months, it's
time to report them here so you are aware of them and so you can raise any
angles I may have missed. I'm especially interested in your thoughts on
issue 2 as that's so bizarre, I simply don't know what to make of it.

The issues were found on VAX/VMS V7.3 and HPE Alpha V8.4 and reported
against those versions. I have now confirmed the issues still exist in
VSI's version of Alpha VMS. I do not have access to an Itanium system
or a x86-64 VMS system, so cannot test for them on those systems.

1) I can crash EVL on demand by sending it a specially constructed event
message. I _think_ this specific crash is non-exploitable, but I can't be
100% sure. There's also the possibility someone could find a more serious
crash that does allow remote code execution so the EVL code should be
reviewed by VSI.

This is what happened with my DCL research, where my first crash (specially
constructed junk in the recall buffer) was benign, but the second one a few
months later (the DCL buffer overflow CVE) was exploitable.

Here's the crash I get with VSI Alpha VMS:

---------------------------------------------------------------------------
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=FFFFFFFFFFFFFFFC, PC=0000000000038B4C, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
FFFFFFFFFFFFFFFC
0000000000038B4C
000000000000001B

Register dump:
R0 = 0000000000000001 R1 = 0000000000011574 R2 = 0000000000010DE0
R3 = 000000004000E8FB R4 = 000000007AE3EE80 R5 = 0000000000012CAC
R6 = 0000000000011838 R7 = 0000000000000006 R8 = 0000000000000000
R9 = 0000000000000005 R10 = 0000000000064214 R11 = 0000000000000006
R12 = 00000000000641F0 R13 = 000000007AEFD3E0 R14 = 000000007AE3F298
R15 = 0000000002008082 R16 = 0000000000000006 R17 = 00000000000115E0
R18 = 00000000000008FB R19 = 0000000000000004 R20 = 00000000000116C8
R21 = 00000000000117BC R22 = FFFFFFFFFFFFFFFF R23 = 7AE3EF400000000C
R24 = 0000000000000200 R25 = FFFFFFFFFFFFFFFF R26 = 0000000000038AB4
R27 = 0000000000000020 R28 = 0000000000035D74 R29 = 000000007AE3EDA0
SP = 000000007AE3EDA0 PC = 0000000000038B4C PS = 200000000000001B
DECNET job terminated at 2-APR-2022 21:25:47.79
---------------------------------------------------------------------------

Because VSI hasn't looked at this yet, I don't think posting the crasher
itself would be the right thing to do.

2) After I have crashed EVL (this is a prerequisite), I can get it to restart
in a non-privileged account I control (the account password is required)
by issuing a certain command.

In my earlier testing, I was issuing a command on a VAX/VMS node that
caused EVL to restart on my Alpha system in my NOPRIV non-privileged
account (NOPRIV has only the usual NETMBX/TMPMBX privileges), and likewise,
issuing a command on Alpha VMS that caused EVL to restart on VAX/VMS in
my NOPRIV account there.

The idea that a non-privileged user can restart a system component in their
own account is so bizarre, I just don't know what to make of this one. :-)
It's certainly not the kind of thing you could do under TCP/IP for example,
even after you had first caused the component to crash.

The good news is that I could only get it to work against EVL in a basic
out-of-the-box DECnet system. I killed REMACP to simulate a crash, but was
unable to restart it again using this technique.

Conceptually, it's a rather general command, so I don't know if there are
other DECnet systems where this technique will work against other more
security-sensitive DECnet components if the attacker can first cause the
DECnet component to crash.

So everyone, is this just a benign and very odd feature, or could it be
something more serious ?

You can probably work out the command, but once again, I don't want to
post it for now because VSI have not looked at this yet.

There's also some really strange buffering going on that I can't work out.
After I restart EVL in NOPRIV, the event messages are buffered somewhere
until EVL has received exactly 6 of them. This is a reproducible number.

Here is a OPA0: session log on VSI Alpha VMS while I was logged in as
SYSTEM. Note how the first message is only output after the sixth command
and notice how EVL itself is now running in my NOPRIV account:

---------------------------------------------------------------------------
$ mcr ncp set circuit ewa-0 state off
$ mcr ncp set circuit ewa-0 state on
$ mcr ncp set circuit ewa-0 state off
$ mcr ncp set circuit ewa-0 state on
$ mcr ncp set circuit ewa-0 state off
$ mcr ncp set circuit ewa-0 state on
%%%%%%%%%%% OPCOM 2-APR-2022 21:29:42.24 %%%%%%%%%%%
Message from user NOPRIV on AXPA
DECnet event 4.7, circuit down, circuit fault
From node 1.1 (AXPA), 2-APR-2022 21:29:18.55
Circuit EWA-0, Line synchronization lost


%%%%%%%%%%% OPCOM 2-APR-2022 21:29:42.26 %%%%%%%%%%%
Message from user NOPRIV on AXPA
DECnet event 4.10, circuit up
From node 1.1 (AXPA), 2-APR-2022 21:29:23.09
Circuit EWA-0


$
%%%%%%%%%%% OPCOM 2-APR-2022 21:29:42.29 %%%%%%%%%%%
Message from user NOPRIV on AXPA
DECnet event 4.7, circuit down, circuit fault
From node 1.1 (AXPA), 2-APR-2022 21:29:27.30
Circuit EWA-0, Line synchronization lost


$
%%%%%%%%%%% OPCOM 2-APR-2022 21:29:42.30 %%%%%%%%%%%
Message from user NOPRIV on AXPA
DECnet event 4.10, circuit up
From node 1.1 (AXPA), 2-APR-2022 21:29:32.90
Circuit EWA-0


$
%%%%%%%%%%% OPCOM 2-APR-2022 21:29:42.32 %%%%%%%%%%%
Message from user NOPRIV on AXPA
DECnet event 4.7, circuit down, circuit fault
From node 1.1 (AXPA), 2-APR-2022 21:29:36.60
Circuit EWA-0, Line synchronization lost


$
%%%%%%%%%%% OPCOM 2-APR-2022 21:29:42.33 %%%%%%%%%%%
Message from user NOPRIV on AXPA
DECnet event 4.10, circuit up
From node 1.1 (AXPA), 2-APR-2022 21:29:42.23
Circuit EWA-0


$
---------------------------------------------------------------------------

3) EVL appears to be running with _full_ privileges (including CMKRNL!!!)
even though it only requires limited privileges to run.

If confirmed, and given the complex parsing EVL appears to do, this is
a ticking timebomb just waiting to go off. This could be used to turn
a constrained remote code execution vulnerability into one that becomes
a full system compromise vulnerability, all without you having to log
into the system in question.

Can you look at the EVL process on your own systems and see if you can
confirm this ? You can use the INSTALL utility to see what privileges EVL
requires and SHOW PROCESS/PRIV/ID={whatever} to see the actual privileges
it is running with.

You might also want to look at the privileges that the other network
service processes on your systems are running with (especially for the
DEC-specific protocols) just in case there are any more surprises waiting.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.