Security flaw ?

[DICTU OpenVMS]

Today I was playing around with display settings when we discovered a security flaw.
I have 2 different users logged in on the VMS system and both have a display setting, created with "$ set display /create /node= /trans=tcpip". As we all know, the display device is defined in the logical decw$display in the proces table. If user1 re-defines his logical to the display device of user2, user1 can display his (possible fake)application on the screen of user2. No privs required !

If user1 had set his display to the pc name of user2, well ok... But in this case, user1 'borrows' the WSA device of user2. Or can this be corrected with protection on the WSA device ?

[Joseph Huber_1]

No, the security flaw is not the fact of using
the same WSA unit (one can do another
set display/create, and it will use a different WSA unit).
The problem is the security setting on the X11 server side
(i.e. the PC /excursion side):
if it allows acces from both user1 and user2 from the same or different nodes, then it doesn't matter what WSA units the client (VMS-) side uses.

I don't have experience with excursion, does it have the possibility to enter explicit user/node pairs in the security setup ?
Unfortunately the DECWindows/tcpip implementation prior to VMS 7.3-2 do not have support for xauth and kerberos authentication for X11, and VMS-TCPIP services (other than Multinet/tcpware) do not have an X11-forwarding SSH implementation, so one has to live with the simple node allowance.
In addition: doesn't have excursion also LAT and/or DECnet support ? With that a user/node
setting should be possible.

[Martin Kirby_1]

As Joseph says, the problem is the settings in eXcursion. You can use the DECnet transport and user/transport/node triplets to enable access.

On my, old, version of eXcursion it is the Access tab on the control panel. Select to enable access control and add the user to valid nodes. The "Controlling Hosts" section is for those who users who can run clients that change access control settings in the server.

However, I know there are some issues with the login sequence if you are running a DECwindows login box. I also am not sure how it interacts if you are using XDMCP.

Martin Kirby

[Jan van den Ende]

Menco,

there is another side to this as well:
there can be various reasons to want to display (part of) the output on another screen ( = station or peecee ) than the one carrying the user interface.

I HAVE been in contact with applications for which a 3-screen display was very usefull.
Those were LAT days, and, IIRC, the secondary displays had to be explicitly allowed, but it worked great!

Proost.

Have one on me.

Jan

[Lawrence Czlapinski]

Menco, we use $create/term/detach for our excursion connections to the VMS nodes from our PCs. Why would they need to do a /node to their own PC's? This gives us FTAxx device names. The transport is TCPIP. We can have as many windows on our PCs as the PC can handle.
Lawrence

[Lawrence Czlapinski]

Menco, if an application needs to use a PC, we use LAT connections.
Lawrence

[DICTU OpenVMS]

Joseph, Martin,

The acces tab in eXcusrion would be an option if it were different node's. But in this case both users are on the same VMS node, so eXcursion won't know the difference between the users. And acces for a user is only possible on DECnet...

And Jan, in case of a 3 screen app it would be handy, but I would expect to have given explicit access in that case.

(Jan : And I will take my Triple tonight ;) )

[Kris Clippeleyr]

Hi Menco,

I tend to disagree with my learned colleagues.


No, the security flaw is not the fact of using
the same WSA unit (one can do another
set display/create, and it will use a different WSA unit).
The problem is the security setting on the X11 server side
(i.e. the PC /excursion side):
if it allows acces from both user1 and user2 from the same or different nodes, then it doesn't matter what WSA units the client (VMS-) side uses.


