It's conceivable, but I doubt it. As best I can tell it's just a question of talking a cross purposes, not deliberate obfuscation.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Bill Johnson <00000047540adefe-dmarc-requ...@listserv.ua.edu> Sent: Sunday, June 2, 2019 5:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls He’s trying to sell his company’s security services. Something I thought was not allowed on this list. Sent from Yahoo Mail for iPhone On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz <sme...@gmu.edu> wrote: > * As part of a APF authorized product there is a SVC or PC routine > that when called will turn on the JSBCAUTH bit Ouch! If it's APF authorized then why does it need to do that? And why would you allow such a vendor in the door? Did you have a tool that discovered that the vendor's SVC turned on JSCBAUTH, or did you have to read the code like the rest of us? -- 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: Friday, May 31, 2019 7:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Just how secure are mainframes? | Trevor Eddolls 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/1BhyjzGqq-589SlBQUb-IjJHHzwIrML_B3lxKqhUQGJUC3yoKaSXPASAjq408wXgHywuYnvh7nPmBEB8x9qeYTgkxsSPN0bNeQxHGTSJWT0rk5nVeYa_8emn94gln-C8ySnLBRQeWLZ_qOBqZkUTNLEAPtouZbZnym6YMqkcESxj3O8qFeA9Bpkk9VT8fPanX9_g_-uUniPy_oTilATJ4ZKgSv_cyg5IwH2jjpdLz9QUfhRWm-oaoUPCo28bfcg9hlCABe5muR1Y54CCiqwQD5dpSQe5XOOFUkUNFH85Shio44z6j2rrox7vuuIkx4qqEKW9l5JntIrQ2lYRpxCL7fm_DFgt1kxSE0rllIwhFqv1LC5ikE1Jk4JtFm0jTuu8X/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFriedrich_Schiller > https://secure-web.cisco.com/1JHQ5Q4uULSamxoCJBM5KqCgBYdAruW165Hn4Xd1Y4QQTSHehJj4Jwe6zJ3FES0pzkdssOb2l3YUKZIltYyzt6L6QwhR7I-bhe6I2XqEnHTVM5Qd6fKFCj8-5HL_2A1q0sO7Ux3S8rR1ki1upOlLLjwBz3HXkzkTTnYEI4hEZEepa6jj_wXwLMw_bbeZtUwCDJOGH892uh4AYyYjj2M9CLH6VzxoPAFdteTqkNYoR8KiZzbkKHgZdvcOkVMM8O2q2ukcBWOc7wp-Typ2YOqAoU8-DSq7RTrcwV2w-jA8CZ24UhcH4pBUYmFY-f5A1LL2bWBwKcCfl4KKoWz5-g_ksqf1OgjAfWeRu-2ubQVVgbS32TYwgCl2q_FtDMVbOPsMR/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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
