I do? You must be joking. The thread is monopolized by one person. You know who.
ITschak בתאריך יום ב׳, 3 ביוני 2019, 0:47, מאת Bill Johnson < 00000047540adefe-dmarc-requ...@listserv.ua.edu>: > 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
