IA64 problem with Shareable Image protection

[Richard J Maher]

Hi,

Can anyone point to either: -
1) A release Note
2) Something in a "porting guide"
3) Something in the standard docs
4) A secttion from your favourite "Shareable Image Cookbook"

That explains why *on Itanium systems only* VMS requires Read as well as Execute access to a shareable image in order to be able to just execute it?

That's right, I don't want to Link against it, LIB$FIS it, only to [E]xecute it. Just like VAX and Alpha where you only need (W:E) access.

I specifically don't want unprivileged users to be able to link/lib$fis against my RTL (Just like many standard VMS layered products on VAX and Alpha).

I haven't been able to find anyone to acknowledge or own up to this change or its motivation; any ideas?

A reasonable important VMS security regime change don't you think?

Cheers Richard Maher

[Hein van den Heuvel]

>> I haven't been able to find anyone to acknowledge or own up to this change or its motivation; any ideas?

The motivation is easy... LIB$FIS actually reads the ELF image with RMS $GET calls, before calling the image activation itself.

When you read a file, you need to have read access.

As to documentation, what next, whether it could have been done better, and other silly questions... I don't know and don't care!

Reference:
Facility: LIBRTL
Module: LIBFNDIMG
Function: lib$$read_object

Cheers,
Hein.

[Richard J Maher]

Hein,

I must not be making myself clear :-(

I understand lib$fis needs [R]ead access to and shareable image - fine!

I understand the Linker needs [R]ead access to the shareable image - fine!

Why does the image activator need [R] access to the shareable image when it didn't on Alpha or VAX?

Are you (or anyone) not concerned that what was previously explicitly forbidden by having a shareable image set to (W:E) instead of the now (W:RE) is now a barn-door wide open?

VMS/IA64 now *requires* us to adopt a security policy at odds to Alpha and VAX and you're saying "in hindsight it might have been worth a footnote or two"?

Anyone can now LIB$FIS or LINK to RDB$COSIP.EXE and get a free UAF reading password hacker; "Not bovvered"?

Cheers Richard Maher

[x2084]

This problem was reported for V8.3 and there was a fix. Any ECO with an image_management.exe generated after Dec-2006 should have the fix. The fix is included in 8.3-1H1. If this still shows in such versions, please contact HP.

[Volker Halle]

Richard,

the problem description from VMS83I_SYS-V0200 looks like this:

5.2.14 Image Activation Failure

5.2.14.1 Problem Description:

If an executable or shareable image is installed, and the user only has execute access to the image file, activating the image fails with a the following error message:

-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

Images Affected:

- [SYS$LDR]IMAGE_MANAGEMENT.EXE
- [SYS$LDR]IMAGE_MANAGEMENT.STB

5.2.14.2 CLDs, and QARs reporting this problem:

5.2.14.2.1 CLD(s)

QXCM1000377545

5.2.14.3 Problem Analysis:

For installed images, the image activator maps the file based global sections created by INSTALL. By default, mapping the global section requires read access, which is compared with the protections set for the file. With only execute access granted, the check fails with the NOPRIV error.


This fix is also included in VMS821I_SYS-V0400.

Volker.

[Richard J Maher]

Volker, Hartmut,

Thanks for the replies!

Certainly sounds like my problem doesn't it, but why am I still getting it?

Can anyone (including the patch testers) show a working example on 8.3-1H1?

Does anyone have the accompanying release note?

Why did Rdb Engineering just stick their tail between their legs and change RDB$COSIP.EXE to (W:RE)?

Cheers Richard Maher

[x2084]

It looks like the fix is incomplete. Can you show the output of INSTALL LIST for RDB$COSIP.EXE? Does it say Shared or SharAddr? Can you test with installing it /share=addr?
Sorry to insist, but it's time to send a problem report.

[John Gillings]

Richard,

Interesting! I agree this would be a very important change (and one that I'd strongly argue against).

It seems to be working correctly for me on OpenVMS V8.3-1H1 on a trivially simple test case. I created a shareable image with a "Hello World" routine, linked a program against it, then set it to (E,E,,) protection. The first program can still activate the image, but TYPE and LINK and LIB$FIS all fail:

$ ty tshr.exe
%TYPE-W-OPENIN, error opening DSA1:[GILLINGS]TSHR.EXE;1 as input
-RMS-E-PRV, insufficient privilege or file protection violation
$ link main1+sys$input/opt
tshr/share
%ILINK-F-OPENIN, error opening DSA1:[GILLINGS]TSHR.EXE;1 as input
-RMS-E-PRV, insufficient privilege or file protection violation
$ run fis
%LIB-E-ACTIMAGE, error activating image DSA1:[GILLINGS]TSHR.EXE;1
-SYSTEM-W-ACCONFLICT, file access conflict
%TRACE-E-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
LIBRTL LIB$FIND_IMAGE LIB$FIND_IMAGE_SYMBOL
1812 0000000000002800 FFFFFFFF841BC750
FIS 0 0000000000020092 0000000000020092
0 FFFFFFFF80C48192 FFFFFFFF80C48192
DCL 0 000000000006BD22 000000007ADB7D22
%TRACE-I-END, end of TRACE stack dump
%SYSTEM-W-ACCONFLICT, file access conflict

$ run main
Hello World

We have applied HP I64VMS VMS831H1I_SYS V3.0

Maybe your case is more complex?

[Richard J Maher]

Hi Hartmut, John

Thanks for the replies!

RDB$COSIP.EXE is a red herring. I just set it to W:E and was still able to SQL$ and to specify username/pass in the database attach spec. Why they deliberately set it to W:RE on Itanium only they know but I submit it should be W:E only. (I guess they just had to do it to get Itanium out the door?)

Mine is less of a security risk as "correctness" so I'm looking at W:RE on t3$private too, but I will try for a small reproducer . A common and protected PSECT is shared between the two which could be the first port of call.

Cheers Richard Maher

[Richard J Maher]

Might have spoke to soon; I had SYSPRV on: -

$ set proc/priv=(noall,tmpmbx,netmbx)
$ mc sql$
SQL> attach 'file mf_personnel user ''tier3_dev'' using ''xxx''';
%SQL-F-ERRATTDEC, Error attaching to database mf_personnel
-RDB-E-UNAVAILABLE, Rdb/Dispatch is not available on your system
-RDB-I-TEXT, %LIB-E-ACTIMAGE, error activating image RX2600$DKA100:[SYS0.SYSCOMMON.][SYSLIB]RDB$COSIP.EXE, -SYSTEM-F-NOPRIV, insuffi
cient privilege or object protection violation

$dir/full sys$library:rdb$cosip.exe

Directory SYS$COMMON:[SYSLIB]

RDB$COSIP.EXE;1 File ID: (19375,1,0)
Size: 32/32 Owner: [SYSTEM]
Created: 20-NOV-2008 14:21:49.09
Revised: 12-FEB-2009 05:27:09.71 (4)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 32, Extend: 0, Global buffer count: 0, No version limit, Contiguous best try
Record format: Fixed length 512 byte records
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RWED, World:E
Access Cntrl List: None
Client attributes: None

Total of 1 file, 32/32 blocks.
$

A "reproducer" or for some reason would they use lib$fis?

Cheers Richard Maher