Top Ten Ways to Compromise OS/390 Security

Although OS/390, as well as its predecessor MVS or its successor z/OS, constitutes one of the safest platforms in the IT world, more often than not ignorance and negligence are causes of very important security flaws. I have tried here to make a checklist of most common security flaws that I encounter every day in OS/390 sites. In general, such lapses would enable a connected userid to get important privileges, and bypass security.

1. Sensitive data sets are not protected, or are incorrectly protected.
2. Powerful programs or products are not protected.
3. JES execution classes are too permissive.
4. Security parameters are incorrect.
5. Trivial passwords may be easily guessed.
6. Homemade system programs, incorrectly coded, are installed.
7. The installation mode (or design) of commercial (or homemade) products is flawed.
8. System parameters are incorrect.
9. There are bugs in the operating system, or in system-related components.
10. Surprise...

1. Sensitive data sets are not protected, or are incorrectly protected.

   - An APF library (or a linklist library, or a lpalist library) may be updated by anybody. Ten lines of assembler code suffice for a cracker (somebody who tries to break the security of a computer system without authorisation) to become system special and bypass all security fences (see below about the JSCBAUTH flag). I believe this is the first thing a malevolent (and knowledgeable) intruder would check (see also [9]).

   - A system PROCLIB may be updated by anybody (yes, it may happen that "TEST.PROCLIB" in spite of its name, is a system PROCLIB !). The cracker may create a started task of his own and START it, perhaps taking benefit of a powerful userid.

   - A system PARMLIB may be updated by anybody (see also flaw #8)

   - A catalog may be deleted by everybody.

   - Everybody may read system files that may contain sensitive information (like passwords) : SYS1.UADS, the spool, the RACF database, the VTAMLST, the PARMLIB (JES2PARM), page data sets, the JES checkpoint.

   Remark 1 : shared dasd degrades the security level of all connected systems to that of the least secure system. It is good that sensitive files cannot be accessed from the current system, it's better when they cannot be accessed from ANY other system. Sharing the RACF database is only part of the solution.

   Remark 2 : some kinds of files, that at first don't seem particularly sensitive, can be exploited for Trojan Horse attacks. For example we'll find here :

   - program or Clist libraries (or simply ISPF profile datasets) owned by people that have system special, or operations, userids (for example, PFkeys may be modified so as to issue surreptitiously a ALTUSER command).

   - general Clist libraries, allocated by every TSO userid at logon time. The cracker updates one of them so as to have system special userids issue ALTUSER commands. Or he may even build a fake "logon screen" that is in fact a ISPF panel displayed by a Clist, the purpose of which being to collect userids/passwords. I saw once a fake Roscoe signon screen, built for the same purpose, displayed by a Roscoe RPF (the equivalent of a Clist).

   ---

2. Powerful programs or powerful products are not protected.

   Some tools, monitors and products, either commercial or free, may be used to circumvent security. For example, RESOLVE (now part of the Mainview line, I think) is a great tool for systems programmers : in practice, it is rarely protected (although it may easily be, with exits), so any knowledgeable user may use it to change the APF table, view any data set on disk, zap the memory, issue MVS commands, etc.

   Every AC(1) program, installed in a APF-authorized library, is a potential tool for the cracker. I often see production jobs using homemade or freeware utilities called "MVSCMD", "SVC34", etc. that are unprotected. Experts like Finn Thunbo Christensen of IBM Denmark, especially highlight the subroutines with AC(1) as a cause for leaks.

   Omegamon, the Monitor, etc. are superb tools. He who has the right to use them may bypass security. With Omegamon, a single MZAP command may be used to become RACF system special. Passwords were used in Omegamon to restrict such commands, but passwords often were keeping their default value.

   Very often, people don't protect the utilities they should protect, but they do go to the bother of protecting utilities they don't need to protect, such as AMASPZAP (AMASPZAP could be used to zap VTOCs, but if you have correctly defined your DASDVOL profiles then there is no need to limit the use of AMASPZAP).

   (suggested by Binyamin Dissen) : anyone with access to the hardware console can alter their own security / authorization settings via display/modify (or whatever it is called nowadays) and thus get permission to do anything. This is not something that can even be audited - it will be completely silent. Of course, if one knows how to do this, one probably has a job that pays more than operations.

   ---

3. JES execution classes are too permissive.

   This is in fact another form of flaw #8, however, this is so frequent that it deserves a special entry.

   - everybody may use the JCL "COMMAND" statement to specify an MVS or JES command that the system issues when the submitted JCL is converted. A flaw very useful for the cracker when PROCLIBs are insufficiently protected (flaw #1).

   - everybody may read any tape dataset with BLP (bypass label) processing. Disk datasets may be correctly protected, however the cracker will retrieve the data in tape backups, since with BLP the dsname of the tape file is arbitrary and is not checked.

   ---

4. Security parameters are incorrect.

   As Schramm puts it [3] : "Access control software is not an integral part of the operating system, but a separate component (RACF) that has to be installed and tailored by local staff".

   Different privileges could be exploited from incorrect security parameters.

   - the RVARY password has not been changed

   - important RACF profiles are in uacc(ALTER), or in warning mode, or in the Global Access Table with high access granted

   - too many userids with RACF attributes SPECIAL or OPERATIONS

   - JESSPOOL not activated, sysouts in the SPOOL are unprotected

   - all userids have a default USS UID that is 0 ; the "su" USS command is unprotected

   - password rules are weak : for example, there is no minimum length, so the user may choose short passwords that can be easily cracked by an exhaustive search

   - OS passwords protecting file or catalogs (obsolete with RACF)

   - JES accepts jobs without a userid (BATCHALLRACF option is not on). May be used to submit unidentified jobs.

   - (suggested by Roland Schiradin) end users may submit jobs from CICS or IMS : the CICS or IMS userid is propagated (no USER= in the JOB statement). The JCL may be modified to do inappropriate things.

   - dynamic allocation facilities are usable in CICS, making possible substitution of one dataset by another.

   - products have powerful functions that are unprotected by default (for example, SDSF enables users to issue unauthorized system commands through a shared console ID - this is APAR PQ23530).

   - use of discrete profiles with ALTER access thus allowing control of the access list for that profile - no, it's not a dinosaur flaw, PROTECT=YES in DB2 table DSNZPARM will generate such discrete profiles for ARCHIVE logs datasets (it's the case with the OS/390 v2r9 system that has been delivered by IBM on CDs for our own MP3000 !).

   - a PassTicket is generated on an unsecure non-OS/390 server (the secured session keys are compromised, enabling logon with the related userid(s))

   - (suggested by Nigel Pentland) : SURROGAT profiles. These can be used to improve security but they can also be a weakness too. It is one of the few ways with RACF to access system attributes (SPECIAL, OPERATIONS or AUDITOR) from a UserID which doesn't appear to have those rights.

   ---

5. Trivial passwords may be easily guessed.

   This may be checked with special tools : password crackers. Some commercial security add-ons can also do it.

   This flaw is extremely dangerous when userids attached to started tasks are involved, because very often these are powerful userids. Users attached to started tasks should have no password (protected userids) or the password should be a random binary string. With SETROPTS, the RACF administrator can enforce both numeric and alpha characters to limit dictionary attacks.

   John Rudolph (Senior Security Specialist at CTG Netherlands) adds this : You suggest these userIDs may (should!) be protected IDs.   I'd like to suggest to have this protected attribute turned on in conjunction with an activated *and* RACLISTed PROPCNTL class. That way it isn't possible to have (the powers of) these userIDs propagated by other users. As opposed by 'the' default where these userIDs are to be propagated and could easily be abused / misused.  

   ---

6. Homemade system programs, incorrectly coded, are installed.

   - the champion here is the authorization SVC that may be used by anybody. This SVC is used to toggle the JSCBAUTH bit : when on, you are authorized to issue system calls (MODESET) and bypass security. Sadly enough, you will find system programmers that are proud to have such "goodies" (see [7]). IBM is the original culprit, as it shipped this kind of SVC to enable the user to make use of IEBCOPY from ISPF (at the beginning, compressing libraries under ISPF was impossible, because IEBCOPY had to be APF-authorized and ISPF is not).

   A thread appeared in IBM-Main in September 2001 about the way to "restrict the use of a SVC"[11]. A good example of "protecting" an SVC is by "validating" the calling program, see program IGX00GSF (a copy is hosted here) from Gilbert Saint-flour on CBT file 183. However, the IBM specialist warned :

   "Karl Schmitz"  wrote...
   > It's been my experience that even if an authorization SVC could
   > successfully restrict its use to a list of trusted calling programs, those
   > "trusted" callers will themselves be the source of security problems.
   > Almost no program successfully lives up to the demands of obtaining
   > authorization in midstream while maintaining system integrity.
   > 
   > I've looked at a lot of programs that used authorization SVCs and
   > were believed by their authors to be free of security holes -- I can
   > count on one hand the number of them where system integrity
   > problems weren't discovered.
   > 
   > Karl Schmitz
   > z/OS System Integrity Competency Center
   

   - routines, exits that create a security flaw, for example the TSO IKJEFLD1 exit is used to keep passwords of TSO userids in clear in TSB blocks

   - I/O appendages can modify the pointers in the DEB (Data Extent Block) block in such a manner that they point to any area on a dasd volume, so that the cracker may do uncontrolled updates

   - SVC (or PC) user programs which at first don't seem to create a security flaw, but when called in a certain way may be used to undermine security. As Brian Currah puts it [2] : "SVCs are a primary source of security exposures".

   - PC routines that are installed at a definite address in private storage : you may setup a program at this address in your address-space and call it to become authorized.

   Writing system programs is a hard task. Even apparently innocuous SVCs (like SVC 11 which returns the time and date) may be misused : what happens when I call a modified SVC 11, passing to it parameters located in a storage zone that I am normally not entitled to overwrite ? The SVC should check this and refuse to return any result.

   With other techniques, one may "fool" the caller of a SVC (the victim) into giving the cracker's program control in an authorized state. As Edward E. Jaffe reminds it in [4], "any unintended operation on the part of the victim is considered an integrity exposure".

   IBM tries in [12] to list common mistakes with SVCs :

   1. Creating an SVC to turn on the APF authorization bit in the jobstep control block.
   2. Creating an SVC that moves some number of bytes of data from anywhere to anywhere with no validity-check of the caller's authority to do the move operation.
   3. Creating an unrestricted SVC to call a restricted SVC. The MVS SVCs that have been restricted to authorized callers have been restricted with good reason. Creating an unrestricted SVC will very likely create a severe system integrity exposure.
   4. Saving/restoring registers in the prolog/epilog of an SVC based on register 13 on entry. This creates a severe exposure and is unnecessary because the SVC first-level interrupt handler saves registers in protected storage prior to entering the SVC.
   5. Failing to validity-check a function code which will be used as an index into a branch table. This may cause the authorized program to branch beyond the bounds of the branch table.
   6. Allocating storage in the MVS common area with protection key 8.
   7. Attempting to restrict the use of an SVC by checking the address in main storage from which the SVC was called.
   8. Attempting to restrict the use of an SVC by comparing a secret password passed as a parameter with one imbedded within the SVC itself.

   ---

7. The installation mode (or design) of commercial (or homemade) products is flawed.

   - the product installs an authorization SVC that may be used by anybody

   - the product installs a user SVC in globally writable storage (for example CSA key 8) : I often saw Y2k date simulation products which front-ended SVC 11 with code in key 8 storage.

   - the product installs systems control blocks (like subsystem control blocks) in globally writable storage, when they should normally be in key 0 : the cracker may modify them to get authorized (or to force an IPL)

   - the product manages data (or even programs !) in globally writable storage : nobody can guess what happens when this storage is overwritten

   - a authorized module used under TSO (declared in one of the IKJTSOxx tables) allows the caller to invoke any (authorized) pgm with any parameter list ; this must not be done, not even if the module checks for AC=1. According to Finn Thunbo Christensen (IBM Danmark), "many vendors do not understand the constraints software mentioned in these tables must respect".

   - other design flaws (for example, usage of CVTUSER pointer as an anchor to data or programs)

   Internal software not using external security (RACF) also may cause security flaws. As Tracy West says : using internal security causes overhead which in turn can cause security administration to become fragmented as the environments grow and the IS group attempts to deal with the increasing volume of work to be done. This can cause security to be disjointed, disorganized, mismanaged, not monitored, etc.

   (suggested by Nigel Pentland) : applications using 2 way password encryption, i.e. forget crackers, you can reverse the process and simply decrypt the password every time. After all how many users keep their RACF password the same as their application password?

   Even IBM has been caught writing incorrect code. In the 80's, there was a system integrity problem caused by a SVC installed with GTMOSI (see [5]). Any normal user program was able to get full authority of the CPU (supervisor state). VTAM applications very often must be APF-authorized because they must RACINIT.

   According to [1], "by far the largest factor in initial OS/390 system penetrations are SVCs of Independent Software Vendors (ISVs)".

   ---

8. System parameters are incorrect.

   - the cursed ICHDEX01 exit is still installed (IBM is the culprit, as this exit was shipped with the system all along the 80's), so all passwords are trivial

   - SCHEDxx in PARMLIB has been modified so as to give special authorization to programs, like the "NOPASS" attribute (which helps bypass RACF security). I knew of one site where ADRDSSU was NOPASS - very handy to backup data without coping with security problems. But anybody could use ADRDSSU to read or even update any dataset ! Other sites have DFSMVRC0 (the IMS controller) or SMFDUMP (SMF unload utility) with NOPASS, which is at least useless.

   - authorized commands and programs under TSO (suggested by Finn Thunbo Christensen, IBM Danmark) : many installations do not really understand why there are 3 tables of authorized software in PARMLIB member IKJTSOxx: AUTHCMD, AUTHPGM and AUTHTSF. Therefore they simply keep the 3 tables identical. Then everything works... But it is opening up serious exposures. The name IDCAMS in table AUTHTSF is an example...

   - many members of the PARMLIB have high security impact : PROGxx, LPALSTxx, IEASVCxx, etc. (see also [6]).

   ---

9. There are bugs in the operating system, or in system-related components.

   Fortunately, this is rare, as IBM knows what is a "statement of integrity", and is very responsive when it comes to security flaws. Too bad other suppliers in the Unix or NT field are not as responsive...

   However, to err is human, and experience has proved that all systems have flaws at one time or another : mild flaws (I remember a funny bug in TSO and MVS/XA, by which the password was not concealed when you typed it during logon), and serious flaws (another bug, in MVS/ESA, enabled anybody to APF-authorize any library using the CSVAPF macro).

   The "war stories" caused by bugs are countless (see for example [8]). For us, systems programmers, bugs causing immediate IPLs are the most memorable... I remember a nasty bug in SAS, that caused IPL due to SQA exhaustion (when initializing a work file, SAS was building an extremely long chain of CCWs).

   A War story by Ray Saunders :

   IBM had a bug which they admitted and refused to fix. Evidently, I was the only person known to have bumped into the problem and the possible fix was to some modules they really didn't want to tinker with. To circumvent the problem, I needed my code to run Key Zero in order to modify protected memory.

   The local SysProg said they had no User SVCs Sysgenned and would not create any for me. (correctly viewed them as potential sucurity risks).

   Solution: Built a 'dummy' DCB - DC 150F(0) At the appropriate offset into the DCB, set flags for ISAM and OPEN and at the DCB offset where OPEN would plug the address of the FREEBUF routine, I plugged in an ADCON pointing to a location in my program Pointed to 'DCB' and issued Freebuf SVC (67?) MVT SVC handler gave control to what it thought was FREEBUF but was really my code, entered in Supervisor Mode, Key Zero. My routine saved calling PSW info, did its dirty work and reloaded PSW with original key and pointing to instruction after the LoadPSW.

   ---

10. I was unable to find a tenth security flaw. ...

    Maybe you have some idea that you would communicate to the mainframe community or directly to me at tfalissard@freesurf.fr.ignore_the_last_part_please...

    Bill Husler suggests this : I would expect that the top exposure for most of us is the desire to help a stranded user. You know, that anonymous call to the helpdesk "Hi, I'm John from the payroll department and I forgot my ID. Can you look it up for me? Oh, and can you reset my password as well? What was that remote dial number anyway? I have to get this report out by tomorrow and I can't find my notes."

    Jeff Loewenstein (edpaudit@i-2000.com) says : the phoney phone call warrants an inclusion as an item whether it is number 10 or 15. I have heard a few too many war stories about it (true ones).

    Stuart R. Holland (Stuart.R.Holland@sce.com) proposes this : One of my favorite ones is the 17-character data set name on tape labels. No matter what name is specified, only the last 17 characters go on the label. You can then code any DSN to read the tape, as long as those last 17 characters match. Tools like CA-1 (TMS) keep the whole DSN in their catalog to try and protect it better. However, if you have multiple systems and don't share the TMC, all you have to do is read the tape from another system. This is especially easy to do when remote vaulting is involved. Most companies won't share the TMC between sites, but they do have access to other site's tapes through channel extension. This is similar to the BLP problem, but BLP can be restricted.

    Leo J. Hauguel (hauguelj@wellsfargo.com) says this : One of the biggest problems that we have that compromises any platform is authorizing users full access to the production systems with little to no training at all. Over 80% of problems are still related to lack of education on the part of the user community and this alone is one of the biggest problems we face. Once Management realizes the importance of training personnel then that is one area where we can be less concerned about being compromised.

    While security systems are designed to give access to authorized users and the controls are in place to allow for READ, UPDATE, or ALLOCATE/DEALLOCATE, the actual production environments (CICS, IMS, etc.) grant access to use a specific transaction. The transaction many times gives the user the ability to UPDATE information online. Unless the system is designed so that the file being updated is an "INTERIM" data file and is edited by another program PRIOR to updating the master files, then the system is corrupted with bad data. While the security system has not been breached the data files would contain "garbage" information and rendered useless or at least contains incorrect information. Somewhere that corrupted data needs to then be "FIXED" to be a valid file. This is not usually the short coming of the security systems but of corporate management practices that does not allow for proper training of personnel. We can only secure the systems with the proper authorizations but do not have control over the personnel's level of expertise that actually use the system.

    ---

    A question that was asked in RACF-L in June 2001 : is there some central place where all flaws and solutions are documented for public access, so as to ensure every problem is fixed on a mainframe installation ?

    Walt Farrell from IBM answered : IBMLINK's listing of closed APARs and PTFs comes the closest that I know of. However, for anything that we view as truly significant for security (i.e. what we call Integrity or Security APARs) you won't find much in IBMLINK. In particular we do not describe the actual flaw nor ways to exploit it for those kinds of APARs. We just say "here's a fix you need".

    Also, IBM specially marks Integrity and Security APARs when sending out PUT tapes so you know you should put them on, but again we do not describe the actual problem.

    ---

    References

    1. "How Much is Your Mainframe Software Leaking ?", Statistics on 350 Penetration Tests, Consul Risk Management.

    2. MVS : Mainframe Virtual Security, Brian Currah (1996). Brian has worked closely with Karl D. Schmitz (kdsch@us.ibm.com) for about 15 years on MVS Security/Integrity.

    3. "Added-on security for MVS : weaknesses and measures", Christof Schramm, Computers & Security, 12 (1993).

    4. JSCBAUTH bit left on, a post in IBM-main about exposures caused by SVCs (December 1996).

    5. IBM's meaning of "open" in the abbreviation OSI, Peter Sylvester.

    6. A guide to SYS1.PARMLIB, 1996 Edition, Mark Hahn, MONOGRAPH SERIES, ISACA. See also the more recent MVS Audit and parmlib Workshop.

    7. Public notice of a security leak, Rob van Hoboken.

    8. The Johnson Bug.

    9. Who has UPDATE authority to the APF libraries in your shop ?, by Peter Goldis.

    10. How to Prevent a Break-in to OS390 Systems, by Stuart Henderson.

    11. Restrict the use of a SVC ?, a long thread in IBM-main (September 2001).

    12. MVS Planning: Security, Document Number: GC28-1439-00.

New links :