In my opinion there are some misconceptions about the ability of an ESM product to mitigate integrity based vulnerabilities and why this should be a concern for you. In general, your ESM product will not be able to help you much when dealing with these types of vulnerabilities. I will try and explain by example based on several real world integrity vulnerabilities what I mean.
Lets say there is a SVC that when you IPL your z/OS system it is installed and available for use (i.e - any one can issue the SVC). The SVC either came with z/OS or your system programmers installed it because of an ISV product your company purchased or its an in-house written program. For this example lets assume one of your TSO users will attempt to exploit this vulnerability. The TSO user has no extra-ordinary security privileges.
Like any SVC when invoked it will get control in an authorized state (PSW Key 0). Further this SVC issues a STM instruction very early in the SVC code storing into where ever R13 points to. This type of defect is easily exploited writing a simple program (could have been posted on the web) that would issue the SVC and:
- Just before the SVC is issued point the unauthorized program's R13 to some critical memory location. When the SVC code executes it will modify the storage pointed to by unauthorized program's R13. If the system does not crash right away then put it into a loop and reissue the svc with R13 pointing at different areas. Eventually you will crash the system.
- Just before the SVC is issued point the unauthorized program's R13 to your security credentials, preload your registers with appropriate values, and have the SVC update your security credentials for you.
Note that it does not matter if the SVC "worked" or not. As long as the STM instruction was executed (it always was) then whatever went on later did not matter.
On a RACF system you could exploit this integrity vulnerability by dynamically elevating your security authority by enabling RACF privileged attribute for your ACEE. You would be able to do similar actions on a TSS or ACF2 protected system as well. According to IBM documentation RACF privileged users have access to any RACF protected resource without logging. Even if there are exceptions to this you could suppress WTO's and any SMF records as well (with a little more work). Once the TSO user has dynamically elevated their security authority they can then access whatever ESM protected resource they want. With no audit trail. Or you could modify your security credentials to be the high powered system's programmer or security officer and let the logging occur. This may get you through any system exits you have in place that check for those users.;-)
Based on these real world examples I was able to write that program: - Dynamically elevated TSO users ESM security authority- Access ESM protected resources the TSO user was not specifically authorized to by the installation
- Suppress any WTO's or SMF about the activity for the TSO user.The ESM products did not stop the TSO user from exploiting this vulnerability. Nor did they provide any audit trail for accessing the protected resource the TSO user was not authorized for. No system data sets were updated. No APF authorized library were updated. The program does not require link edit with AC(1). In this case there was nothing the ESM's could do.
The places where this work was done had stringent security requirements, internal/external auditors, periodic security reviews, and were very diligent in implementing their computer security. Yet with the exploit of this vulnerabliit the TSO user bypassed all of the installations controls and left no audit trail for later analysis. With this program the TSO user was able to compromise all data on that system as well we the system itself. What if that data was secret government or military data, or was credit card or insurance company customer data? That would violate ever compliance standard there is!
Unfortunately, there are integrity based vulnerabilities similar to this that are on your z/OS system today. Your ESM controls will not help you if they are exploited. If you are not concerned that your users can crash your z/OS system at any time (maliciously or accidentally) OR your users can access any ESM protect resources regardless of installation controls with no logging or auditing then by all means ignore the issue. It does not mean it is not true.
Ray Overby Key Resources, Inc. Ensuring System Integrity for z/Series^(TM) www.zassure.com (312)574-0007 On 3/27/2012 15:06 PM, Joel C. Ewing wrote:
Yes, it is true that if you could introduce a trojan into an APF library you could compromise z/OS, and that this might be possible:If you don't have RACF or equivalent properly configured to protect all system data sets; If you allow update authority to APF libraries or PARMLIB to people other than those which require it for system-level maintenance; If you install modules into APF libraries from any sources other than trusted vendors; If you add installation hooks deliberately designed to circumvent security that might be exploited, or tolerate vendor products with such exposures; If you don't have some sort of change management, oversight, and monitoring in place to catch violations of installation security policies.In a very real sense RACF and system maintenance policies and the mindset and training of z/OS SysProgs are the anti-virus software on z/OS and this combination has worked quite well over the decades -- much more reliably than even the best anti-virus software on MS platforms, and no periodic database or detection program refresh ever required.The concept of allowing average-Joe user to be able to download data from arbitrary sources in arbitrary formats and being able from that to somehow introduce executable code into the system in ways that will execute with special privileges so as to introduce a virus or trojan is an issue that is endemic to Windows platforms but foreign to z/OS.Thus it makes excellent sense for auditors to examine and question installation RACF conventions, access to critical system data sets, and change management procedures. It makes zero sense to ask what is your z/OS anti-virus software.JC Ewing On 03/27/2012 01:49 PM, David Cole wrote:I'm sorry Tom. I did not intend my remarks to be personal. I deeply regret that you feel hurt by them. Please don't let my words deter you from future contributions. Your thoughts generally are more valuable than most. I just wanted to emphasize the APF Trojan horse vulnerability. It is real, it is serious, yet for decades everyone seems to want to pretend that it does not exist... It mystifies me....www.zassure.com is the closest thing I've seen to an MVS anti-virus program. After seeing a demo, I would have bought it, or recommended it to a client. Check it out, you will be surprised, if not shocked.Thank you for this. I will check it out.[Regarding SAF] I do take issue with your last sentence. SAF and an ESM have everything to do with anti-virus protection, provided they are configured to correctly protect APF-authorized resources.Perhaps. However, all an APF authorized program has to do is flip a bit or two in certain RACF control blocks, and voilà! He's suddenly a supervisory program and, as such, is given a pass on all RACF calls... Alternatively, a malicious APF program can simply dynamically front-end certain supervisory programs, and again voilà! (As I'm sure you know, APF programs can fairly easily defeat all hardware storage protections.) Yes, SAF is still called even for APF programs, but an APF program can still subvert those calls.I've never forgotten this [APF libraries]. That's why my APF-authorized libraries are severely limited in scope, and audited for any and all updates.Enforcing trust is a technical issue. RACF is very good at that. Deciding who to trust is a management issue. Even at shops that allow only trusted vendor software into APF authorized libraries is implicitly trusting the hundreds or even thousands of people involved in the development of that software. Again, I go into more detail about this in my prior post:"<https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches>https://bama.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&I=-3&X=6EB01556E36E4D9CAC&Y=dbcole%40colesoft.com&d=No+Match%3BMatch%3BMatches". Again, please accept my apology, Tom. It was not intended to be personal. I'm sorry it came out that way. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow Road VOICE: 540-456-8536 Afton, VA 22920 FAX: 540-456-6658 At 3/27/2012 02:21 PM, Pinnacle wrote:Replies like this are why I seldom post to IBM-Main anymore. The fact that it comes from someone who I respect and consider a friend hurts all the more. Bottom line is that I work for a living, and I often don't have time to respond in gory detail to everything posted. My primary objective here was to stress that the z/OS architecture is inherently hardened against viruses. The fact that I did not go into explicit protections for APF-authorized programs appears to have been my fatal flaw, according to Mr. Cole. Regardless of what comes back, this will be my last post on the subject. My comments below. Regards, Tom Conley On 3/27/2012 1:06 PM, David Cole wrote:At 3/27/2012 11:19 AM, Pinnacle wrote:There is a mainframe product that protects against malicious software. It's called SAF, and it interfaces with ESM's like RACF, or ACF2, or TopSecret."SAF" is not a product. It stands for "System Access Facility" and it is nothing more than an interface within z/OS into which a security system (such as ACF2, TopSecret and any ryo security system) can plug into to receive and respond to security calls. It really has nothing to do with anti-virus protection.SAF is not a product, you're right. Please forgive my use of the term "product", I should have said "feature". I do take issue with your last sentence. SAF and an ESM have everything to do with anti-virus protection, provided they are configured to correctly protect APF-authorized resources.It [z/OS] is the only operating system out there with built-in anti-virus protection. On top of that, the hardware itself actively protects against damage through storage keys, protected memory, etc. You have to explain to the auditors that anti-virus software is not needed on z/OS, because it's intrinsic to the operating system and the hardware.I think you seriously misunderstand what a virus is... Yes, z/OS has exceptional security (and integrity and reliability) features for protecting against non-authorized programs. But I must emphasize... -->NON<--authorized programs! When it comes to AUTHORIZED programs, z/OS's integrity (which is what you are talking about with "storage keys" and such) is very good, but of course not bulletproof. Worse though, when it comes to SECURITY, there are some real problems! Because with the proper knowledge, it is TRIVIALLY EASY FOR AN AUTHORIZED PROGRAM TO SUBVERT SECURITY COMPLETELY! This is what mainframers constantly forget regarding security. For authorized programs there is no security. All that is necessary for a malicious program to do is to Trojan-horse its way (with the AC(1) attribute) into an authorized library, and you're done for!I've never forgotten this. That's why my APF-authorized libraries are severely limited in scope, and audited for any and all updates.As far as I know there is no serious anti-virus program for mainframes. I believe strongly that there needs to be one, but I don't know of one. And at this stage of the mainframe culture, I would be seriously suspicious of the efficacy of any program that claimed to be anti-virus. I don't think that a serious mainframe anti-virus program can exist unless and until IBM itself makes acommitment to support an effort to make the mainframe anti-virus proof....
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
