1. Forum
  2. Usenet
  3. COMP.OS.VMS

  • Have VSI been silently fixing potential security issues ?

    From Simon Clubley@21:1/5 to Mark Berryman on Mon Jan 15 14:13:53 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)