> 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://en.wikipedia.org/wiki/Friedrich_Schiller https://en.wikipedia.org/wiki/The_Maid_of_Orleans_(play) > * 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
