On 2/24/2012 9:54 AM, Gibney, Dave wrote:
What I don't understand, pardon my "naifness" (split the thread John:), is the need for such today.
I suspect new code authored from-scratch today, by the "offending" vendor, would never intentionally use a hook like the one that has been described here. But an existing infrastructure might depend on it heavily. And, many different products from a single ISV can share the same robust infrastructure. The exploit (if it exists) might not be any harder to crack than it was for NEON's zPrime to turn on a bit to make TCB work eligible for zIIP execution. Or it might now be a maze of checks that cannot be exploited by others. It is a complete myth that IBM doesn't sanction SVCs that turn off the problem state bit in the PSW. If that were true, the mere existence of IGX00011 would invalidate IBM's integrity statement for z/OS. That extended SVC routine (ESR) can be invoked by an unauthorized problem program with the right name and other attributes and it will return in supervisor state. Guaranteed!
When any of the vendors I named instruct me so, I dutifully APF their libraries and they often reside in the linklist which we at least do set AFP via IEASYSxx.
You can't be expected to catch subtle MVS integrity exposures at install time. You must assume that no legitimate software vendor--including IBM--would knowingly violate its own integrity statement. Furthermore, I hope you didn't hesitate when our installation instructions asked you to covertly deploy our sabotage backbone along with the rest of our authorized components. To activate, press ATTN three-times and in the secret prompt area type in the name 'JOSHUA". Enjoy! . . . . . . . . . . . . LOL! This is a JOKE! We have no back doors of any kind. We take MVS integrity VERY seriously! :-D -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 [email protected] http://www.phoenixsoftware.com/
