Seymour,
A specific example would help with this discussion. Do you have one?
I will use a TSO ISPF application as my example. The assumption is that
application security code is PSW KEY 8 problem state code (just like the
application code). In fact, it could be CLIST or REXX execs as well.
* The following ways to frontend the application programs (lmods or
clist or rexx):
o TSO has TSOLIB command. I could add a non-apf DSN to STEPLIB so
that when the application programs are fetched they will pick up
my version of the program instead of the applications.
o ISPF supports a TASKLIB call ISPLLIB. I could add my non-apf DSN
to ISPLLIB so that when the application programs are fetched
they will pick up my version of the program instead of the
applications.
o ISPF supports LIBDEF. I could use LIBDEF to add my non-apf DSN
so that when the application programs are fetched they will pick
up my version of the program instead of the applications.
o TSO has ALTLIB command. I could add my CLIST library to SYSPROC
so that when the application clists (or rexx) are fetched they
will pick up my version of the program instead of the applications
I have identified some (but not all) of the available ways to frontend
application programs in a TSO/E environment. If I frontend the security
module (whether I replace it or copy it and zap off the stuff I don't
want) does not matter - I will be able to bypass the "so called"
security controls. If this was a common criteria evaluation for the
application I would not even have to create an exploit. I would just
have to document that the security is implemented in the application
layer - therefore is it always vulnerable.
The TSO user would need access to the data as the security calls would
probably be performed with the TSO users credentials. More details about
the TSO/E ISPF application would be required to do further analysis.
If you were referring to CICS as the application to logon to I am not as
familiar with this environment. It would appear that there are not as
many options for module frontending here. Can CICS users edit a file,
type in a rexx exec which uses the REXX STORAGE function and execute the
rexx exec? If so they may be able to start zapping the CICS region
private area. This may or more not include the CICS transaction
programs. I will have to try this to see what I can do ;-) The CICS user
may be able to logon to TSO to create the rexx exec. And then execute it
from CICS. I will give this a try.
in 5/31/2019 1:33 PM, Seymour J Metz wrote:
A user who front-ends an application is running with his own credentials; he
doesn't have access to the production data. A user who simply logs on to the
application canfront-end it.
--
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 2:44 PM
To: [email protected]
Subject: 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
