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

[Richard J Maher]

Here's one I prepared earlier :-)

See attached for DIR_WATCH.COM if you (at) that file and then $RUN TEST_DIR from an unprivileged account you'll see what I mean: -

$ dir/full SYS$COMMON:[SYSLIB]DIR_WATCH_EXEC.EXE;1

Directory SYS$COMMON:[SYSLIB]

DIR_WATCH_EXEC.EXE;1 File ID: (2255,11,0)
Size: 51/64 Owner: [SYSTEM]
Created: 12-FEB-2009 06:57:37.77
Revised: 12-FEB-2009 06:57:37.98 (3)

File organization: Sequential
File protection: System:RWED, Owner:RWED, Group:RE, World:E
Access Cntrl List: None
Client attributes: None

Total of 1 file, 51/64 blocks.
$ set proc/priv=(noall,tmpmbx,netmbx)
$ run test_dir
%DCL-W-ACTIMAGE, error activating image DIR_WATCH_EXEC
-CLI-E-IMGNAME, image file RX2600$DKA100:[SYS0.SYSCOMMON.][SYSLIB]DIR_WATCH_EXEC.EXE
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

Cheers Richard Maher

*NB* Be advised that some of the attached go operates in Kernel mode. Use at own risk! No warranty express of implied.

[Richard J Maher]

Here's some documentation for the routines in the previous example, if it helps any.

Cheers Richard Maher

[John Gillings]

Richard,

Sorry, I can't run your test - policy regarding privileged programs (if it were an Alpha question I could run it on my home Alpha, but I don't have an IA64 to play with).

The issue may have something to do with the /PROTECT on the installed image, or maybe it's because of the two levels? As a sanity check, could you please try the attached procedure to see if my trivial example works correctly? No kernel mode code, no privilege required. Worst it will do is leave a few files and some logical names defined.

[Richard J Maher]

Here 'tis,