I did the experiment myself with a slight modification. First I did a "SET DISPLAY/CREATE/NODE=mypeecee/TRANSP=TCPIP" from an interactive session on our rx2600, hereby obtaining the WSA27 device. From another session, from a non-privileged account (only TMPMBX & NETMBX), I simply defined my DECW$DISPLAY thus
$ DEFINE DECW$DISPLAY "_WSA27:"
I did NOT do a SET DISPLAY.
I was then able to start e.g. the DECW$CLOCK program and the output went to the screen of the peecee.
This means that I am "stealing" a device from my fellow co-worker, and could prevent him from doing serious work by cluttering his/her display.
Apparently, VMS doesn't care.
IMHO, this is not the way it supposed to be. If I am using a device on VMS, and I want to share it with other users on the VMS box, I would like to have to allow that explicitly.
But then again, it may all well be philosophical.

Just my 2 cents,
Kris (aka Qkcl)

[DICTU OpenVMS]

Hi Kris.

Exact my point. So to us this is a secutiry flaw... ;-)

[Jan van den Ende]

Menco,


but I would expect to have given explicit access in that case.


Yes, and I DID write that that, as far as I remember, was the case (at least, then).

(OT. on Tripel: to me, that was yesterday. Tonight I 'll be playing bridge at a location where they don't serve Tripel, but they can consolate me quite well with Koninck)

Kris,
yes, I would expect that as well!
_NO_ device sharing unless explicitly shared!

I guess that herewith Menco's original statement now stands on firmer ground.

Anyone with Engeneering credentials care to comment?

Proost.

Have one on me.

jpe

[Martin Kirby_1]

I can also do:

$ DEFINE DECW$DISPLAY "tcpip/hispcee:0.0"
$ RUN MY_PASSWORD_STEALER

You don't need a WSA device.

The security flaw is in the PC which has allowed access for clients without authentication and not on the client/OpenVMS side.

----

In olden times, the OpenVMS server was more secure than many other X-11 servers because it added validation by user for DECNET, LOCAL and LAT. Then it wasn't so hot because it didn't support magic cookie. Now (Alpha and I64) it is more or less level pegging with Cookie and Kerberos support.

However, that is the OpenVMS server and irrelevant to the eXcursion server.

----

There is a potential security flaw with the WS devices but it is the other way around.

You can use SET DISPLAY to modify my display device so I connect to your server. Chances are I'll notice that (since windows don't appear on my display).

However, you could implement a forwarding proxy and watch everything go by. Kerberos authentication prevents that, DECNET or LAT would need some low-level network hacking, TCPIP and cookie would be easiest to break.

Martin Kirby

[Martin Kirby_1 · Accepted solution]

It looks like protecting the WSA device by using SET SECURITY/CLASS=DEVICE can prevent use, or modification, of the device by other users.

Changing the default protection on newly created devices risks compatibility issues. I guess there is room for an enhancement to allow specifying the protections on the SET DISPLAY/CREATE command.

You can see protections in use:

$ defi decw$display wsa324
$ sh sec wsa324 /class=dev

_WSA324: object of class DEVICE
Owner: [Q348070,DEFAULT]
Protection: (System, Owner: RWPL, Group, World)
Access Control List:
TEST7 $ mcr decw$clock
Interrupt

TEST7 $ stop
TEST7 $ set proc/priv=(noall,tmpmbx,netmbx)
TEST7 $ mcr decw$clock
X Toolkit Error: Can't Open display
%DWT-F-NOMSG, Message number 03AB8204
TEST7 $ sh disp wsa324

%DECW-F-UNEXPMODE, unexpected mode value in workstation device
TEST7 $ set disp wsa324 /screen=1
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
TEST7 $

The UNEXPMODE error from SHOW DISPLAY would need fixing.

Martin

[Joseph Huber_1]

Yes, I concede, the fact that WSA devices have
security defaulting to g and w:RWLP is a security flaw !
By the way, WSA devices created by the session manager on VMS
are executive mode display, and they can't be changed only by users with SYSNAM privilege.

[Lawrence Czlapinski]

Menco, I also agree that WSA devices having
security defaulting to g and w:RWLP is a security flaw ! Since the devices are W:RW, anyone at the DCL level can do a SHOW DEVICE WSA/FULL and see all the active WSA devices.
Lawrence