On 03/05/2012 08:19 AM, Pate, Gene wrote:
I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor
can accomplish that any AC=1 module in any APF authorized library cannot?
Is there anyone else out there that is running any vendor code for which they
have not done code reviews that is running AC=1 in any APF authorized library?
Is there anyone else out there that is running any home grown code with an AC=1
in an APF authorized library for which they have not done code reviews? Is
there anyone else out there that has libraries in the APF list that can be
updated by anything other than there change control system that only allows
modules that have been through code reviews to be installed in their APF
authorized libraries?
How you allow code to get into supervisor state is of no consequence once it is
in supervisor state so, unless you have a pristine system where every load
module library on the system is totally locked down and only the OS libraries
supplied by IBM appear in the APF list, you have by definition accepted
exposures to system integrity. Does your management understand just how exposed
you have left all the company secrets?
Using a PCFLIH backdoor is only one of many techniques that can be used to
accomplish getting yourself into supervisor state and sometimes it is the right
technique and sometimes it is not.
Back in the late 70's I wrote a PCFLIH backdoor because it was not only the
correct technique it was the only technique that would work. My company and its
sister companies had many 168APs that did not have the MVS/SE hardware assist
installed. At that time IBM wanted about $150K per system for the hardware
upgrade and we already had plans to replace all of them over the next 3 years
with 3033s so there was no money to upgrade them. I wrote an SE hardware
emulator that would run on Ups, APs, and MPs and while you got a 15%
performance increase with the hardware upgrade and MVS/SE we still got around
12% with my PCFLIH hardware emulator and we were able to move to MVS/SE 3 years
sooner that we could have had we all had to wait until all the 168s were
replaced.
If there was any criminal activity involved in this entire affair I believe it
was on IBM's part for trying to charge us $150K per system for a microcode
upgrade to a bunch of outdated systems and not on the part any PCFLIH code that
I wrote so I outright reject your assertion that a PCFLIH backdoor is any more
criminal than running any AC=1 module in any APF authorized library that you as
the systems programmer have not personally code reviewed before you allowed it
to run on any system that you are responsible for!
Gene Pate
CSX Technology
Enterprise Architecture
...
While it is a given that a module running "authorized" can, if malicious
or badly written, potentially do anything bad that could be done by a
PCFLIH back door, it also would seem that as a general principle one
would want to be able to limit the potential exposure from sensitive
code as much as possible -- in other words, use the least-global
interfaces that will suffice. Code reviews may be able to catch obvious
malicious code, but the existence of corrective product SYSMODS attests
to the continuing inability of reviews and testing to catch 100% of
subtle errors and bugs.
An authorized vendor module that is normally only invoked from vendor
address spaces, if found to do bad things unintentionally, might at
least be more likely to damage virtual storage and data associated with
the vendor application; and not starting vendor address spaces or
invoking the product could reasonably be expected to suppress use of the
code. While someone familiar with the interface might attempt to invoke
this code in a context for which it was not intended, this would have to
be a deliberate act and not an accident.
I think people tend to have a gut feeling that the exposure from a
PCFLIH back door is much greater because this code has much greater
potential to be invoked by any arbitrary address space and not just for
those address spaces or events related to the vendor product. Users of
the interface are in general unaware they are invoking the vendor code,
and in the worst case scenario a code bug might render the system
unusable even when the offending vendor product is not started or
directly invoked. If sysprogs are unaware that such an interface is
being used by a product, they would also be unlikely to know how to
disable its use if it should become a problem.
The generic "suspicion" toward a PCFLIH back door is probably not unlike
the uproar several years back when another interface was used
inappropriately that could have had serious negative impact far beyond
the vendor product for which it was intended. It was revealed that CA
was distributing in their products an SMP/E exit to automatically bypass
ID errors to compensate for bad packaging of CA SYSMODs at the time.
While only intended to affect SMP/E maintenance for CA products, the
exit was typically globally accessible, and there was no easy way to
verify that it did not have the potential to compromise SMP/E behavior
for all other z/OS product maintenance. Needless to say that approach
was not well received once it became known (and was discontinued).
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
