Sory to inform you: there are such SVCs available for download. I think there is one on the cbttape .
בתאריך יום א׳, 2 ביוני 2019, 22:33, מאת Seymour J Metz <[email protected]>: > > 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 <[email protected]> on behalf > of ITschak Mugzach <[email protected]> > Sent: Saturday, June 1, 2019 2:42 AM > To: [email protected] > 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 <[email protected]>: > > > 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 <[email protected]> on > > behalf of Jesse 1 Robinson <[email protected]> > > > Sent: Thursday, May 30, 2019 5:48 PM > > > To: [email protected] > > > 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 > > > [email protected] > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List <[email protected]> On > > Behalf Of Ray Overby > > > Sent: Thursday, May 30, 2019 11:45 AM > > > To: [email protected] > > > 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 <[email protected]> on > > >> behalf of Ray Overby <[email protected]> > > >> Sent: Thursday, May 30, 2019 7:28 AM > > >> To: [email protected] > > >> 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 <[email protected]> on > > >>> behalf of Ray Overby <[email protected]> > > >>> Sent: Wednesday, May 29, 2019 11:11 AM > > >>> To: [email protected] > > >>> 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 [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 > > > > ---------------------------------------------------------------------- > > 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 > > > ---------------------------------------------------------------------- > 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
