[VMS] SMGRTL Issue - VMS

This is a discussion on [VMS] SMGRTL Issue - VMS ; May I again ask some questions about the recent events and my answers after browsing (but *not* reading all of) the thread here (and some kind soul of you you correct me where I'm wrong or adds an answer where ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: [VMS] SMGRTL Issue

  1. [VMS] SMGRTL Issue

    May I again ask some questions about the recent events and my answers
    after browsing (but *not* reading all of) the thread here (and some
    kind soul of you you correct me where I'm wrong or adds an answer
    where I've none):

    Q1) Has VMS again been (allowed/invented) at an DEFCON event?
    A1) text goes here (Yes, at DEFCON16, 8-AUG-2008 til 10-AUG-2008 in Las Vegas)

    Q2) Which arguments which 'disallowed' VMS at earlier DEFCON has changed now?
    A2) text goes here

    Q3) Were a VMS security flaw found/demonstrated at DEFCON16?
    A3) Yes, a missing range check in SMG RTL (SMGSHR.EXE) which corrupts stack
    and allows one to specify an address where code continues after cmd input.

    Q4) What is the CVE of this SMG flaw?
    A4) text goes here

    Q5) Was this security flaw of VMS used to take over a VMS system at DEFCON?
    A6) No (though it could have been done via this flaw).

    Q6) How can this flaw be used to take over an VMS system?
    A6) By running (as an unprivileged user) a program installed with privileges
    (like INSTALL.EXE) which links to the SMGSHR.EXE and being able to jump
    to one's own program (loaded into memory) which is then run with privileges.

    Q7) Why is an unprivileged user able to run a program installed with privs?
    A7) Because this is design - to let unprivileged users do privileged things
    (like login, changing the password and much much more) without compromising
    the whole system. That is why it is important to have only trusted images
    installed (with privs).

    Q8) Why is an unpriv user able to run INSTALL.EXE? Why does one need to?
    A8) There is no need for an unprivileged user to run INSTALL.EXE
    One is able to run it, because VMS is after 25 years still delivered
    (fresh installed) with protection WORLD:RE as default and obviously no
    system manager secured this file after VMS installation then.

    Q9) Why is INSTALL.EXE installed with privileges (it is only for priv Users)?
    A9) text goes here

    Q10) Doesn't a installed privileged image like the INSTALL.EXE require the
    linked shareable images like the SMGSHR.EXE not also be installed?
    A10) Yes it does, and it is (SMGSHR.EXE is installed /OPEN/HEADER/SHARE/NOPRIV)

    Q11) Is INSTALL.EXE the only image which could use the SMGSHR.EXE flaw?
    A11) No, many - accessible for unprivileged users - images, which are
    installed with privileges, and are linked to this buggy SMGSHR.EXE
    could be used to take over the system. Eg. SYSMAN.EXE
    It depends on whether the privileged image requires command input via
    the SMG routines linked in.

    Q12) How many versions of OpenVMS are affected by this SMG RTL bug?
    A12) Text goes here (versions of decades ago are already affected,
    might even be a day one exploit)

    Q13) How do I secure my VMS system?
    A13) Most of all, install the (Install 1 - still not MUP - grade) SMGRTL ECO
    for the platform/os-version you use. But if you are on VAX or on a way too
    old version of VMS, please contact HP (as there are no released ECOs so far)

    Second, set the protections of images not to be run by the public to no
    WORLD access. Consider also ACLs for these files if only a few nonpriv
    users require them.

    Q14) Is the SMG RTL flaw the only VMS flaw recently found/demonstrated?
    A14) No, eg. a bug in the finger client of HP VMS own TCPIP stack
    (TCPIP$FINGER.EXE) was found. But as finger is a service rarely enabled
    on VMS systems, the finger flaw is far less important than the SMG RTL flaw
    (which affects every - unpatched - VMS system).

    Q15) Was the TCPIP finger client flaw found/demonstrated at DEFCON16, too?
    A15) text goes here


    TIA

    --
    Peter "EPLAN" LANGSTÖGER
    Network and OpenVMS system specialist
    E-mail Peter@LANGSTOeGER.at
    A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist

  2. Re: [VMS] SMGRTL Issue


    Hi Peter,

    My answers here are also largely based on what I read here in c.o.v.
    Corrections are welcome, of course.

    On Tue, 26 Aug 2008, Peter 'EPLAN' LANGSTOeGER wrote:

    > Q1) Has VMS again been (allowed/invented) at an DEFCON event?
    > A1) text goes here (Yes, at DEFCON16, 8-AUG-2008 til 10-AUG-2008 in
    > Las Vegas)


    I think the answer here is "no." I have not heard that there was a
    VMS system in the "hacker's playground" (or whatever it is called) at
    DEFCON 16. There *was* a presentation about the VMS vulnerabilities
    at one of the sessions. This presentation had been on the schedule
    for months. I think this is different from "VMS being at
    DEFCON". My 2 cents.

    > Q2) Which arguments which 'disallowed' VMS at earlier DEFCON has
    > changed now?
    > A2) text goes here


    I think the "disallowed" thing referred to having a VMS system in the
    playground. That does not appear to have changed.

    > Q3) Were a VMS security flaw found/demonstrated at DEFCON16?
    > A3) Yes, a missing range check in SMG RTL (SMGSHR.EXE) which
    > corrupts stack and allows one to specify an address where code
    > continues after cmd input.


    Found? No. The flaw was found months ago. This presentation about
    the VMS security flaw had been scheduled for months.

    Demonstrated? Depends on what you mean by "demonstrated". There was
    a presentation with videos but no live demonstration, since there was
    no VMS system at the event.

    > Q5) Was this security flaw of VMS used to take over a VMS system at
    > DEFCON?
    > A6) No (though it could have been done via this flaw).


    There was no VMS system at DEFCON.

    > Q8) Why is an unpriv user able to run INSTALL.EXE? Why does one need
    > to?
    > A8) There is no need for an unprivileged user to run INSTALL.EXE One
    > is able to run it, because VMS is after 25 years still delivered
    > (fresh installed) with protection WORLD:RE as default and obviously
    > no system manager secured this file after VMS installation then.


    As a developer I used INSTALL LIST from time to time to see if
    sections of interest were installed. I'm not sure whether or not I
    could make a case for checking without having the privilege to "fix if
    necessary".

    > Q15) Was the TCPIP finger client flaw found/demonstrated at
    > DEFCON16, too?
    > A15) text goes here


    Same as my answer to question 3, above.


    --

    Rob Brown b r o w n a t g m c l d o t c o m
    G. Michaels Consulting Ltd. (780)438-9343 (voice)
    Edmonton (780)437-3367 (FAX)
    http://gmcl.com/


  3. Re: [VMS] SMGRTL Issue

    Peter 'EPLAN' LANGSTOeGER wrote:
    > Q1) Has VMS again been (allowed/invented) at an DEFCON event?


    A presentation on hacking OpenVMS was included as part of the conference
    content. OpenVMS was not involved in the Capture-The-Flag game.

    > Q2) Which arguments which 'disallowed' VMS at earlier DEFCON has changed now?


    None.

    The Capture-The-Flag (CTF) game rules were changed after DEFCON 9 so
    that all participants are required to run the same (supplied)
    distribution of Linux. I'm pretty sure the intent was to "level the
    playing field" among the participants rather than specifically to
    exclude OpenVMS. But some took it as "being asked not to return."

    (Some of us thought about running OpenVMS under simh on top of this
    supplied distro, with as much as possible disabled down at the Linux level.)

    > Q3) Were a VMS security flaw found/demonstrated at DEFCON16?


    Yes, a flaw in the Finger client and a buffer overflow vulnerability
    (which turned out to be in SMG) were discussed and an exploit demonstrated.

    > Q4) What is the CVE of this SMG flaw?


    After a quick Google search, I assume you mean Common Vulnerabilities
    and Exposures, http://cve.mitre.org/

    I can't answer this one.

    > Q5) Was this security flaw of VMS used to take over a VMS system at DEFCON?


    I wasn't there, but I understand it was demonstrated.

    > A13) Most of all, install the (Install 1 - still not MUP - grade) SMGRTL ECO


    I got an e-mail which indicates these may be in the process of being
    re-released as MUPs.

  4. Re: [VMS] SMGRTL Issue

    In article <48b4142f$1@news.langstoeger.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) writes:
    > May I again ask some questions about the recent events and my answers
    > after browsing (but *not* reading all of) the thread here (and some
    > kind soul of you you correct me where I'm wrong or adds an answer
    > where I've none):
    >
    > Q1) Has VMS again been (allowed/invented) at an DEFCON event?


    No. A talk about VMS was given, and snapshots of screen images,
    but no one claims VMS itself was there. On the other hand, probably
    no one allowed their laptops to be scanned for SIMH copies.

    > Q2) Which arguments which 'disallowed' VMS at earlier DEFCON has changed now?


    DEFCON limited the OS which could be brought, under the excuse that
    only those allowed were of interest.

    > Q15) Was the TCPIP finger client flaw found/demonstrated at DEFCON16, too?


    Yes.


  5. Re: [VMS] SMGRTL Issue

    "Keith Parris" wrote in message
    news:g919sn$cq3$1@usenet01.boi.hp.com...
    > Peter 'EPLAN' LANGSTOeGER wrote:
    >> Q1) Has VMS again been (allowed/invented) at an DEFCON event?

    >
    > A presentation on hacking OpenVMS was included as part of the conference
    > content. OpenVMS was not involved in the Capture-The-Flag game.
    >
    >> Q2) Which arguments which 'disallowed' VMS at earlier DEFCON has changed
    >> now?

    >
    > None.
    >
    > The Capture-The-Flag (CTF) game rules were changed after DEFCON 9 so that
    > all participants are required to run the same (supplied) distribution of
    > Linux. I'm pretty sure the intent was to "level the playing field" among
    > the participants rather than specifically to exclude OpenVMS. But some
    > took it as "being asked not to return."
    >
    > (Some of us thought about running OpenVMS under simh on top of this
    > supplied distro, with as much as possible disabled down at the Linux
    > level.)
    >


    More specifically - the OS has to run on an X86 or X64 processor and have a
    port of a specific monitoring program. This allows Linux, Windows, and, I
    believe, Mac OS-X running on X86 and X64 hardware.

    Mike Ober.


    >> Q3) Were a VMS security flaw found/demonstrated at DEFCON16?

    >
    > Yes, a flaw in the Finger client and a buffer overflow vulnerability
    > (which turned out to be in SMG) were discussed and an exploit
    > demonstrated.
    >
    >> Q4) What is the CVE of this SMG flaw?

    >
    > After a quick Google search, I assume you mean Common Vulnerabilities and
    > Exposures, http://cve.mitre.org/
    >
    > I can't answer this one.
    >
    >> Q5) Was this security flaw of VMS used to take over a VMS system at
    >> DEFCON?

    >
    > I wasn't there, but I understand it was demonstrated.
    >
    >> A13) Most of all, install the (Install 1 - still not MUP - grade) SMGRTL
    >> ECO

    >
    > I got an e-mail which indicates these may be in the process of being
    > re-released as MUPs.
    >





+ Reply to Thread