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

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/

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.

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.

"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.
>