The hook that Bill discovered is the same one I'm referring to. After I found it I there was some discussion about disabling it to see what might shake out but I had already figured who owned the code and even located the load module in the vendor's load library so we figured it was best to avoid a scene. I'd agree that the code is now more convoluted; it would require some time and effort to decipher it to the point where it could be exploited. Which is not to say I don't consider it an abomination; I do, and it is.
Keven -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Bill Fairchild Sent: Thursday, February 23, 2012 4:43 PM To: [email protected] Subject: Re: Program FLIH I found a similar (and maybe the same) vendor hook in 1996, disassembled the code, and discovered that one of its purposes was to put an unauthorized caller into various protect keys, supervisor state, etc., based on the contents of a register. I alerted the vendor that using a hook such as this was not the optimal way to get into some authorized state. Literally anyone could have disassembled the code enough to see how to exploit the hook and get an unauthorized program into supervisor state and key 0. The vendor made some changes shortly thereafter and claimed that the enhancement was now much better. I didn't have time to disassemble the new version and figure out how to hack into it, but a colleague of mine did and said it was still relatively easy to subvert. This vendor has many products which are typically installed in a system all at the same time, and many of their products make use of this program FLIH hook to do authorized things. You can also find the virtual address of the FLIH by running a very simple, unauthorized batch job if you don't have the access rule mentioned below. Once you know the virtual address, you can see the code with the TSO display storage command, inter alia. Once you can see it, you can disassemble it, and then you can deduce how to invoke the "clever" hook and do wonderful and magic things, none of which I think I should spell out. The vendor apparently does not want to invest in the development resources to provide a hack-proof way to get their products able to invoke authorized functions. I think the vendor also uses this hook for communication between its products, but I am not sure about that. I also remember attending a SHARE session in the early 1980s in which the IBM speaker told the audience that putting magic, secret code value into a register and then invoking a user SVC to check the contents of the register and return in supervisor state was a REALLY BAD IDEA. And this vendor is still doing things that same way. The only difference is that the hook is in the program FLIH instead of a user SVC, the program FLIH is entered in DAT-off mode, and thus it is a little (very little) bit harder to find and disassemble the code to know what to put into the register. Bill Fairchild -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Hall, Keven Sent: Thursday, February 23, 2012 3:08 PM To: [email protected] Subject: Program FLIH Some time back (ca. 1991-1992) I wrote a rudimentary debugger for MVS that hooked into the Program FLIH (I used SIGP to install the hook on each processor). I figured I'd look at the IBM FLIH code and use it as a template but I didn't have access to VPL and/or microfiche listings so I just disassembled the code in an active system (once I had hacked my storage browser to handle real storage, that is, since the Program FLIH is invoked with a DAT off PSW). Once I had a display of the code in storage I stated reading and decoding the instruction stream. Less than a dozen instructions into the process it was very obvious that I was not looking at IBM MVS code. I had stumbled upon a fiendishly well hidden back door. Once I was working for a software company I started finding the same code in SVC dumps sent in by our customers. Eventually I stopped looking for it and then I kind of forgot about it until about a year ago when I found a new version of it in our own system. I started looking for it again in customer dumps and I find it more often than not. If you're at all curious to see if it's in your system/s you can use IPCS (as of z/OS v1.9) to browse real storage when source is specified as ACTIVE. You need to have read access to BLSACTV.SYSTEM in class FACILITY and then use the command: IP L pointer_at_location_1DC ABS INST If the address at location 1DC points to a page boundary it's most likely that the 3rd party code is installed. Happy hunting, Keven
