>If when PARMDD appeared on the EXEC statement an old program >simply received > > R1 -> fullword -> H'0' > >... there'd be no integrity threat in passing PARMDD to old authorized >programs. They are all prepared nowadays to handle PARM=''. >However, IBM saw fit to provide the LONGPARM attribute on load >modules for authorized programs, implying that IBM perceived such >a threat, and PARMDD uses the traditional CALL/EXEC/ATTACH/XCTL >interface.
PARMDD does not use the traditional CALL/EXEC/ATTACH/XCTL interface. I thought that had been made clear. The use of PARMDD requires no change to programs that can handle any length in the 0-32760 range other than the new binder attribute for AC=1 programs from APF-authorized libraries. It is true that if the use of PARMDD resulted in passing a halfword length of 0 there would be no "threat" but there also would be no chance of things "working" without code changes in the target module. That would greatly inhibit exploitation. Obviously JCL changes are needed in order to use PARMDD. Target-program changes are needed only if the program has not been coded to handle the longer input (there being many ways in which programs could "not handle"). And some of those "not handle" cases could result in system integrity exposures in authorized code (consider the "MVC" case where the target buffer is 100 characters long; the extent of the exposure depends on what is in the subsequent 156 bytes). That is why the binder option is required for such cases. Non-authorized programs will likely fail with PARMDD if they are coded in such a way (hence my note in a previous append that you should not use PARMDD unless the application has asserted that it can handle it), but that is not a system integrity exposure. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
