On 2024-01-13, Mark Berryman <mark@theberrymans.com> wrote:
> On 1/11/24 6:45 AM, Simon Clubley wrote:
>>
>> For example, in 2) above, how does this address clients on an authorised
>> VLAN being able to send malformed packets to a server with an inappropriately
>> fully-privileged EVL listener that has a dodgy message parser built into it ?
>

[snip]

>
> Also, you are out of date. EVL is not fully privileged. It only has
> SYSNAM, OPER, and SYSPRV privileges and its listener only runs in
> unprivileged user mode.

_If_ that is true, and _IF_ VSI has silently fixed that in DECnet Phase IV
without even bothering to tell me, I am going to be seriously annoyed.
See [*] below.

However, before we get to that, we need to make sure you are seeing what you
think you are seeing before people start saying negative things about VSI.

How have you determined the privileges in use ? Did you look at the installed
privileges or did you run a "$ show proc/priv/id=evl_listener_pid" command ?

Can you post the output from the above command for EVL on your system,
along with architecture and VMS version ? Have you installed any DECnet
patches ?

If anyone else is reading, could you post your output from the command ?
When I filed this report with VSI a couple of years ago, it clearly showed
the EVL listener was running with all privileges on Alpha, even though it
was only installed with a limited set of privileges.

>
>> PS: I wonder if, 2 years on, whether VSI has got around to fixing those
>> issues in DECnet Phase IV yet ?
>
> Beyond your previously mentioned ability to crash EVL, what issues would
> those be (I'm genuinely curious)?
>

The other major one was the ability to restart EVL, once it had crashed
(this is a prerequisite), in an account I controlled and to do it from
across the network.

There is absolutely no way I should have been able to do that. Fortunately,
experiments with REMACP after a simulated failure were unsuccessful
(thankfully!!!), but as I mentioned at the time, I don't know if you can do
that to other DECnet components if you can first get the running service
to crash.

The original public writeup is here:

https://groups.google.com/g/comp.os.vms/c/Bjp0hRkSnh4

[*] If VSI has silently fixed this, it goes against current security
reporting conventions. I am an advocate of "coordinated disclosure",
also known as "responsible disclosure". A reasonable writeup of the
issues involved is here:

https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure

It involves researchers privately reporting either an actual vulnerability
(as in the DCL one), or potential security issues (as in the list of
DECnet issues I found above) and giving the vendor time to fix them
before disclosing them.

In any case, if the vendor considers them important enough to fix, it
is the expected standard that the vendor notifies the researcher they
have been fixed and when. It is considered very bad form to try to
silently fix even a potential issue without telling the researcher who
originally reported it.

_IF_ VSI have silently fixed this, then did they fix the other issues,
such as the crash itself, or did they just remove the extra privileges
and call it a day ? Did they also fix it on the other architectures
they support ?

Simon.

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