Wrong image name identified in IMGNAME error message

[Richard J Maher]

Hi,

Below is the dispatcher snippet and attached is the six-year old discussion from COV.

Cheers Richard.

00C0 14820 ; If there are more than 6arguments, they must be copied from the

SYSTEM_SERVICE_DISPATCHER Change Mode System Service Disp 19-NOV-2004 08:30:51 MACRO-64 V1.2-108-367CC Page 23
X-52 Change Mode to EXEC Dispatcher 20-JUL-2004 21:14:13 [SYS_2.SRC]SYSTEM_SERVICE_DISPATCHER.M64;1

00C0 14821 ; caller's to the inner mode stack. We neither validate the argument
00C0 14822 ; count nor probe the accessibility of the data pointed to by the
00C0 14823 ; arguments. However, we have to make certain we can access the
00C0 14824 ; arguments themselves.
00C0 14825 ;
*Optimized* 14826 AND R25, #255,R22 ; isolate number of arguments
*Optimized* 14827 OR R16, R31, R2 ; Save prvmod
*Optimized* 14828 SUBQ R22, #6, R22 ; get number of arguments > 6
*Optimized* 14829 BLE R22, 30$ ; if LEQ, 6 or fewer
00D0 14830
*Optimized* 14831 OR R17, R31, R6 ; Save additional argument registers
*Optimized* 14832 OR R18, R31, R1
00D8 14833 ;
00D8 14834 ; Set up to probe the caller's excess parameters. These are
00D8 14835 ; on top of caller's stack, whose address has been saved in R28.
00D8 14836 ;
*Optimized* 14837 OR R16, R31,R18 ; copy caller's CURMOD for PROBE
*Optimized* 14838 OR R28, R31,R16 ; PROBE wants address in R16
*Optimized* 14839 S8SUBQ R22, #1, R17 ; point to last datum
00E4 14840 ;
00E4 14841 ; Probe caller's stack to insure we can read the arguments themselves
00E4 14842 ; (not what they point to).
00E4 14843 ; Because the maximum number of arguments is 255 we will not span more
00E4 14844 ; than two Alpha pages.
00E4 14845 ;
*Optimized* 14846 PROBER ; can we read the argument list?
*Optimized* 14847 BLBC R0,KERNEL_ACCVIO ; no, fail service
00EC 14848 ; (NOTE: caller R26 still intact)
*Optimized* 14849 SUBL SP, R17, SP ; make room for arguments
*Optimized* 14850 BIC SP, #15, SP ; force OCTAWORD alignment
*Optimized* 14851 OR SP, R31, R18 ; copy pointer to inner stack
00F8 14852
00F8 14853 ;
00F8 14854 ; Determine if sign extension checking should be performed for the stack-based
00F8 14855 ; arguments.
00F8 14856 ;
00F8 14857 20$:
*Optimized* 14858 AND R5,#SSFLAG_K_64_BIT_ARGS, R28
*Optimized* 14859 BNE R28, 27$
0100 14860
0100 14861 ;
0100 14862 ; R18 -> inner stack
0100 14863 ; R16 -> caller stack
0100 14864 ; R22 = number of excess parameters to be copied
0100 14865 ; Copy doing sign extension check.
0100 14866 ;
0100 14867 25$:
*Optimized* 14868 LDQ R28, (R16) ; get caller's datum
0104 14869 IS_32_BITS R28, R0 ; check if arg is sign extended
*Optimized* 14870 STQ R28, (R18) ; store in inner stack
*Optimized* 14871 LDA R16, 8(R16) ; autoincrement
*Optimized* 14872 LDA R18, 8(R18)
*Optimized* 14873 SUBL R22, #1, R22 ; count it
*Optimized* 14874 BGT R22, 25$ ; loop if not done
*Optimized* 14875 BR R31, 29$ ; branch around non-sign extended check copy
*Optimized* 14875 ing
0128 14876

SYSTEM_SERVICE_DISPATCHER Change Mode System Service Disp 19-NOV-2004 08:30:51 MACRO-64 V1.2-108-367CC Page 24
X-52 Change Mode to EXEC Dispatcher 20-JUL-2004 21:14:13 [SYS_2.SRC]SYSTEM_SERVICE_DISPATCHER.M64;1

0128 14877 ;
0128 14878 ; Copy stack arguments without sign-extension checking.
0128 14879 ;
0128 14880 27$:
*Optimized* 14881 LDQ R28, (R16) ; get caller's datum
*Optimized* 14882 STQ R28, (R18) ; store in inner stack
*Optimized* 14883 LDA R16, 8(R16) ; autoincrement
*Optimized* 14884 LDA R18, 8(R18)
*Optimized* 14885 SUBL R22, #1, R22 ; count it
*Optimized* 14886 BGT R22, 27$ ; loop if not done
0140 14887
0140 14888 29$:
*Optimized* 14889 OR R6, R31, R17 ; Restore registers saved across PROBE
*Optimized* 14890 OR R1, R31, R18

[John Gillings]

Richard,

Are you actually looking for help and advice, or are you just here to insult people?

Consider:

CLRL R0
CALLG (R0),your-routine

upon entry to your routine, AP will be zero. Therefore the instruction:

CMPB (AP),#anything

will ACCVIO.

Try it on a VAX, look it up in the architecture manual (section 8.4 in my 1977 first edition). That's how the CALL instruction is defined.

Now, as it *happens*, in some cases the Alpha MACRO-32 compiler may generate code for the CALL in such a way as to result in an ACCVIO *before* actually calling the target routine. That may protect you from this particular exploit, but depending on coincidences is entirely the wrong attitude when coding in inner modes.

The first rule of inner mode, is to do your best to AVOID it. The second is to not trust anything sent to you. That includes the AP and everything it points to.

Again, I suggest that you look at what you're trying to achieve and use the available user mode mechanisms.

[Hein van den Heuvel]

Richard, I respect your techincal insights and probing questions and sense of humor. But replies are no longer constructive, sarcastic, cynical or funny but crossed in to the ugly world of personal attacks. Please don't.



Regards,
Hein van den Heuvel.

[Phil.Howell]

ok back to the original questions...

Q1: Without the use of enhanced privileges and with the Main Executable Image not having being INSTALLed: - Can a call from an inner-mode UWSS out to any other shareable image (/PROTECTED or otherwise) be spoofed and redirected to another shareable image?

No - until proved otherwise.
(what do have against installing your executable image with privilege?)

My testing to-date indicates that the image activator insists on all shareable images being INSTALLed. Is this supported and architected behaviour?

Yes - but only if the executable is privileged, or any shared image referenced by the executable image is protected, or if the executable image is installed as /execute_only
Shared images that do not have any security implications do not have to be installed.

From Install utility reference:
" any routine called by the privileged image must also be trusted. For this reason, any shareable images activated for use by a privileged image must be installed. Only trusted logical names (names defined in executive and kernel mode) can be used in locating shareable images to be used by a privileged image."

Q2: When a LIB$ routine is called from an EXEC Mode UWSS, why does the image activator consider Non-Trusted, Supervisor-Mode Logical Names when activating LIBRTL? Furthermore, why does the image activator then appear to ignore non-trusted logical names when activating other shareable images? Is there something peculiar about LIBRTL?

When I tried your code, it worked when I wasn't expecting it to, so I'll pass on this one while I re-check what I did.

One question
$install/list shows installed image details
what determines if an image is listed as
"Shared" or "SharAddr"

Phil

[Guy Peleg]

As one of the forum's moderators I have
deleted some answers I considered inappropriate.

John Gillings is one of the best VMS people
on planet earth.

Guy Peleg
OpenVMS Engineering