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://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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