$ @john
This should output "Hello World"
Hello World
This should output "Hello World" again
Hello World
This should fail with %TYPE-W-OPENIN
%TYPE-W-OPENIN, error opening DKA0:[TIER3_DEV.GILLINGS]TSHR.EXE;1 as input
-RMS-E-PRV, insufficient privilege or file protection violation
This should fail with %ILINK-F-OPENIN
%ILINK-F-OPENIN, error opening DKA0:[TIER3_DEV.GILLINGS]TSHR.EXE;1 as input
-RMS-E-PRV, insufficient privilege or file protection violation
This should fail with %LIB-E-ACTIMAGE
%LIB-E-ACTIMAGE, error activating image DKA0:[TIER3_DEV.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
TFIS 0 0000000000020092 0000000000020092
0 FFFFFFFF80B9E492 FFFFFFFF80B9E492
DCL 0 000000000006BD22 000000007AE27D22
%TRACE-I-END, end of TRACE stack dump
%SYSTEM-W-ACCONFLICT, file access conflict

[x2084]

The ECO talks about installed images. It talks about mapping global sections. If installed /share, it gives the error, if installed /share=addr it works. The fix is incomplete, it addresses only /share=addr, which the error report was for. Please report the problem to get the fix.

[Richard J Maher]

Hi Hartmut,

You're an absolute champion! Should have given your post 10 points.

> if installed /share=addr it works.

Sure does! Can't think of hand why you wouldn't use share=ADDRESS as opposed to vanilla /SHARE but is sounds better than setting protection down to w:Re so I'm off to investigate.

> Please report the problem to get the fix.

Not in a position to do that at the mo, and if Rdb Engineering can't be bothered then it can't be too important :-(

But maybe you can find the guy at VMS responsible who considers regression-testing a clean-compile and Linker-errors a manufacturing issue and get him/her to be a bit more pro-active?

Thanks again.

Cheers Richard Maher

[x2084 · Accepted solution]

OK, I'll try to find that guy who only made minimal (security related) changes when he took over the image activator (which some people name a complex environment). If nobody wants this fixed in an ECO, it will go into the next
major release.

[Richard J Maher]

Hi Hartmut,

Thanks again for your help with this!

Yes, I want it fixed in an ECO, justice *demands* it is fixed in an ECO!

Don't you dare sit there as an appologist for the incompetent that made the original change and ask me to jump through hoops :-(

But as I summed it up recently in a note to the Rdb Listserver: -

----- Original Message -----
From: Richard's Hotmail
To: oraclerdb@jcc.com
Sent: Friday, February 13, 2009 10:40 AM
Subject: Re: IA64 and protection on RDB$COSIP.EXE

In closing: -

- /SHARE=ADDRESS_DATA is starting to look like the mutt's nuts to me (although I too could have lowered the power to the sheilds and set protection to W:RE with far less security implecations in my case.)

- No one here seems too worried that anyone can now LINK or LIB$FIS to RDB$COSIP and chance their arm at some passwords. (I'd take Port Number out of the intrusion detection just in case too)

- I don't have a support agreement nor the rapport you share between VMS and Rdb engineering

As an annoying developer who used to sit across from me had a habit of solutionizing "Someone oughta do something!" :-)

Cheers Richard Maher

----- Original Message -----
From: Norman Lastovica
To: oraclerdb@jcc.com
Sent: Friday, February 13, 2009 9:15 AM
Subject: RE: IA64 and protection on RDB$COSIP.EXE

If there is a problem on VMS, Please do get in touch with HP OpenVMS support directly and they should be able to help you.

From: Richard's Hotmail Sent: Thursday, February 12, 2009 6:48 PM
To: oraclerdb@jcc.com
Subject: Re: IA64 and protection on RDB$COSIP.EXE

Hi Norm,

Thanks for the reply!

It is a bug, but a VMS/IA64 image-activator bug (that wasn't completely fixed) rather than and Rdb kitting bug. Let me illustrate on my lovely RX2600 VMS/IA64 8.3-1H1: -

$ set file/protect=w:e sys$library:rdb$cosip.exe
$ 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
SQL> exit

(See http://forums11.itrc.hp.com/service/forums/questionanswerdo?threadId=1312923 for complete details)

My problem with someone on your side is they they've arbitrarily chosen to just drop the protection on the image rather than pursue VMS Engineering to fix the problem :-(

The work around for Tier3 appears to be to simply install the T3$PRIVATE.EXE and T3$PUBLIC.EXE shareables with the /SHARE=ADDRESS option in the install utility. It would also appear from the following example that this option is not available to RDB$COSIP.EXE: -

$ set proc/priv=all
$ install remove sys$library:rdb$cosip.exe
$ install add sys$library:rdb$cosip.exe/open/head/protected/share=address
%INSTALL-I-NONSHRADR, DISK$I831H1SYS:RDB$COSIP.EXE installed ignoring '/SHARE=ADDRESS'
-INSTALL-E-NOT_MAPPED, target address not mapped
-INSTALL-I-ADDRINFO, %X00060000 (not mapped address, link-time value)

Must be a C language issue :-)

Anyway, please get on to VMS engineering to fix your problem.

Cheers Richard Maher

PS. Anyone know anything bad about installing images /SHARE=ADDRESS as opposed to a vanilla /SHARE?

----- Original Message -----

More stuff . . . .

Cheers Richard Maher

[Richard J Maher]

http://www.openvms.org/stories.php?story=09/06/17/4386856

Which would you rather use? (and perhaps have bundled with VMS) Just curious.

Cheers Richard Maher

[Ian Miller.]

I guess you are comparing your DIR_WATCH_EXEC utility with the recently updated WatchDir from Jim Duff as they appear to perform the same function?

Perhaps you can open a specific thread about that and indicate if there are any particular attributes of the utilities that you wish people to compare?
Robustness, ease of use, documentation, that sort of thing?