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