Some further observations on this situation. On naming the perpetrator: It is easy to sound like one of a gaggle of pompous and self important journalists who all know some nasty little secret or piece of gossip, but have appointed themselves gatekeepers of the news and are unwilling to publish. But take care - it is one thing to name the culprit, but another to risk making false accusations of what the offending code does, what dangers it offers to customers, and what opportunities it provides to would-be malfeasors. Certainly if the code turns out to be benign, someone who has made claims as to its dangers may find himself in a bit of a pickle. Even if "everybody knows", I'm going to let this ISV make their own considered and hopefully detailed statement, which I have no doubt they will do in time.
It seems to me that there are three other aspects that can stand further discussion. First is the very existence of a PSW stealer in 2012. I think there is complete agreement that, while this may have been both necessary and acceptable practice in say, 1980, it is for several reasons both astonishing and completely unacceptable today, regardless of any exploits that it may enable. Even though the code takes pains to pass control on to the IBM FLIH within a few instructions for common cases, I imagine that many customers will still not appreciate the performance or reliability implications of having such code installed. Second is the apparently stealth nature of its installation. Here again, I tread carefully, because I don't know what documentation its provider may have given to its customers. Perhaps customers are warned when they install the offending product (which is, to be quite clear, not all or even most products from this ISV) that it replaces IBM's Program New PSW with its own, and thus intercepts all program checks, including routine page faults, PER interrupts, and so on. But let's not get carried away. This is not the Sony root kit scandal, or the Carrier IQ case. This code does not attempt to hide itself from inspection or analysis, nor does it appear to intentionally return misleading results. Third, of course, is the matter of whether it does in fact provide any exploitable way for an unauthorized program to gain control in an authorized state. Perhaps we will all know that sooner rather than later. As I suggested earlier, the code does not pass any kind of sniff test. Any program that under any circumstances turns off the problem state bit in a PSW, which this code does, demands documentation and/or a clear statement of integrity. Perhaps all such circumstances are covered by clear and undefeatable controls, but as others have pointed out, there are surely plenty of options for programs to accomplish this sort of thing using standard facilities. It seems to me that, apart from the eagle eyed Keven Hall, the parties who must know that this code is installed at many sites are its provider, and, by virtue of the unequalled number of dumps it receives from its customers, IBM. That IBM has not to my knowledge issued any public warning about it suggests to me that that while it may be "evil" in a design sense, this code may well not do anything bad in a practical one. IBM would surely not stand by if a widely deployed product provided a convenient method of breaking IBM's own statement of system integrity, so I conclude that it most likely does not. Tony H.
