a bHi list,
There are zillions of ways to hack a zOS system. I do agree that when everything is secured, it is not possible by the very nature of zOS, On the other hand, during my 25+ years as a free lance MVS systems programmer I never worked on a mainframe site I could not hack easily, starting with a vanilla userid. I think we will all agree that the cornerstone of zOS security is the status of the PSW key and supervisor state bits. We can change these through for example SVC's, PC', what most auditors like because it is somewhere on their list, just like the everlasting question about I/O appendages, etc. Their question about the PPT also annoys me the most. A program only has the attributes assigned to it from the PPT if it comes from an APF library. If it is APF, you do not need the PPT. A simple logic apparently impossible to explain to $millions a day auditors. Let us focus on APF. Just some minor remarks0 if you can have it: You can give yourself RACF SPECIAL without RACF knowing it by changing a bit in the ACEE, same goes for OPERATIONS. You can give yourself access to anything that is RACF protected by pointing the RACF exits to your own coding, making an exception for your user id. You can switch off RACF & SMF logging. You can hide some SVC prefixing code in a SMP/E usermodification so that it will be replicated to the next release by a systems programmer who has not examined the assembler coding. So, how to get there with a vanilla userid? You loose APF it when your address space becomes dirty. This is annoying. Lots of sides have home written authorisation SVC's hanging around. Everybody can examine the SVC table, eliminate the genuine IBM ones, and disassemble the others. My experience hit rate 40%. Systems programmers have UPDATE access to APF libraries. Execution of group logon Rexx or CLIST (SYSTEM) followed by (VANILLA) is not exceptional. Change to a copy of your module to an APF one. My experience hit rate 25%. Ask a systems programmer to debug a Rexx. Ask for his wisdom. Go to his desk and let him examine a Rexx exec with an error which he clearly recognizes as a typical idiot symptom. He will demonstrate you that it works now, thanks to his superior brain. Hide a copy of one of assembler modules to an APF library somewhere in an unreadable interpret instruction at the end. I could go on. Other classic: are all STC's PROTECTED? If not, you can try DOS by logon with the STC userid. 2011 Id did a real system integrity audit and found 19176 security holes of the nature mentioned above without looking very deeply. This was a small mainframe. I once started a book about this but stopped because I could not find a publisher interested in zOS. Perhaps I will take it up again. I concluded the draft with (joke) a beastly number of questions, 666. Good night from Brussels (at the time of posting). j@n On Thu, Mar 29, 2012 at 4:54 PM, Shmuel Metz (Seymour J.) < [email protected]> wrote: > In <[email protected]>, on > 03/28/2012 > at 02:37 PM, Andy Wood <[email protected]> said: > > >The problems were usually coding errors of the nature of the R13 STM > >as described by Ray, however there were even deliberate "backdoors". > > Those are defects[1] in the product, not in z/OS. As Walt and others > have repeatedly written, your security is only as good as what you > allow in your authorized libraries. > > >Such backdoors may have included some sort of checking to try to > >prevent misuse, > > They almost invariably do, and almost invariably the checking is > inadequate :-( > > [1] Yes, defects, not features. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
