> We look for such SVC There is no "such SVC". What is under discussion is code that runs legitimately in key zero tuning on JSCBAUTH, not an SVC that does that.
IMHO, for 3rd party vendor that requires APF to use that to turn on JSCBAUTH is grossly irresponsible, and I'd love for you to catch such a vendor. I just don't believe that it is possible short of reading the code thoroughly. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of ITschak Mugzach <imugz...@gmail.com> Sent: Saturday, June 1, 2019 2:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls We look for such SVC in our STIG compliance product IronSphere. We advise adding ESM control in facility class to control who can use it in case this SVC is a must. ITschak בתאריך שבת, 1 ביוני 2019, 2:19, מאת Ray Overby <rayove...@comcast.net>: > In response to "Since when does MODESET turn on the JSCBAUTH bit? Just > how do you propose that IBM prevent key zero code from setting it? Why > do think that turning on JSCBAUTH lets key zero code do anything that it > couldn't do anyways? If the installation doesn't control what goes into > its authorized libraries then the vulnerability is in management, not in > the platform." > > You are correct - MODESET does not set JSBCAUTH. What I meant to say is: > > Some of the vulnerabilities I have discovered in the wild will do the > following: > > * As part of a APF authorized product there is a SVC or PC routine > that when called will turn on the JSBCAUTH bit > * Product application code (psw key 8 problem state not-apf > authorized) will issue the SVC or PC to turn on JSCBAUTH bit > * After control returns from SVC or PC routine the application program > then issues MODESET KEY=ZERO or MODESET MODE=SUP - Since JSCBAUTH > bit is on this does not ABEND with S047 - MODESET works. > * Application code will do "authorized stuff" > * Application will invoke the SVC or PC routine to turn off the > JSBCAUTH bit > > By dynamically turning on the JSCBAUTH bit allows the application to > dynamically elevate its z/OS authority (ability to MODESET) which it > would not normally be allowed to do. Disallowing this type of dynamic > elevation of z/OS authority would make this kind of code logic unusable. > It would force those that use this technique to adopt a different, more > secure approach. > > > On 5/31/2019 12:21 PM, Seymour J Metz wrote: > >> The security code path can be modified (if it is non-rent), frontended > by using content supervision functions (ex - task lib), or bypassed. > > Sure, a user can front end parts of the application, he won't have > access to the production data. Of course, if installation management lets > everybody and his buddy alter the production JCL, then all bets are off, > but then the crackers don't need to front end the application. > > > >> * I don't know who Schiller is. Can you clarify? Thanks. > > https://secure-web.cisco.com/1c4OrmAe9KnhmZx8g9sBxlSsv-hIMbNz9UGjkio7TFzPajz6dlrUSWmHtQ00ppd4Fo67mAAWdaKVO92JLY29NoiDxrsi6xZFpNHQz5arBb1KY5RGDAEMESUo0ynBKZ91aPA_lJJ7s46fljALKFJiHA_veVLbCfDmlaNNyl40LTbhwPVSTPN86pIC6qJ8UmPJAi92ayGPAiQ1tP31vCnOEawBhkAkgyIpNL9uGlDcKflPs0P7TdTPCGIjqSETQACespkocZvWIs4yFILQdq9mZgskwJdZf3PHQtKObFdT1UFxGzAIKky9e8MZuJKx_vM8wJjpUJpGWZqSxV7qeX6GUG7Czsd3IdESStaKEUWyRzPtjanZB5KZbQddfyedqsCmB5uxptJVkBnPZ1CQAqRPltIdY5X0AMprTvq-d5fEuEtu_VdOOpBcamTO_hgAhzgdq/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFriedrich_Schiller > > https://secure-web.cisco.com/1QQeEhpQJLEg-12skT-aktu0983OzbgoTd4Kbnku6kDsj5fkW3LPONrHhE04xCfPJd_FqQmAXTb-iszk7K5aCq-8p62_YCZIUj3EaGue4KQjQVizQ88-fWoXyyVYpxOInRR66ucRqUnEo7sbJct4tc0u5oCMWJmINWIDeptbhjhyMBeR_BFGKB_GIOIoaGh-czVK2yjvy0mYcVzzdANX6e5G7MBauV0gXRY0uaTy1aNYSQu5-COzF-KQk7jwwNbFfhQxHLChlwJe7hFapIM4ceqyHtI1QjilX0nTyfXBQOZ2CpkSiymI4TOC7j1Has2tfDxkXE-c5ycyz-HtkPBrvFVXUDwyTOiZx2O7CkuyhgQY6DFzUJsZJZbCz15xM7FZsiPZJSl8gfBVHtpOzbJi86cZ9GBqbKz959GlbBICgcEJEFr5UsBlXIhEP38FPU4Dw/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FThe_Maid_of_Orleans_%28play%29 > > > >> * As an example - The platform could make a new integrity rule such > >> as: Only SVC 107 can turn on JSCBAUTH bit. > > Since when does MODESET turn on the JSCBAUTH bit? Just how do you > propose that IBM prevent key zero code from setting it? Why do think that > turning on JSCBAUTH lets key zero code do anything that it couldn't do > anyways? If the installation doesn't control what goes into its authorized > libraries then the vulnerability is in management, not in the platform. > > > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > ________________________________________ > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Jesse 1 Robinson <jesse1.robin...@sce.com> > > Sent: Thursday, May 30, 2019 5:48 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Just how secure are mainframes? | Trevor Eddolls > > > > It must be Friday somewhere. I put 'against stupidity' into Google. > Schiller's exact quote popped up first. Just sayin'. > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > robin...@sce.com > > > > -----Original Message----- > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Ray Overby > > Sent: Thursday, May 30, 2019 11:45 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Fwd: Just how secure are mainframes? | Trevor > Eddolls > > > > In response to "Please note that an unprivileged application can still > have a dangerous back door that compromises, e.g., privacy, by giving a > user authorized to access the application access more data than he is > authorized to see." > > > > As a developer of security interfaces for applications: It is extremely > difficult to design an unprivileged application security interface in code > that runs in PSW Key 8 problem state not apf-authorized. The security code > path can be modified (if it is non-rent), frontended by using content > supervision functions (ex - task lib), or bypassed. In addition, > application storage areas + ESM (external security manager) credentials > cannot be in key 8 storage as the application code could accidentally or > maliciously modify them. > > > > A properly designed z/OS application would have separate application and > system level programs and memory objects. These programs would be invoked > differently (ex - EXEC PGM= vs a SVC or PC routine). The application code > would call the system level programs whenever an application function needs > to be performed that requires security checks. In this way the system level > code + memory objects they reference cannot be accidentally or maliciously > compromised by the application code or other programs running on the > platform. > > > > So called unprivileged application security code is really just > application code. Important (really). But I do not like calling it > security code as it does not meet the due diligence required for system > level security code. Calling application code "Unprivileged application > security code" leads people to assume that the code has integrity and > therefore is secure. In most cases, this is not true. It spreads a false > sense of security. > > > > In response to "It can if you don't install the broken application." > > > > * Must of the code vulnerabilities I find are zero day > > vulnerabilities. This means there is no fix. If there is no fix then > > it is almost 100% certain that the client installing and/or running > > the product would have no idea that they are installing/running a > > back door on their system. > > * Before you install a product (how often does that happen these > > days?) do you ensure that all maintenance is applied or just hipers? > > What about integrity fix's? You probably have a different answer > > depending upon which vendor it is........ > > > > In response to "To quote Schiller, "Against stupidity the gods > themselves contend in vain." The OS can prevent am unauthorized application > from accessing unauthorized data or elevating its privileges; it cannot > prevent the application from violating its own specifications. The OS also > cannot protect against malicious modifications; it's a management > responsibility to vet personnel and 3rd party providing OS changes and > other privileged code." > > > > * I don't know who Schiller is. Can you clarify? Thanks. > > * As an example - The platform could make a new integrity rule such > > as: Only SVC 107 can turn on JSCBAUTH bit. Any other SVC or any PC > > routine that does it will abend with S047-98 (yes, I just created a > > new abend code for integrity - Byte me!). This would render useless > > most of the currently implemented "magic SVC or PC routines" that > > turn on JSCBAUTH bit that are running in the wild today (FYI - this > > is another sub-category of a TRAP DOOR vulnerability). There are > > ways to get around this (several come to mind as I write this) > > however I would ague that a change like this would benefit all users > > of the platform. The same business arguments that were used to > > eliminate Key 8 common storage usage could be used for this change. > > With similar benefits. > > > > On 5/30/2019 10:28 AM, Seymour J Metz wrote: > >>> Does it really matter if an application vs z/OS has a trap door > vulnerability? > >> Not if you don't care about security. If you care then you must > investigate both. Please note that an unprivileged application can still > have a dangerous back door that compromises, e.g., privacy, by giving a > user authorized to access the application access more data than he is > authorized to see. > >> > >>> In either case z/OS and the ESM's cannot function properly when the > >>> TRAP DOOR vulnerability is exploited. > >> It can if you don't install the broken application. > >> > >>> Shouldn't z/OS be able to protect itself from accidental and/or > malicious vulnerabilities? > >> To quote Schiller, "Against stupidity the gods themselves contend in > vain." The OS can prevent am unauthorized application from accessing > unauthorized data or elevating its privileges; it cannot prevent the > application from violating its own specifications. The OS also cannot > protect against malicious modifications; it's a management responsibility > to vet personnel and 3rd party providing OS changes and other privileged > code. > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> http://mason.gmu.edu/~smetz3 > >> > >> ________________________________________ > >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > >> behalf of Ray Overby <rayove...@comcast.net> > >> Sent: Thursday, May 30, 2019 7:28 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > >> > >> In response to "An application with a trap door is an application > >> vulnerability. If there is a trap door in z/OS itself then that's a > >> platform vulnerability." > >> > >> Does it really matter if an application vs z/OS has a trap door > >> vulnerability? In either case z/OS and the ESM's cannot function > >> properly when the TRAP DOOR vulnerability is exploited. Shouldn't z/OS > >> be able to protect itself from accidental and/or malicious > >> vulnerabilities? Isn't that what a platform is supposed to do? Isn't > >> that a requirement of a secure system? > >> > >> Every program in z/OS has certain rules of the road it must abide by. > >> System level programs (PSW Key 0-7, Supervisor State, APF authorized) > >> regardless of whether they are in z/OS or an application have > >> additional rules they must adhere to (i.e. - they must not violate the > >> integrity of z/OS). These rules of the road are the responsibility of > >> and dictated by the platform. Integrity is a platform issue. > >> > >> One of the reason's the mainframe is the most secure-able platform is > >> at least partially based on integrity. Integrity as implemented by the > >> platform is why security is possible. Without platform integrity > >> security is not possible. So all code (z/OS and application) that > >> operates at a system level (i.e. - PSW Key 0-7, Supervisor state, APF > >> authorized) must not violate the integrity rules. Failure of a single > >> program regardless of whether it is part of z/OS or an application > >> will allow a hacker to compromise that system and all data on it. > >> > >> In response to "I'd be willing to bet a substantial amount that the > >> majority of penetrations in z/OS are application, configuration, > >> personnel and process vulnerabilities rather than z/OS vulnerabilities." > >> > >> In terms of numbers of vulnerabilities there are fewer code based > >> vulnerabilities (TRAP DOOR is one example of a code based > >> vulnerabilities - there are others) vs configuration based > >> vulnerabilities. I would point out that a hacker only needs a single > >> TRAP DOOR vulnerability to compromise the platform regardless of how > >> the platform is configured. So fewer code based vulnerabilities does > >> not help. All code based vulnerabilities have to be removed from the > >> system in order to secure the platform. > >> > >> On 5/29/2019 2:57 PM, Seymour J Metz wrote: > >> > >>>> A single TRAP DOOR code vulnerability pierces the veil of > >>>> integrity and can be used to compromise the mainframe. Is this a > platform weakness? > >>> An application with a trap door is an application vulnerability. If > there is a trap door in z/OS itself then that's a platform vulnerability. > I'd be willing to bet a substantial amount that the majority of > penetrations in z/OS are application, configuration, personnel and process > vulnerabilities rather than z/OS vulnerabilities. > >>> > >>>> Would you say that the elimination of User Key Common storage is an > >>>> example of a z/OS change to address a mainframe platform weakness > >>> Partially. > >>> > >>> -- > >>> Shmuel (Seymour J.) Metz > >>> http://mason.gmu.edu/~smetz3 > >>> > >>> ________________________________________ > >>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > >>> behalf of Ray Overby <rayove...@comcast.net> > >>> Sent: Wednesday, May 29, 2019 11:11 AM > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > >>> > >>> In response to "Mistakes, lack of time, lack of control, lack of > skills. > >>> Not a platform weakness." comment: The mainframe platform, z/OS, and > >>> ESM's all rely on integrity to function. A single TRAP DOOR code > >>> vulnerability pierces the veil of integrity and can be used to > >>> compromise the mainframe. Is this a platform weakness? I think so. > >>> The platform relies on all code it runs adhering to certain rules. > >>> z/OS could be changed to better check and enforce those rules. > >>> > >>> Would you say that the elimination of User Key Common storage is an > >>> example of a z/OS change to address a mainframe platform weakness? I > >>> think so. > >>> > >>> An interesting observation. Thanks. > >>> > >>> On 5/29/2019 5:25 AM, R.S. wrote: > >>>> That's classical FUD. > >>>> Frightening people. > >>>> "if an exploit", "if job reads you RACF db", "unintended > consequences". > >>>> What exactly hacking scenario can provide RACF db to the hacker? > >>>> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO > >>>> user attribute, even UPDATE to RACF db. But it's problem of people. > >>>> Mistakes, lack of time, lack of control, lack of skills. Not a > >>>> platform weakness. > >>>> > >>>> It's typical that assurance/lock/gun salesmen tend to talk about > >>>> risks, threats and dangers. They create a vision. > >>>> My English is poor, but I can observe it for two of debaters here. > >>>> It's visible. I don't like social engineering. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
