I started my I/T career as a MVS (now z/OS) Systems Programmer...a "system administrator". In that role, I did a lot of work on system configuration and customization. I was also a security administrator, installing/maintaining/using IBM's "Resource Access Control System" (RACF). During my 5-7 year stint doing sysprog work, I ran into a lot of functions of the operating system that could have been exploited had they not been adequately and correctly protected. This is the case with any computing environment and operating system. There will be holes, if you allow them to be there.
With that background out of the way... I still work extensively with IBM mainframe technology, but now as an architect focused on digital transformation. As a person who works with this stuff, this week a few people sent me a link to a ZDNet article that led with a somewhat silly, breathless title "Pwning the mainframe: How to hack the 'most secure platform on Earth'" Now I know the author gets paid to get eyeballs, so I'm not surprised that they'd use something overblown like that. But because of this, I've been getting inquiries and having to explain to people what that article is about and the truth to it.
Here's my executive summary in response to the article: What is described is a case where an auditor found a shortcoming in the administration of security in their z/OS system, NOT an exposure/bug in the software. They exposed the company's security administration error.
Now here's my geek-out, detailed explanation:
What this article describes is something called the Authorized Program Facility. The article's author gets the terminology a little squirreled up, which can be excused if it comes from someone without some mainframe experience. APF is a built-in feature in z/OS that designates certain libraries of programs as "authorized" so system-level code can be executed from them. The list of authorized libraries is contained in a system parameters file (to be technically accurate: a partitioned dataset) called "SYS1.PARMLIB". It's akin to CONFIG.SYS in the old DOS/Windows operating systems, or to the "System Preferences" on a Macbook. One of the things SYS1.PARMLIB contains is a list of APF-authorized system libraries. This "APF List" has existed pretty much since z/OS (MVS) has existed...it was there when I started back in the 1980s and I'm pretty sure it existed in the 70s and prior.
So there's this APF List of authorized libraries of system level code. In many z installations, that list is almost entirely a list of IBM- or vendor-provided datasets. Sometimes a customer will write their own code that requires system-level authorization (they wrote their own operating system utilities or whatever). So you will often find a few customer-specific libraries in there. NOTE: There is absolutely an issue if someone manages to get access to of one of those libraries and store their own nefarious program in one...and execute it.
BUT...THE DATASETS IN THE APF LIST MUST BE SECURED!
IBM has always always always told customers: "Thou Shalt Restrict Access to APF-Authorized Libraries". And customers who are administering their systems properly do this. It used to be part of my job to maintain the APF List and ensure the libraries were secure. IBM's own zSecure Audit product checks for (among other things) situations where APF-authorized libraries are NOT protected, and lists who has access. IBM requires every z/OS system to have a security management system, and that's where the protection is done. Ours is called RACF - Resource Access Control Facility. Computer Associates also sells a couple of them. But every single customer must have a product like this, AND they must use it to protect APF-authorized libraries.
So what happened here (apparently) is that someone erred by NOT protecting some datasets in the APF list. That's a somewhat uncommon thing, but not unheard of. Audits take place to ensure that kind of thing doesn't happen. This auditor did their job by finding a problem in administration where APF-authorized libraries were not secured.
Think of it this way: This is no different than someone posting the root password for a server on a sticky note on the outside of the server. It's one of those things you just don't do. So if you consider looking at a sticky note and using the password to log in and do nasty things to be "pwning the server" ... ok, I guess that's what you can do.
In my opinion, there's not really an issue here. The news: An audit worked. That's good. If the customer had been leveraging an audit tool like zSecure on a regular basis, this issue would have been discovered quickly and the customer would have had the awareness and ability to quickly remediate the problem.
Admittedly, the article probably serves a useful purpose by pointing out a situation where IBM z/OS customers need to pay attention: Don't leave APF-authorized libraries un- or improperly-secured.
NOTE: This article is the opinion of the author. I do not speak on behalf of the IBM Corporation.
