On Wed, 28 Mar 2012 07:29:22 -0400, Shmuel Metz (Seymour J.) <[email protected]> wrote:
. . . > >That's only a vulnerability if such an SVC exists. You haven't shown >that. No SVC in z/OS that I'm aware of has such an STM. It would >certainly violate IBM's statement of integrity. > I have seen such an SVC, but it would not be the one Ray is talking about as it was locally written. I have no doubt other SVCs with the same problem exist, and it would not surprise me at all if some of them were vendor-supplied. Over a period of about twenty years I found dozens of problems like that. Practically all of them were in software provided by the "who's who" of mainframe software the guys most of you would call "trusted vendors". The problems were often in SVC routines, or more specifically in the SVC "frontends" that could be found stacked waist-high on a typical system. The problems were usually coding errors of the nature of the R13 STM as described by Ray, however there were even deliberate "backdoors". For example, "magic" SVCs that could return control to the caller in supervisor state, or with JSCBAUTH turned on. Such backdoors may have included some sort of checking to try to prevent misuse, but more often than not the checking could be defeated. Trust me, telling the "good guys" from the "bad guys" is very difficult when the bad guys refuse to cooperate. There was a problem of that nature in an early version of a certain IGX... module mentioned in a recent thread here. Of course, the problem is not restricted to SVC routines. I found similar issues all over the place. I have not done anything like that for over ten years now. Does that mean the problem has gone away? I doubt it, even though the last ten years has brought some improvements (for example, preventing allocation of user-key CSA by default). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
