Varian described a DIAG 128 hole that was exploited in early releases of VM, but said these types of exploits have long since been closed.
VSE expert Rich Smrcina stated that although he doesn’t recall or know of any VSE hacking, that doesn’t mean there haven’t been any instances, as some incidents may not be reported because of the impact of negative publicity.
z/OS and UNIX guru Bob Puppa remembers only one case where a Time Sharing Option (TSO) account was accessed by guessing the owner’s pass- word (one of his children’s names), and even then it was an internal situation. z/OS is a brick wall without easy exploits for most software, as it was architected to protect itself; but integrity exposures in a class of privileged software called authorized programs can still cause damage. By far the largest supplier of authorized pro- grams is IBM, but others exist as vendor products and customer-written utilities.
Ray Overby of Key Resources, Inc., who specializes in security penetration testing and monitoring, explained that bypassing system integrity requires first identifying an integrity exposure, since that will allow a program to perform one or more actions not authorized by a mechanism under installation control. The most critical exploits are those that obtain the ability to do the activities detailed in IBM’s Statement of System Integrity.
Overby says that, “Only a single integrity exposure need exist for your system to be at risk. The larger the shop, the larger the risk due to the number of authorized programs. The integrity exposure is the vulnerability.”
IBM is proactive regarding security and system integrity. z/VM and z/OS have effective security models and z/VSE is continuing to evolve with security enhancements. IBM publishes a strong statement regarding system integrity for z/OS and z/VM (see the accompanying sidebar).
Recently, on the IBM-MAIN discussion list, David Cole commented: “It is acknowledged by both IBM and the mainframe community that authorized programs have the power to corrupt the operating system in arbitrary ways, creating an exploit to gain access. It would certainly be possible to manually build a DEB (system-level structure that potentially could allow access to unauthorized data), and no, it would not be APAR-able (vendor-acknowledged problem to be fixed).” Obviously, if you can install authorized programs, you can compromise the system.
Noted RACF expert Bob Hansel of RSH Consulting summed it up by saying: “I’m not personally aware of any instance where a mainframe has been hacked. However, I think the scarcity of such incidents is due more to a lack of technical expertise by would-be perpetrators than to the sound implementation of controls. We have found serious security holes in all our reviews, but most require a moderate degree of technical skill and knowledge to exploit them. Unlike Windows and UNIX, there are no z/OS ‘script kid- die’ routines that an unskilled user can use to penetrate a z/OS system. However, we’re currently facing new challenges. It used to be that only those relatively few users with TSO or ROSCOE could manipulate system files and execute routines that could harm the system, but with the introduction of OpenEdition MVS (now z/OS UNIX) and common TCP/IP-based network applications, many organizations, some unknowingly, have opened their systems to a much broader user base, including clients and business partners. This increased connectivity is unfortunately coupled with a lack of upkeep on RACF controls. Newer z/OS capabilities either aren’t being protected or fall under the scope of older, less stringent control settings. Both of these factors contribute significantly to the underlying cause of the vast majority of the vulnerabilities we find.”
Examples of insider hacking were even harder to locate; this can be attributed to the difficulty in implementing an internal security exploit and to the desire to avoid negative publicity from acknowledging a security breach.
At a California bank in 1975, an application programmer modified a savings account interest calculation module to move the rounding amount from each account to his personal account during the monthly run. Everything always balanced, so he got away with skimming hundredths of a penny from each account, month after month, until the size of his account balance caught the eye of a branch manager; those small amounts had accumulated into several hundred thou- sand dollars! Technology and internal testing procedures failed to catch this criminal. That was 34 years ago, but the same problem could occur today if proper procedures aren’t followed.
As Walt Kelly’s “Pogo” comic strip character eloquently stated in 1970, “We have met the enemy and he is us.” The responsibility for security rests complete- ly within our collective laps. We can be proactive and fix security holes before they are exploited, or we can ignore the situation while waiting for the inevitable.
The threat of hacking mainframes should be taken seriously. While it appears System z systems are protected quite successfully, we can’t rest on our laurels or think we’re invincible. IBM has done an excellent job of providing an environment with high system integrity along with a set of tools to protect us from ourselves, but we must use them to maintain a secure future.