subject:"Program FLIH backdoor \- This is a criminal breach of security\!"

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-13 Thread Shmuel Metz (Seymour J.)

In
,
on 03/12/2012
   at 02:52 PM, Peter Relson  said:

>The authorized code must be written to prevent such exposures.

What does IGX00011 do and what are the safeguards?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-12 Thread Peter Relson

Some of the integrity examples have been tripping a bit over trying to 
define system integrity in terms of the behavior of authorized programs, 
when the statement is in terms of what an unauthorized program must not be 
allowed to do.

For the PC FLIH intercept case, the requirement is that a malicious user 
must not be able to take advantage of this mechanism in order to get their 
own code running authorized.

For the fetch-protection case, the requirement is that a malicious user 
must not be able to trick a service into copying arbitrary fetch protected 
system key storage into non-fetch protected storage viewable by the 
unauthorized caller.

The authorized code must be written to prevent such exposures.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-12 Thread Chris Craddock

On Sun, Mar 11, 2012 at 8:07 AM, John Gilmore wrote:

> Since this sort of thing is expected of me, I will note that we find
> ourselves between Scylla and Charybdis here.
>
> Chris Craddock's formulation was open to the exception that Peter
> Relson took: there is fetch-protected storage the contents of which
> its owner is entirely free to make available to others.
>
> Peter's exception is logically impeccable.  It did, however, seem to
> me to be a very special one; and I observed that it was.  I still
> prefer the ROT that the contents of protected storage should not be
> made available to the unauthorized (in any but very special
> circumstances, when they are known procedurally to be innocuous.).
>
> To repeat myself now, Peter is nonetheless correct in the abstract.
> There is a long intellectual tradition which has it that the
> production of just one black swan is an unanswerable refutation of the
> proposition that all swans are white.

I can't quibble with Peter's exception. I was evidently not sufficiently
clear. I had assumed it was self-evident to everyone that a privileged
program is free to do what ever it wants with the contents of its own
storage - including both disclosing and/or modifying that data - regardless
of fetch protection. I was merely pointing out to a prior poster that a
privileged program is required to honor key controlled protection in
general and meeting that requirement is more rigorous than just not
mindlessly storing in areas provided by a caller (regardless of the
caller's key).

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-11 Thread John Gilmore

Swans, white and black, have a long history in scholastic and then
mathematical logic, figuring too frequently in illustrations of modus
ponens:

All swans are white.  A is a swan.  Ergo, A is white.

The heavy, unquestioning use of this scheme presumably reflects the
fact that northern hemisphere swans, European and Japanese swans in
particular, were/are white.

All this changed when the southern hemisphere, Australian and New
Zealand, black swan, Cygnus atratus, was discovered in the late 18th
century.

"Black swan" then came to have another, quite different connotation.
It is used to describe putatively rare things when they are in fact
found and sometimes even to derogate rareness, as in the recent heavy
use of variants of

Unscrupulous, greedy bankers are not black swans.

Produce is used in logic as shorthand for provide an instance of in
the sense of the existential quantifier, assert or show there is at
least one S such that S is an x.

Obtusely, I had not thought about the 'production of a black swan' in
its other, literal or Marxist economic sense, accomplished say by
painting a white swan black; but I agree that the idea is repellent.
(We again have a significant, growing population of white swan pairs
resident throughout the year in our glacial ponds/reservoirs here in
Massachusetts west of Boston.  They are very tolerant of people, and I
should not want to see that change.)

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-11 Thread Gerhard Postpischil


On 3/11/2012 9:07 AM, John Gilmore wrote:

There is a long intellectual tradition which has it that the
production of just one black swan is an unanswerable refutation of the
proposition that all swans are white.


I cringe at the word "production" - purportedly (google search 
came up empty) not too long ago in our nation's history it was 
common practice to paint sparrows for the purpose of selling 
them as parakeets.


While I don't recall a proposition on swans, I was reminded of 
the Pejorative Calculus (Joel Cohen, "On The Nature Of 
Mathematical Proofs", The Worm-Runner's Digest, Vol. III, No.3, 
December 1961), where Lemma I (all horses are the same color) is 
credited to Professor Lee M. Sonneborn, then at U. of Kansas.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-11 Thread John Gilmore

Since this sort of thing is expected of me, I will note that we find
ourselves between Scylla and Charybdis here.

Chris Craddock's formulation was open to the exception that Peter
Relson took: there is fetch-protected storage the contents of which
its owner is entirely free to make available to others.

Peter's exception is logically impeccable.  It did, however, seem to
me to be a very special one; and I observed that it was.  I still
prefer the ROT that the contents of protected storage should not be
made available to the unauthorized (in any but very special
circumstances, when they are known procedurally to be innocuous.).

To repeat myself now, Peter is nonetheless correct in the abstract.
There is a long intellectual tradition which has it that the
production of just one black swan is an unanswerable refutation of the
proposition that all swans are white.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-11 Thread Peter Relson

>this is true, but it is not interesting.
(with respect to my pointing out some flaws in the examples)

I respectfully disagree.

When something is presented as a guideline or even perhaps a "rule of 
thumb", that is one thing.
When something is presented as a rule, that is a different thing.

If it is stated that "x is true" when it is not, that ought to be 
challenged.
I believe that that is where the examples fell.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-10 Thread John Gilmore

In response to Chris Craddock's stricture about the disclosure of the
contents of fetch-protected storage Peter Relson wrote


This is not necessarily a violation of the IBM statement of integrity.
 It depends on whose data is being copied. I am allowed to put my own
non-sensitive data into fetch-protected storage and copy it to
non-fetch protected storage if I so choose. The requirement is that I
not allow the unauthorized user to access something he should not be
given access to. Fetch protection is just one tool in the bag of
tricks.  The owner of the data is typically the one that decides what
the access limitations are to be.


To borrow one of Chomsky's distinctions, this is true, but it is not
interesting.
I may of course do anything I like with something I myself put into
fetch-protected storage.  Moreover, I can know, locally and
procedurally, when I can do so; but most of the time I am dealing with
someone else's fetch-protected storage; and for it the only proper
rule is non-disclosure to the unauthorized.

An exact, entirely correct description of every action that
constitutes a breach of integrity at some time T may just be
achievable; but if it is achieved it will be obsolescent when it is
achieved; and it will resemble a contract drawn up by an attorney not
to inform but to protect a client from hostile litigation.  It will
not, that is, be at all helpful or even intelligible to any but the
already well-informed.

Integrity remains a crucial goal.  Practices that clearly put it at
risk must be avoided, and breaches must be closed as they are
detected.  (Disagreeable as this sounds, 1) we now learn chiefly from
these breaches; and 2) there will be more of them.)

ROTs simplify reality, and they thus always entail overkill, but they
are useful to people who lack the experience to make subtle
distinctions.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-10 Thread Peter Relson

I apologize in advance to Karl Schmitz if I have a bit of this
not quite exact.

>Perhaps some Integrity Vulnerability examples will help clarify:
>
>1)If your authorized program while executing in PSW key 0-7 stores 
>into an address provided by an unauthorized caller then this is a 
>violation of the IBM statement of integrity. 

The use of PSW key is imprecise. It's really "while not using the user's 
key, whether by that being the PSW key or by using MVCK/MVCDK/MVCSK/etc.".
But, more important, the (corrected) statement applies both to 
stores into and fetches from an address. Not just stores. Still, with
the exception that if the address has been validated to be a block
that the authorized program owns and that cannot change attributes while
mid-stream and that is known not to be fetch-protected, maybe. 
There are any number of cases where unauthorized "input" identifies a 
system-key system block (which is verified as being a system block) and 
that block gets updated as a result of a service call by the system 
running in system key.

>3)If your authorized program while executing in PSW Key 0-7 or 
>supervisor state returns control to an unauthorized requester in an 
>authorized state then this is a violation of the IBM statement of 
>Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or 
>now has the ability to MODESET. 

You really also need to add "unintended" if "unauthorized" refers only to
key, state, and APF. This is allowed as long as it is done 
correctly, which includes limiting it to only the 
intended requestor(s). Getting that correct is the difficult part. 
And of course that's at heart of this whole thread. Whether done by
a PC FLIH intercept returning via LPSW(E), or an SVC routine manipulating 
the RB,
or a stacking PC manipulating the linkage stack, the concept is the same.

>4)If your authorized program while executing in PSW Key 0-7 copies 
>fetch protected storage to non-fetch protected storage then this is a 
>violation of the IBM statement of integrity. 

This is not necessarily a violation of the IBM statement of integrity. 
It depends on whose data is being copied. I am allowed to put my own
non-sensitive data into fetch-protected storage and copy it to
non-fetch protected storage if I so choose. The requirement is that I not
allow the unauthorized user to access something he should not be given
access to. Fetch protection is just one tool in the bag of tricks.
The owner of the data is typically the one that decides what the access
limitations are to be.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-09 Thread Chris Craddock

On Mar 8, 2012, at 1:15 PM, Ray Overby  wrote:

> Rob - How about: If your authorized program while executing in PSW Key 0-7 
> stores into an address provided by an unauthorized caller (as long as the 
> store operation uses the execution PSW KEY) then this is a violation of the 
> IBM statement of integrity.

Not necessarily. The integrity statement would only be violated if the 
privileged program allowed the non-privileged program to circumvent key 
controlled access. To prevent this, the privileged program must use the 
non-privileged program's PSW key when passing any results back in areas 
provider by the caller (e.g. By using MVCDK and the caller's key) - however, 
the privileged program must also ensure that it does not inadvertently disclose 
the contents of fetch protected storage, regardless of how it moves the results 
back to the caller. 

In the latter case a black hat might cleverly cause a malformed privileged 
program to copy (say) contents of key zero fetch protected storage into plain 
old user key storage where the black hat could inspect it to his heart's 
content. 

So bottom line: using the caller's key to return results is a necessary, but 
not sufficient condition to maintain integrity. 

CC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-09 Thread Shmuel Metz (Seymour J.)

In <4f58fe65.7030...@kr-inc.com>, on 03/08/2012
   at 12:45 PM, Ray Overby  said:

>1)If your authorized program while executing in PSW key 0-7
>stores into an address provided by an unauthorized caller then 
>this is a violation of the IBM statement of integrity.

MVCDK
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Rob Scott

How about :

"If your authorized program, while executing in PSW key 0-7 stores into an 
address provided by an unauthorized caller without using the caller's key then 
this is a violation of the IBM statement of integrity"

I am sure there are other people on IBM-Main who could make this more readable 
and accurate.

Truth is that there are lots programs out there (public domain, in-house 
utilities) that just splat into caller storage using Key0 regardless of caller 
key.

A good example of how to do it properly in "Authorized Assembler Programming 
Guide" would be my preferred start for re-education of the masses.

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ray Overby
Sent: 08 March 2012 19:15
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!

Rob - How about: If your authorized program while executing in PSW Key
0-7 stores into an address provided by an unauthorized caller (as long as the 
store operation uses the execution PSW KEY) then this is a violation of the IBM 
statement of integrity.

Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM) www.zassure.com
(312)574-0007


On 3/8/2012 13:02 PM, Rob Scott wrote:
>> 1)If your authorized program while executing in PSW key 0-7 stores
> into an address provided by an unauthorized caller then this is a violation 
> of the IBM statement of integrity.
>
> Sorry - I disagree with this.
>
> It is quite OK for auth routines (eg PC-ss) to store into storage whose 
> address is provided by the caller *AS LONG AS THE CALLER'S KEY IS USED* when 
> moving the data.
>
> See the MVCDK instruction.
>
> Likewise any authorized routine should treat caller provided storage with 
> suspicion and use MVCSK to copy any data from the caller and use trusted 
> control block pointers rather than rely on caller contents.
>
>
> Rob Scott
> Lead Developer
> Rocket Software
> 275 Grove Street * Newton, MA 02466-2272 * USA
> Tel: +1.781.684.2305
> Email: rsc...@rs.com
> Web: www.rocketsoftware.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
> Behalf Of Ray Overby
> Sent: 08 March 2012 18:46
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Program FLIH backdoor - This is a criminal breach of security!
>
> Charles - yes, it is somewhat ambiguous what "violation of the IBM statement 
> of integrity" means. Perhaps some Integrity Vulnerability examples will help 
> clarify:
>
> 1)If your authorized program while executing in PSW key 0-7 stores
> into an address provided by an unauthorized caller then this is a violation 
> of the IBM statement of integrity.
>
> 2)If your authorized program while executing in PSW Key 0-7 or
> supervisor state branches to an address provided by an unauthorized requester 
> then this is a violation of the IBM statement of Integrity.
>
> 3)If your authorized program while executing in PSW Key 0-7 or
> supervisor state returns control to an unauthorized requester in an 
> authorized state then this is a violation of the IBM statement of Integrity. 
> By authorized state I mean PSW Key 0-7, Supervisor state, or now has the 
> ability to MODESET.
>
> 4)If your authorized program while executing in PSW Key 0-7 copies
> fetch protected storage to non-fetch protected storage then this is a 
> violation of the IBM statement of integrity.
>
> The "unauthorized requester" in these case's would be any PSW Key 8 problem 
> state program that is not currently enabled to MODESET prior to issuing a 
> request to an authorized service. After the request completes the program now 
> has new capabilities that were not available prior to the request such as:
>
> -The program could now be in an authorized state (psw key 0-7 or
> supervisor state)
> -The program could now have the ability to MODESET
> -The security credentials may have been dynamically elevated (i.e. -
> I now have RACF privileged attribute which I did not have before)
> -Some code provided by my program could have been executed in an
> authorized state (PSW Key 0-7 or Supervisor state).
>
> If you examine the before and after state around the invoking of the 
> authorized service you generally see some form of elevated capabilities when 
> a violation of the IBM statement of integrity occurs.
>
> Ray Overby
> Key Resources, Inc.
> Ensuring System Integrity for z/Series^(TM) www.zassure.com
> (312)574-0007
>
>
>
> On 3/8/2012 11:20 AM, Ch

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Ray Overby

Rob - How about: If your authorized program while executing in PSW Key 
0-7 stores into an address provided by an unauthorized caller (as long 
as the store operation uses the execution PSW KEY) then this is a 
violation of the IBM statement of integrity.


Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007


On 3/8/2012 13:02 PM, Rob Scott wrote:

1)If your authorized program while executing in PSW key 0-7 stores

into an address provided by an unauthorized caller then this is a violation of 
the IBM statement of integrity.

Sorry - I disagree with this.

It is quite OK for auth routines (eg PC-ss) to store into storage whose address 
is provided by the caller *AS LONG AS THE CALLER'S KEY IS USED* when moving the 
data.

See the MVCDK instruction.

Likewise any authorized routine should treat caller provided storage with 
suspicion and use MVCSK to copy any data from the caller and use trusted 
control block pointers rather than rely on caller contents.


Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ray Overby
Sent: 08 March 2012 18:46
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!

Charles - yes, it is somewhat ambiguous what "violation of the IBM statement of 
integrity" means. Perhaps some Integrity Vulnerability examples will help clarify:

1)If your authorized program while executing in PSW key 0-7 stores
into an address provided by an unauthorized caller then this is a violation of 
the IBM statement of integrity.

2)If your authorized program while executing in PSW Key 0-7 or
supervisor state branches to an address provided by an unauthorized requester 
then this is a violation of the IBM statement of Integrity.

3)If your authorized program while executing in PSW Key 0-7 or
supervisor state returns control to an unauthorized requester in an authorized 
state then this is a violation of the IBM statement of Integrity. By authorized 
state I mean PSW Key 0-7, Supervisor state, or now has the ability to MODESET.

4)If your authorized program while executing in PSW Key 0-7 copies
fetch protected storage to non-fetch protected storage then this is a violation 
of the IBM statement of integrity.

The "unauthorized requester" in these case's would be any PSW Key 8 problem 
state program that is not currently enabled to MODESET prior to issuing a request to an 
authorized service. After the request completes the program now has new capabilities that 
were not available prior to the request such as:

-The program could now be in an authorized state (psw key 0-7 or
supervisor state)
-The program could now have the ability to MODESET
-The security credentials may have been dynamically elevated (i.e. -
I now have RACF privileged attribute which I did not have before)
-Some code provided by my program could have been executed in an
authorized state (PSW Key 0-7 or Supervisor state).

If you examine the before and after state around the invoking of the authorized 
service you generally see some form of elevated capabilities when a violation 
of the IBM statement of integrity occurs.

Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM) www.zassure.com
(312)574-0007



On 3/8/2012 11:20 AM, Charles Mills wrote:

I will give it one more shot at trying to clarify what I mean.

Witness this thread, reasonable people can disagree on what "violates
the statement of integrity" means. One person's reasonable or only
available technique is another person's violation.

We could use some finer granularity. We could use a standard statement
of "does X but does not do Y."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Ray Overby
Sent: Thursday, March 08, 2012 8:45 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!

The IBM statement of Integrity or its equivalent is a standard that
all authorized programs should conform with. See IBM statement of
Integrity
<http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_st
atemen
t.html>.
If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide:
21.1.2
<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2?
ACTION=MATCHES&REQUEST=system+integrity&TYPE=FUZZY&SHELF=EZ2ZBK0K&DT=2
010062
9141054&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank
=RANK&
ScrollTOP=FIRSTHIT#FIRSTHIT>/you/
will see that IBM puts the responsibility on the installation for
ensuring the integrity (i.e. - conforms to the IBM statement of
Integ

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Rob Scott

>1)If your authorized program while executing in PSW key 0-7 stores 
into an address provided by an unauthorized caller then this is a violation of 
the IBM statement of integrity.

Sorry - I disagree with this.

It is quite OK for auth routines (eg PC-ss) to store into storage whose address 
is provided by the caller *AS LONG AS THE CALLER'S KEY IS USED* when moving the 
data. 

See the MVCDK instruction.

Likewise any authorized routine should treat caller provided storage with 
suspicion and use MVCSK to copy any data from the caller and use trusted 
control block pointers rather than rely on caller contents.

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ray Overby
Sent: 08 March 2012 18:46
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!

Charles - yes, it is somewhat ambiguous what "violation of the IBM statement of 
integrity" means. Perhaps some Integrity Vulnerability examples will help 
clarify:

1)If your authorized program while executing in PSW key 0-7 stores 
into an address provided by an unauthorized caller then this is a violation of 
the IBM statement of integrity.

2)If your authorized program while executing in PSW Key 0-7 or 
supervisor state branches to an address provided by an unauthorized requester 
then this is a violation of the IBM statement of Integrity.

3)If your authorized program while executing in PSW Key 0-7 or 
supervisor state returns control to an unauthorized requester in an authorized 
state then this is a violation of the IBM statement of Integrity. By authorized 
state I mean PSW Key 0-7, Supervisor state, or now has the ability to MODESET.

4)If your authorized program while executing in PSW Key 0-7 copies 
fetch protected storage to non-fetch protected storage then this is a violation 
of the IBM statement of integrity.

The "unauthorized requester" in these case's would be any PSW Key 8 problem 
state program that is not currently enabled to MODESET prior to issuing a 
request to an authorized service. After the request completes the program now 
has new capabilities that were not available prior to the request such as:

-The program could now be in an authorized state (psw key 0-7 or 
supervisor state)
-The program could now have the ability to MODESET
-The security credentials may have been dynamically elevated (i.e. - 
I now have RACF privileged attribute which I did not have before)
-Some code provided by my program could have been executed in an 
authorized state (PSW Key 0-7 or Supervisor state).

If you examine the before and after state around the invoking of the authorized 
service you generally see some form of elevated capabilities when a violation 
of the IBM statement of integrity occurs.

Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM) www.zassure.com
(312)574-0007

On 3/8/2012 11:20 AM, Charles Mills wrote:
> I will give it one more shot at trying to clarify what I mean.
>
> Witness this thread, reasonable people can disagree on what "violates 
> the statement of integrity" means. One person's reasonable or only 
> available technique is another person's violation.
>
> We could use some finer granularity. We could use a standard statement 
> of "does X but does not do Y."
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
> Behalf Of Ray Overby
> Sent: Thursday, March 08, 2012 8:45 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Program FLIH backdoor - This is a criminal breach of security!
>
> The IBM statement of Integrity or its equivalent is a standard that 
> all authorized programs should conform with. See IBM statement of 
> Integrity 
> <http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_st
> atemen
> t.html>.
> If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide:
> 21.1.2
> <http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2?
> ACTION=MATCHES&REQUEST=system+integrity&TYPE=FUZZY&SHELF=EZ2ZBK0K&DT=2
> 010062 
> 9141054&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank
> =RANK&
> ScrollTOP=FIRSTHIT#FIRSTHIT>/you/
> will see that IBM puts the responsibility on the installation for 
> ensuring the integrity (i.e. - conforms to the IBM statement of
> Integrity) for any modifications or extensions to z/OS the 
> installation makes. This would include any authorized code 
> written/installed by the i

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Ray Overby

Charles - yes, it is somewhat ambiguous what "violation of the IBM 
statement of integrity" means. Perhaps some Integrity Vulnerability 
examples will help clarify:


1)If your authorized program while executing in PSW key 0-7 stores 
into an address provided by an unauthorized caller then this is a 
violation of the IBM statement of integrity.


2)If your authorized program while executing in PSW Key 0-7 or 
supervisor state branches to an address provided by an unauthorized 
requester then this is a violation of the IBM statement of Integrity.


3)If your authorized program while executing in PSW Key 0-7 or 
supervisor state returns control to an unauthorized requester in an 
authorized state then this is a violation of the IBM statement of 
Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or 
now has the ability to MODESET.


4)If your authorized program while executing in PSW Key 0-7 copies 
fetch protected storage to non-fetch protected storage then this is a 
violation of the IBM statement of integrity.


The "unauthorized requester" in these case's would be any PSW Key 8 
problem state program that is not currently enabled to MODESET prior to 
issuing a request to an authorized service. After the request completes 
the program now has new capabilities that were not available prior to 
the request such as:


-The program could now be in an authorized state (psw key 0-7 or 
supervisor state)

-The program could now have the ability to MODESET
-The security credentials may have been dynamically elevated (i.e. - 
I now have RACF privileged attribute which I did not have before)
-Some code provided by my program could have been executed in an 
authorized state (PSW Key 0-7 or Supervisor state).


If you examine the before and after state around the invoking of the 
authorized service you generally see some form of elevated capabilities 
when a violation of the IBM statement of integrity occurs.


Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007



On 3/8/2012 11:20 AM, Charles Mills wrote:

I will give it one more shot at trying to clarify what I mean.

Witness this thread, reasonable people can disagree on what "violates the
statement of integrity" means. One person's reasonable or only available
technique is another person's violation.

We could use some finer granularity. We could use a standard statement of
"does X but does not do Y."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Ray Overby
Sent: Thursday, March 08, 2012 8:45 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!

The IBM statement of Integrity or its equivalent is a standard that all
authorized programs should conform with. See IBM statement of Integrity
<http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statemen
t.html>.
If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide:
21.1.2
<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2?
ACTION=MATCHES&REQUEST=system+integrity&TYPE=FUZZY&SHELF=EZ2ZBK0K&DT=2010062
9141054&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&
ScrollTOP=FIRSTHIT#FIRSTHIT>/you/
will see that IBM puts the responsibility on the installation for
ensuring the integrity (i.e. - conforms to the IBM statement of
Integrity) for any modifications or extensions to z/OS the installation
makes. This would include any authorized code written/installed by the
installation as well as any authorized code installed that is from ISVs.

If the backdoor, intercept, or other authorized program violates the IBM
statement of integrity then it is a problem that needs to be remediated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Charles Mills

I will give it one more shot at trying to clarify what I mean.

Witness this thread, reasonable people can disagree on what "violates the
statement of integrity" means. One person's reasonable or only available
technique is another person's violation.

We could use some finer granularity. We could use a standard statement of
"does X but does not do Y."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Ray Overby
Sent: Thursday, March 08, 2012 8:45 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!

The IBM statement of Integrity or its equivalent is a standard that all 
authorized programs should conform with. See IBM statement of Integrity 
<http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statemen
t.html>. 
If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide: 
21.1.2 
<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2?
ACTION=MATCHES&REQUEST=system+integrity&TYPE=FUZZY&SHELF=EZ2ZBK0K&DT=2010062
9141054&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&
ScrollTOP=FIRSTHIT#FIRSTHIT>/you/ 
will see that IBM puts the responsibility on the installation for 
ensuring the integrity (i.e. - conforms to the IBM statement of 
Integrity) for any modifications or extensions to z/OS the installation 
makes. This would include any authorized code written/installed by the 
installation as well as any authorized code installed that is from ISVs.

If the backdoor, intercept, or other authorized program violates the IBM 
statement of integrity then it is a problem that needs to be remediated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Ray Overby

The IBM statement of Integrity or its equivalent is a standard that all 
authorized programs should conform with. See IBM statement of Integrity 
<http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statement.html>. 
If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide: 
21.1.2 
<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2?ACTION=MATCHES&REQUEST=system+integrity&TYPE=FUZZY&SHELF=EZ2ZBK0K&DT=20100629141054&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT>/you/ 
will see that IBM puts the responsibility on the installation for 
ensuring the integrity (i.e. - conforms to the IBM statement of 
Integrity) for any modifications or extensions to z/OS the installation 
makes. This would include any authorized code written/installed by the 
installation as well as any authorized code installed that is from ISVs.


If the backdoor, intercept, or other authorized program violates the IBM 
statement of integrity then it is a problem that needs to be remediated.



Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007


On 3/8/2012 08:40 AM, Charles Mills wrote:

an APF authorized program can do that.  It can also create a "backdoor"

(my definition) that

any task in the system can walk through and get into supervisor state.

That is the objection that was raised, and it is a very different matter.

I should be smarter than to wade into this one but is it not true,
unfortunately, that an APF program can do ANYTHING it wants to do? "Doing
anything it wants to do" would include "granting privileges implicitly to
other programs" would it not?

Further, there is no industry agreement -- witness this thread -- on what
constitutes acceptable APF authorized program conduct. My "the only
technique that will work" is someone else's "criminal breach of security."

It seems to me the problem here is, from a technological point of view, the
"all or nothing" nature of APF authorization. IBM is moving away from that
approach, but APF authorization as it is and was is going to be with us for
a long time. From a non-technology point of view, we need some sort of
industry agreement on what is good behavior in an authorized program. I am
thinking of something like a standardized set of questions that a vendor
could answer and have an officer certify: "Mr./Ms. Customer, we are asking
for APF authorization. I certify under penalty of fraud that our program
uses APF authorization to do X, and Y, and Z but does not do A, and B, and
C."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Tom Marchant
Sent: Thursday, March 08, 2012 6:19 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!

On Thu, 8 Mar 2012 13:49:28 +, Pate, Gene wrote:


You have your definition for 'backdoor', I have mine, Next.

That is the root of your confusion.  This thread is about a vendor creating
a backdoor according to my definition.  You are "amazed at the uproar over
this"
because you applied your definition of what a "backdoor"
is without considering the description of what the backdoor was in the
original discussion.


if they were APF authorized then they could by definition switch anyone
or any task in the system to supervisor state

Yes, an APF authorized program can do that.  It can also create a "backdoor"
(my definition) that any task in the system can walk through and get into
supervisor state.  That is the objection that was raised, and it is a very
different matter.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Charles Mills

Not sure I get your drift. I am talking about the problem in the OP, not
about "me," and not about "preventing programs from doing X and Y" but
rather about an agreement about what is legitimate and what is not, or as I
said, one person's "'the only technique that will work' [a phrase one poster
used] is someone else's 'criminal breach of security.'" Failing that, a
formal affirmation of "we do X but we don't do Y."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Edward Jaffe
Sent: Thursday, March 08, 2012 7:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!

On 3/8/2012 6:40 AM, Charles Mills wrote:
> From a non-technology point of view, we need some sort of industry 
> agreement on what is good behavior in an authorized program. I am 
> thinking of something like a standardized set of questions that a 
> vendor could answer and have an officer certify: "Mr./Ms. Customer, we 
> are asking for APF authorization. I certify under penalty of fraud 
> that our program uses APF authorization to do X, and Y, and Z but does not
do A, and B, and C."

You have no integrity statement?? Wow! You might consider drafting one...

Here is IBM's you can use as a template: 
http://www.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statement.ht
ml

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Edward Jaffe


On 3/8/2012 6:40 AM, Charles Mills wrote:
From a non-technology point of view, we need some sort of industry agreement 
on what is good behavior in an authorized program. I am thinking of something 
like a standardized set of questions that a vendor could answer and have an 
officer certify: "Mr./Ms. Customer, we are asking for APF authorization. I 
certify under penalty of fraud that our program uses APF authorization to do 
X, and Y, and Z but does not do A, and B, and C."


You have no integrity statement?? Wow! You might consider drafting one...

Here is IBM's you can use as a template: 
http://www.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statement.html


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Charles Mills

> an APF authorized program can do that.  It can also create a "backdoor"
(my definition) that 
> any task in the system can walk through and get into supervisor state.
That is the objection that was raised, and it is a very different matter.

I should be smarter than to wade into this one but is it not true,
unfortunately, that an APF program can do ANYTHING it wants to do? "Doing
anything it wants to do" would include "granting privileges implicitly to
other programs" would it not?

Further, there is no industry agreement -- witness this thread -- on what
constitutes acceptable APF authorized program conduct. My "the only
technique that will work" is someone else's "criminal breach of security."

It seems to me the problem here is, from a technological point of view, the
"all or nothing" nature of APF authorization. IBM is moving away from that
approach, but APF authorization as it is and was is going to be with us for
a long time. From a non-technology point of view, we need some sort of
industry agreement on what is good behavior in an authorized program. I am
thinking of something like a standardized set of questions that a vendor
could answer and have an officer certify: "Mr./Ms. Customer, we are asking
for APF authorization. I certify under penalty of fraud that our program
uses APF authorization to do X, and Y, and Z but does not do A, and B, and
C."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Tom Marchant
Sent: Thursday, March 08, 2012 6:19 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!

On Thu, 8 Mar 2012 13:49:28 +, Pate, Gene wrote:

>You have your definition for 'backdoor', I have mine, Next.

That is the root of your confusion.  This thread is about a vendor creating
a backdoor according to my definition.  You are "amazed at the uproar over
this" 
because you applied your definition of what a "backdoor" 
is without considering the description of what the backdoor was in the
original discussion.

>if they were APF authorized then they could by definition switch anyone 
>or any task in the system to supervisor state

Yes, an APF authorized program can do that.  It can also create a "backdoor"
(my definition) that any task in the system can walk through and get into
supervisor state.  That is the objection that was raised, and it is a very
different matter.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Tom Marchant

On Thu, 8 Mar 2012 13:49:28 +, Pate, Gene wrote:

>You have your definition for 'backdoor', I have mine, Next.

That is the root of your confusion.  This thread is 
about a vendor creating a backdoor according to my 
definition.  You are "amazed at the uproar over this" 
because you applied your definition of what a "backdoor" 
is without considering the description of what the 
backdoor was in the original discussion.

>if they were APF authorized then they could
>by definition switch anyone or any task in the 
>system to supervisor state 

Yes, an APF authorized program can do that.  It can 
also create a "backdoor" (my definition) that any 
task in the system can walk through and get into 
supervisor state.  That is the objection that was 
raised, and it is a very different matter.

Since your definition of a "backdoor" is simply an 
intercept of a system routine, what would you call 
it when an authorized program creates an interface 
that any program can use to put itself into 
supervisor state?

>Now if they did this magic and they were NOT APF 
>authorized, then we have a lot to talk about here.

Of course they were authorized to be able 
to install their intercept

>I have not seen the vendor code and cannot 
>comment on what it does or does not do or
>how much security checking it does or does 
>not perform before it does what it does.

That was Ed's point too.  Neither have I and 
it's the reason I said "alleged".

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-08 Thread Pate, Gene

On Tue, 6 Mar 2012 15:40:25 -0600, Tom Marchant wrote:

>>By PCFLIH backdoor I mean a routine whose address 
>>replaced the address of the IBM supplied PCFLIH.

>That would be a hook or an intercept.
>"Backdoor" means something else entirely.

You have your definition for 'backdoor', I have mine, Next.

>>The backdoor routine received control every time a 
>>PC interrupt

>ITYM a program interruption.

Yes.

>That is certainly not what the vendor routine being 
>discussed is alleged to have done.  It is alleged to 
>return to the program that was interrupted in supervisor 
>state.  It is further alleged that it is relatively easy for 
>any program to exploit this and to get put into 
>supervisor state.

I keep seeing that 'alleged' word.  Doesn't anyone actually know what they 
did/do, and how did 
they do this magic without being APF authorized, and if they were APF 
authorized then they could
by definition switch anyone or any task in the system to supervisor state so 
what does it matter at that 
point anyway; the battle is lost, get out your white flags and start waving.

Now if they did this magic and they were NOT APF authorized, then we have a lot 
to talk about here.

I have not seen the vendor code and cannot comment on what it does or does not 
do or 
how much security checking it does or does not perform before it does what it 
does. 

My defense was of the use of the technique of 'backdooring, hooking, 
intercepting, 
or whatever word you choose to use in whatever language you choose to use' when 
it is
the appropriate technique. I would really hate to see IBM use this discussion 
as a justification for somehow
making it impossible for a sharp systems programmer or vendor to use this 
technique when there are
times that it is the only technique that will work. I guess it was that 
'criminal' word in the subject line that set me off.

As for what the vendor did, I am not offering any justification and if what you 
would like to
organize with this discussion is a party where we all get together a roast a 
few vendors I will not only
volunteer to bring some firewood I will also invite my CA and IBM marketing 
reps to come with me to the party!   

Gene Pate
CSX Technology
Enterprise Architecture

-
This email transmission and any accompanying attachments may
contain CSX privileged and confidential information intended only
for the use of the intended addressee.  Any dissemination,
distribution, copying or action taken in reliance on the contents
of this email by anyone other than the intended recipient is
strictly prohibited.  If you have received this email in error
please immediately delete it and  notify sender at the above CSX
email address.  Sender and CSX accept no liability for any damage
caused directly or indirectly by receipt of this email.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-06 Thread Shmuel Metz (Seymour J.)

In <4f5638d5.6050...@phoenixsoftware.com>, on 03/06/2012
   at 08:18 AM, Edward Jaffe  said:

>Suffice to say that it does.

Perhaps; I'd have to examine the code to confirm that. Of course, if I
examined the code and found a hole, I wouldn't give the details to
anybody but IBM.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-06 Thread John Gilmore

Edward E. Jaffe wrote:


The above notwithstanding, I don't think anyone at IBM or elsewhere
would recommend this technique for brand new, 21st-century
development.


and I am very pleased to see that this is his view.   My own, slightly
different view of "this interface" is in a certain sense admiring; but
it is also very like my view of Kama Sutra position 327,859: I see
that you can do it that way, but why?

Moreover, as I have had occasion to say here before, its cleverness
seems to me to be misplaced or, better perhaps, too provocative.  It
implicitly poses a challenge of the self-congratulatory form: No
impostor is clever enough to penetrate our defenses!  This is
unfortunate because there are able old-sense hackers who respond only
to such challenges.  (It is a good operational premise to assume,
however improbably, that attackers are as smart as defenders.)

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-06 Thread Edward Jaffe


On 3/6/2012 7:40 AM, Clark Morris wrote:

On 5 Mar 2012 23:38:50 -0800, in bit.listserv.ibm-main you wrote:

To understand what it does study the two trace entries below (GTF is your 
friend):

SVC   CODE 109  ASCB 00F95200 CPU. 
 PSW. 0785 806D  0C53B222
 TCB. 00AC8300 R15. 000B R0.. 
 R1.. 0001
GMT-03/06/2012 06:59:08.693767  LOC-03/05/2012 22:59:08.693767

SVCR  CODE 109  ASCB 00F95200 CPU. 
 PSW. 0714 806D  0C53B222
 TCB. 00AC8300 R15.  R0.. 
 R1.. 0001
GMT-03/06/2012 06:59:08.693799  LOC-03/05/2012 22:59:08.693799

How does the system verify that the caller is the intended caller versus an 
impostor?


Suffice to say that it does. My intent was not to explain the intricacies of 
this interface -- smart programmers can likely figure that out for themselves -- 
but rather to dispel the myth that such interfaces necessarily represent an 
exposure. This is IBM code!!


The above notwithstanding, I don't think anyone at IBM or elsewhere would 
recommend this technique for brand new, 21st-century development. Making it 
secure is a tricky business that requires a deep understanding of system 
internals. There are much better interfaces available to modern developers on 
z/OS that guarantee integrity without having to work so hard.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-06 Thread Shmuel Metz (Seymour J.)

In <4f55be9e.7000...@phoenixsoftware.com>, on 03/05/2012
   at 11:37 PM, Edward Jaffe  said:

>To understand what it does study the two trace entries below (GTF is
>your friend):

That doesn't tell me what happens in between.

>Of course, I meant the intended caller.

Code trumps intention.

>Unintended callers can't successfully use the service.

What stops them.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-06 Thread Clark Morris

On 5 Mar 2012 23:38:50 -0800, in bit.listserv.ibm-main you wrote:

>On 3/5/2012 6:06 PM, Shmuel Metz (Seymour J.) wrote:
>> In<4f540cf5.3080...@phoenixsoftware.com>, on 03/04/2012
>> at 04:46 PM, Edward Jaffe  said:
>>
>>> Look more closely.
>> In the PLM that IBM doesn't publish?
>>
>>
>> Peter? Could you comment on what IGX00011 does?
>
>To understand what it does study the two trace entries below (GTF is your 
>friend):
>
>SVC   CODE 109  ASCB 00F95200 CPU. 
> PSW. 0785 806D  0C53B222
> TCB. 00AC8300 R15. 000B R0.. 
> R1.. 0001
>GMT-03/06/2012 06:59:08.693767  LOC-03/05/2012 22:59:08.693767
>
>SVCR  CODE 109  ASCB 00F95200 CPU. 
> PSW. 0714 806D  0C53B222
> TCB. 00AC8300 R15.  R0.. 
> R1.. 0001
>GMT-03/06/2012 06:59:08.693799  LOC-03/05/2012 22:59:08.693799
>
>> You need to look more closely at IGX00011. Hint: the "secure"
>> implementation is not just in the SVC(ESR) routine itself but also
>> in the caller
>> What caller? It might not be the intended caller.
>
>Of course, I meant the intended caller. Unintended callers can't successfully 
>use the service.

How does the system verify that the caller is the intended caller
versus an impostor?

Clark Morris

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Edward Jaffe


On 3/5/2012 6:06 PM, Shmuel Metz (Seymour J.) wrote:

In<4f540cf5.3080...@phoenixsoftware.com>, on 03/04/2012
at 04:46 PM, Edward Jaffe  said:


Look more closely.

In the PLM that IBM doesn't publish?


Peter? Could you comment on what IGX00011 does?


To understand what it does study the two trace entries below (GTF is your 
friend):

SVC   CODE 109  ASCB 00F95200 CPU. 
PSW. 0785 806D  0C53B222
TCB. 00AC8300 R15. 000B R0.. 
R1.. 0001
   GMT-03/06/2012 06:59:08.693767  LOC-03/05/2012 22:59:08.693767

SVCR  CODE 109  ASCB 00F95200 CPU. 
PSW. 0714 806D  0C53B222
TCB. 00AC8300 R15.  R0.. 
R1.. 0001
   GMT-03/06/2012 06:59:08.693799  LOC-03/05/2012 22:59:08.693799


You need to look more closely at IGX00011. Hint: the "secure"
implementation is not just in the SVC(ESR) routine itself but also
in the caller
What caller? It might not be the intended caller.


Of course, I meant the intended caller. Unintended callers can't successfully 
use the service.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Shmuel Metz (Seymour J.)

In <4f540cf5.3080...@phoenixsoftware.com>, on 03/04/2012
   at 04:46 PM, Edward Jaffe  said:

>Look more closely. 

In the PLM that IBM doesn't publish?


Peter? Could you comment on what IGX00011 does?

>You need to look more closely at IGX00011. Hint: the "secure"
>implementation is not just in the SVC(ESR) routine itself but also
>in the caller

What caller? It might not be the intended caller.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Shmuel Metz (Seymour J.)

In
,
on 03/05/2012
   at 02:19 PM, "Pate, Gene"  said:

>How you allow code to get into supervisor state is of no consequence
>once it is in supervisor state so, unless you have a pristine system
>where every load module library on the system is totally locked down
>and only the OS libraries supplied by IBM appear in the APF list, you
>have by definition accepted exposures to system integrity.

It's not just how but who. Letting trusted code get into supervisor
code is one thing; letting everybody that knows how do it is quite
another.

>Back in the late 70's I wrote a PCFLIH backdoor

What do you mean by backdoor? I don't believe that it is what others
were referring to.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Shmuel Metz (Seymour J.)

In <4f540e03.3070...@phoenixsoftware.com>, on 03/04/2012
   at 04:51 PM, Edward Jaffe  said:

>For the record, I once knew of a developer who claimed to have found
>an MVS back  door because he wanted to appear cool like a phone
>phreaking hacker, but he was  full of B.S. I also know someone that
>actually *did* find a back door (through  an EXCP appendage) and IBM
>closed it.

BTDT,GTTS. I got some flack here because I asked IBM not to include
the details in the public portion of the PMR.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Wayne Driscoll

Gene,
All that an AC=1 module that is in an APF authorized module can do is to 
start running with the JSCBAUTH bit on if, and only if, it is invoked as a 
Job Step Task from the initiator, or other initiator-like process (z/OS 
UNIX Services, for instance).  However, a PCFLIH backdoor can allow a 
problem state, non-system key program that is not running APF authorized 
to receive control in an authorized state simply by causing a program 
interrupt to occur.  Now I don't know if this particular backdoor does 
this or not, but if it does (or worse, can be spoofed by a caller to do 
this) than it would constitute a violation of z/OS system integrity.

===
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(AT)us.ibm.com
=== 



From:
"Pate, Gene" 
To:
IBM-MAIN@bama.ua.edu
Date:
03/05/2012 08:30 AM
Subject:
Re: Program FLIH backdoor - This is a criminal breach of security!
Sent by:
IBM Mainframe Discussion List 



I am amazed at the uproar over this. Is there anything that a PCFLIH 
backdoor can accomplish that any AC=1 module in any APF authorized library 
cannot? 



Gene Pate 
CSX Technology
Enterprise Architecture






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Binyamin Dissen

On Mon, 5 Mar 2012 14:19:33 + "Pate, Gene"  wrote:

:>I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor 
can accomplish that any AC=1 module in any APF authorized library cannot? 

No. The question is how is the PC-FLIH among the best choices to do this
function.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Joel C. Ewing


On 03/05/2012 08:19 AM, Pate, Gene wrote:

I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor 
can accomplish that any AC=1 module in any APF authorized library cannot?
Is there anyone else out there that is running any vendor code for which they 
have not done code reviews that is running AC=1 in any APF authorized library? 
Is there anyone else out there that is running any home grown code with an AC=1 
in an APF authorized library for which they have not done code reviews? Is 
there anyone else out there that has libraries in the APF list that can be 
updated by anything other than there change control system that only allows 
modules that have been through code reviews to be installed in their APF 
authorized libraries?

How you allow code to get into supervisor state is of no consequence once it is 
in supervisor state so, unless you have a pristine system where every load 
module library on the system is totally locked down and only the OS libraries 
supplied by IBM appear in the APF list, you have by definition accepted 
exposures to system integrity. Does your management understand just how exposed 
you have left all the company secrets?

Using a PCFLIH backdoor is only one of many techniques that can be used to 
accomplish getting yourself into supervisor state and sometimes it is the right 
technique and sometimes it is not.

Back in the late 70's I wrote a PCFLIH backdoor because it was not only the 
correct technique it was the only technique that would work. My company and its 
sister companies had many 168APs that did not have the MVS/SE hardware assist 
installed. At that time IBM wanted about $150K per system for the hardware 
upgrade and we already had plans to replace all of them over the next 3 years 
with 3033s so there was no money to upgrade them. I wrote an SE hardware 
emulator that would run on Ups, APs, and MPs and while you got a 15% 
performance increase with the hardware upgrade and MVS/SE we still got around 
12% with my PCFLIH hardware emulator and we were able to move to MVS/SE 3 years 
sooner that we could have had we all had to wait until all the 168s were 
replaced.

If there was any criminal activity involved in this entire affair I believe it 
was on IBM's part for trying to charge us $150K per system for a microcode 
upgrade to a bunch of outdated systems and not on the part any PCFLIH code that 
I wrote so I outright reject your assertion that a PCFLIH backdoor is any more 
criminal than running any AC=1 module in any APF authorized library that you as 
the systems programmer have not personally code reviewed before you allowed it 
to run on any system that you are responsible for!

Gene Pate
CSX Technology
Enterprise Architecture


...
While it is a given that a module running "authorized" can, if malicious 
or badly written, potentially do anything bad that could be done by a 
PCFLIH back door, it also would seem that as a general principle one 
would want to be able to limit the potential exposure from sensitive 
code as much as possible -- in other words, use the least-global 
interfaces that will suffice.  Code reviews may be able to catch obvious 
malicious code, but the existence of corrective product  SYSMODS attests 
to the continuing inability of reviews and testing to catch 100% of 
subtle errors and bugs.


An authorized vendor module that is normally only invoked from vendor 
address spaces, if found to do bad things unintentionally, might at 
least be more likely to damage virtual storage and data associated with 
the vendor application; and not starting vendor address spaces or 
invoking the product could reasonably be expected to suppress use of the 
code. While someone familiar with the interface might attempt to invoke 
this code in a context for which it was not intended, this would have to 
be a deliberate act and not an accident.


I think people tend to have a gut feeling that the exposure from a 
PCFLIH back door is much greater because this code has much greater 
potential to be invoked by any arbitrary address space and not just for 
those address spaces or events related to the vendor product.  Users of 
the interface are in general unaware they are invoking the vendor code, 
and in the worst case scenario a code bug might render the system 
unusable even when the offending vendor product is not started or 
directly invoked.  If sysprogs are unaware that such an interface is 
being used by a product, they would also be unlikely to know how to 
disable its use if it should become a problem.


The generic "suspicion" toward a PCFLIH back door is probably not unlike 
the uproar several years back when another interface was used 
inappropriately that could have had serious negative impact far beyond 
the vendor product for which it was intended.  It was revealed that CA 
was distributing in their products an SMP/E exit to automatically bypass 
ID errors to compensate for bad packaging of CA SYSMODs at the time. 
While

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Paul Gilmartin

On Mon, 5 Mar 2012 14:19:33 +, Pate, Gene wrote:

>I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor 
>can accomplish that any AC=1 module in any APF authorized library cannot?
>Is there anyone else out there that is running any vendor code for which they 
>have not done code reviews that is running AC=1 in any APF authorized library? 
>Is there anyone else out there that is running any home grown code with an 
>AC=1 in an APF authorized library for which they have not done code reviews? 
>Is there anyone else out there that has libraries in the APF list that can be 
>updated by anything other than there change control system that only allows 
>modules that have been through code reviews to be installed in their APF 
>authorized libraries?
>
>How you allow code to get into supervisor state is of no consequence once it 
>is in supervisor state so, unless you have a pristine system where every load 
>module library on the system is totally locked down ...
>
Not "every".  I believe IBM's SOI applies regardless of what mey be put
in non-authorized load libraries.

>and only the OS libraries supplied by IBM appear in the APF list, you have by 
>definition accepted exposures to system integrity. Does your management 
>understand just how exposed you have left all the company secrets?
>
Or, by your earlier paragraph, suitable review is performed for non-IBM code.
And even then, IBM's SOI doesn't apply.

But why do you trust IBM?  Their code is OCO and difficult to review.  I suppose
it's possible if one signs the required NDAs and pays the charges.

Is there any independent commercial body that so reviews and certifies IBM's
code?  And even indemnifies?  For a price, of course.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Bob Shannon

>I wrote an SE hardware emulator that would run on Ups, APs, and MPs and while 
>you got a 15% >performance increase with the hardware upgrade and MVS/SE we 
>still got around 12% with my >PCFLIH hardware emulator and we were able to 
>move to MVS/SE 3 years sooner that we could have >had we all had to wait until 
>all the 168s were replaced.

That's exactly what Amdahl's SE and SP Assist did. 

Bob Shannon
Rocket Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-05 Thread Pate, Gene

I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor 
can accomplish that any AC=1 module in any APF authorized library cannot? 
Is there anyone else out there that is running any vendor code for which they 
have not done code reviews that is running AC=1 in any APF authorized library? 
Is there anyone else out there that is running any home grown code with an AC=1 
in an APF authorized library for which they have not done code reviews? Is 
there anyone else out there that has libraries in the APF list that can be 
updated by anything other than there change control system that only allows 
modules that have been through code reviews to be installed in their APF 
authorized libraries? 

How you allow code to get into supervisor state is of no consequence once it is 
in supervisor state so, unless you have a pristine system where every load 
module library on the system is totally locked down and only the OS libraries 
supplied by IBM appear in the APF list, you have by definition accepted 
exposures to system integrity. Does your management understand just how exposed 
you have left all the company secrets?

Using a PCFLIH backdoor is only one of many techniques that can be used to 
accomplish getting yourself into supervisor state and sometimes it is the right 
technique and sometimes it is not.

Back in the late 70's I wrote a PCFLIH backdoor because it was not only the 
correct technique it was the only technique that would work. My company and its 
sister companies had many 168APs that did not have the MVS/SE hardware assist 
installed. At that time IBM wanted about $150K per system for the hardware 
upgrade and we already had plans to replace all of them over the next 3 years 
with 3033s so there was no money to upgrade them. I wrote an SE hardware 
emulator that would run on Ups, APs, and MPs and while you got a 15% 
performance increase with the hardware upgrade and MVS/SE we still got around 
12% with my PCFLIH hardware emulator and we were able to move to MVS/SE 3 years 
sooner that we could have had we all had to wait until all the 168s were 
replaced.

If there was any criminal activity involved in this entire affair I believe it 
was on IBM's part for trying to charge us $150K per system for a microcode 
upgrade to a bunch of outdated systems and not on the part any PCFLIH code that 
I wrote so I outright reject your assertion that a PCFLIH backdoor is any more 
criminal than running any AC=1 module in any APF authorized library that you as 
the systems programmer have not personally code reviewed before you allowed it 
to run on any system that you are responsible for! 

Gene Pate
CSX Technology
Enterprise Architecture



-
This email transmission and any accompanying attachments may
contain CSX privileged and confidential information intended only
for the use of the intended addressee.  Any dissemination,
distribution, copying or action taken in reliance on the contents
of this email by anyone other than the intended recipient is
strictly prohibited.  If you have received this email in error
please immediately delete it and  notify sender at the above CSX
email address.  Sender and CSX accept no liability for any damage
caused directly or indirectly by receipt of this email.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-04 Thread Edward Jaffe


On 3/4/2012 10:28 AM, Shmuel Metz (Seymour J.) wrote:

Speculative? Did you read what he quoted from Bill Fairchild's message?


Yes. I read it before he quoted it. We don't even know the person's name or how 
long ago this happened (if at all). A lot can change in a decade.


For the record, I once knew of a developer who claimed to have found an MVS back 
door because he wanted to appear cool like a phone phreaking hacker, but he was 
full of B.S. I also know someone that actually *did* find a back door (through 
an EXCP appendage) and IBM closed it.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-04 Thread Edward Jaffe


On 3/4/2012 10:24 AM, Shmuel Metz (Seymour J.) wrote:

The presence of SVC IGX00011 on z/OS systems *proves* that
so-called "magic" SVCs that "confer authority to their callers,"

The ESR's do not"confer authority to their callers," but rather invoke
narrowly defined functions. The so-called "magic" SVC's return to
their callers in a more privileged mode.


Look more closely. That is exactly what IGX00011 does. It is called in problem 
state and returns in supervisor state.





are NOT considered an exposure when implemented correctly.

I have yet to see one that was implemented correctly.


You need to look more closely at IGX00011. Hint: the "secure" implementation is 
not just in the SVC(ESR) routine itself but also in the caller which discards 
all information it had before the SVC(ESR) invocation, including base register 
contents, etc. and starts over with a clean slate.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-04 Thread Shmuel Metz (Seymour J.)

In <4f50f9bf.10...@phoenixsoftware.com>, on 03/02/2012
   at 08:47 AM, Edward Jaffe  said:

>A "magic" PFLIH technique is not substantially different, from an
>integrity  standpoint, than a "magic" SVC except that the code 
>gets control for EVERY interrupt

ITYM every Program interrupt.


>The presence of SVC IGX00011 on z/OS systems *proves* that 
>so-called "magic" SVCs that "confer authority to their callers," 

The ESR's do not"confer authority to their callers," but rather invoke
narrowly defined functions. The so-called "magic" SVC's return to
their callers in a more privileged mode.

>are NOT considered an exposure when implemented correctly.

I have yet to see one that was implemented correctly.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-04 Thread Shmuel Metz (Seymour J.)

In <4f510ab8.2070...@phoenixsoftware.com>, on 03/02/2012
   at 10:00 AM, Edward Jaffe  said:

>The subject line of this thread started off (in the other list) as
>"Program  FLIH". Then, you renamed it to, "Program FLIH backdoor -
>This is a criminal  breach of security!" Having concerns is one
>thing; making speculative  accusations of criminal wrongdoing is
>quite another.

Speculative? Did you read what he quoted from Bill Fairchild's
message?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-04 Thread Rob Schramm

I am sure that you could easily ask VAT Security... since the product
offering is all about verifying the ability to subvert any interface to
gain authorization.

AFAIK VAT has already taken IBM for the trip to discover OS related
vulnerabilities.

Rob Schramm
Senior Systems Consultant
Imperium Group



On Fri, Mar 2, 2012 at 1:00 PM, Edward Jaffe wrote:

> On 3/2/2012 9:09 AM, David Cole wrote:
>
>> At 3/2/2012 10:25 AM, Edward Jaffe wrote:
>>
>>>
>>> The real question is whether an unintended third party can use the code
>>> to become authorized.
>>>
>>
>> Yes. That absolutely is the "real question".
>> And absolutely, that is what Bill Fairchild's post asserts.
>> So that absolutely is why I am concerned.
>>
>
> The subject line of this thread started off (in the other list) as
> "Program FLIH". Then, you renamed it to, "Program FLIH backdoor - This is a
> criminal breach of security!" Having concerns is one thing; making
> speculative accusations of criminal wrongdoing is quite another. Innocent
> until proven guilty is the American way; not the other way 'round.
>
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> 310-338-0400 x318
> edja...@phoenixsoftware.com
> http://www.phoenixsoftware.**com/ <http://www.phoenixsoftware.com/>
>
> --**--**--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-02 Thread Edward Jaffe


On 3/2/2012 9:09 AM, David Cole wrote:

At 3/2/2012 10:25 AM, Edward Jaffe wrote:


The real question is whether an unintended third party can use the code to 
become authorized.


Yes. That absolutely is the "real question".
And absolutely, that is what Bill Fairchild's post asserts.
So that absolutely is why I am concerned.


The subject line of this thread started off (in the other list) as "Program 
FLIH". Then, you renamed it to, "Program FLIH backdoor - This is a criminal 
breach of security!" Having concerns is one thing; making speculative 
accusations of criminal wrongdoing is quite another. Innocent until proven 
guilty is the American way; not the other way 'round.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-02 Thread David Cole


At 3/2/2012 10:25 AM, Edward Jaffe wrote:

On 3/2/2012 1:29 AM, David Cole wrote:
If the PFLIH hook is (as it has been described earlier in these 
threads) a mechanism by which a non-authorized process can become 
authorized, then its very existence is a "substantive offense" in 
and of itself. It is not just "a template", it doesn't just show 
the way. It *is* the way.


I keep coming back to IGX00011. It's presence on z/OS systems PROVES 
that the very existence of a "magic" SVC service, while arguably not 
a 21st-century best practice, is NOT considered an exposure or 
"substantive offense" when done correctly. (Those last three words 
are very important!)


A "magic" PFLIH technique is not substantially different, from an 
integrity standpoint, than a "magic" SVC except that the code gets 
control for EVERY interrupt and so has the potential to slow things 
down if not implemented efficiently.


The real question is whether an unintended third party can use the 
code to become authorized.


Yes. That absolutely is the "real question".
And absolutely, that is what Bill Fairchild's post asserts.
So that absolutely is why I am concerned.






Unlike the "magic" SVCs of the past, I'm confident that IGX00011 
cannot be exploited by unintended third parties.


That is good to know.







The same might very well be true of the PFLIH approach being discussed here,
despite any third-party hearsay from Bill Fairchild's colleague 
claiming otherwise.


Certainly, the "hearsay" could be wrong. And I do hope that it is wrong.
But it is a better course to assume that the charge is right and 
raise awareness to the point where it will be investigated and PROVEN 
to be right or wrong...


... than it is to assume that the charge is wrong and just sit back 
and *hope* that nothing bad happens.


In other words, I think that being noisy about this issue will have a 
more constructive result than being silent will.








--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658  


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-02 Thread Edward Jaffe


On 3/2/2012 1:29 AM, David Cole wrote:
If the PFLIH hook is (as it has been described earlier in these threads) a 
mechanism by which a non-authorized process can become authorized, then its 
very existence is a "substantive offense" in and of itself. It is not just "a 
template", it doesn't just show the way. It *is* the way.


A "magic" PFLIH technique is not substantially different, from an integrity 
standpoint, than a "magic" SVC except that the code gets control for EVERY 
interrupt and so has the potential to slow things down if not implemented 
efficiently. The presence of SVC IGX00011 on z/OS systems *proves* that 
so-called "magic" SVCs that "confer authority to their callers," while arguably 
not a 21st-century best practice, are NOT considered an exposure when 
implemented correctly. (Those last three words are very important!)


The real question is whether an unintended third party can use the code to 
become authorized. Unlike the "magic" SVCs of the past, I'm confident that 
IGX00011 cannot be exploited by unintended third parties. The same might very 
well be true of the PFLIH approach being discussed here, despite any speculation 
or hearsay to the contrary.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-02 Thread John Gilmore

David Cole and I are, I think, in substantive agreement about the
offensive character of this ISV's scheme.

That said, the situation we confront would be much worse if this
scheme had been used to do real mischief.  It has not, and we can take
some small comfort---It is only small comfort--- in that.

There is an old notion that, shorn of any sexist connotations it may
once have had, remains important.  It is not enough that Caesar's wife
be virtuous; she must also be seen to be virtuous.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-02 Thread David Cole


At 3/1/2012 06:46 PM, Skip Robinson wrote:
For years we ran a 'channel extender' product call RDS. It worked by 
front-endng FLIH for I/O interrupts to determine whether the I/O was 
to or from a supported device as defined to RDS. If not, the I/O was 
passed along for normal processing. If so, RDS redirected the I/O to 
its own network device for transmission (out); or written to the 
intended device (in). It sounds kludgy, but it worked amazingly 
well. The vendor was very forthright about the internals. We had 
occasional hardware problems with RDS, but I never once saw an OS 
failure caused by this technique.


This sort of thing is best not done at home.


This also is a example of a "legitimate" use of an intercept. It does 
not confer authority upon its caller. All it does is perform a 
service on behalf of a caller and which the caller itself does not 
have the authority to perform on its own. In this sense it is no 
different from any other system service (OPEN, WTO, GETMAIN, etc.) 
performed by the OS.








JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-02 Thread David Cole


John Gilmore wrote:
even though, as I believe, the the offender's code itself commits no 
substantive offense it it is, I think, guilty of the admittedly much 
subtler offense of providing a template for others, who are bent on 
mischief, to use.


If the PFLIH hook is (as it has been described earlier in these 
threads) a mechanism by which a non-authorized process can become 
authorized, then its very existence is a "substantive offense" in and 
of itself. It is not just "a template", it doesn't just show the way. 
It *is* the way.


I fervently hope that the existence of this thread has gotten the 
attention of the ISV who has created this obscenity and that it will 
commit immediate resources to purging this from its products.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658





At 3/1/2012 04:54 PM, John Gilmore wrote:

I don't want to put words in EJ's mouth; but if 'an exposure' were
replaced by what I should call 'misuse' what he said is correct and
not even controversial.

I think there is an exposure, in the sense that this device lends
itself very readily to abuse.  I have seen no evidence that it has
actually been misused in any but the tenuous sense that it adds
clandestine overhead to the processing of every interrupt.

The device itself has been much misused elsewhere.  A number of
viruses have, for example, used a Windows scheduled task---PC Health
Data Collection is a favorite---to hijack PCs.

Moreover, now that its use has been publicized here, the scheme it
embodies---not, a fortiori, the offender's code itself---is all but
certain to be used irresponsibly by others; even though, as I believe,
the the offender's code itself commits no substantive offense it it
is, I think, guilty of the admittedly much subtler offense of
providing a template for others, who are bent on mischief, to use.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-01 Thread Skip Robinson

For years we ran a 'channel extender' product call RDS. It worked by 
front-endng FLIH for I/O interrupts to determine whether the I/O was to or 
from a supported device as defined to RDS. If not, the I/O was passed 
along for normal processing. If so, RDS redirected the I/O to its own 
network device for transmission (out); or written to the intended device 
(in). It sounds kludgy, but it worked amazingly well. The vendor was very 
forthright about the internals. We had occasional hardware problems with 
RDS, but I never once saw an OS failure caused by this technique. 

This sort of thing is best not done at home. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Gilmore 
To: IBM-MAIN@bama.ua.edu
Date:   03/01/2012 01:56 PM
Subject:    Re: Program FLIH backdoor - This is a criminal breach of 
security!
Sent by:IBM Mainframe Discussion List 



I don't want to put words in EJ's mouth; but if 'an exposure' were
replaced by what I should call 'misuse' what he said is correct and
not even controversial.

I think there is an exposure, in the sense that this device lends
itself very readily to abuse.  I have seen no evidence that it has
actually been misused in any but the tenuous sense that it adds
clandestine overhead to the processing of every interrupt.

The device itself has been much misused elsewhere.  A number of
viruses have, for example, used a Windows scheduled task---PC Health
Data Collection is a favorite---to hijack PCs.

Moreover, now that its use has been publicized here, the scheme it
embodies---not, a fortiori, the offender's code itself---is all but
certain to be used irresponsibly by others; even though, as I believe,
the the offender's code itself commits no substantive offense it it
is, I think, guilty of the admittedly much subtler offense of
providing a template for others, who are bent on mischief, to use.

John Gilmore, Ashland, MA 01721 - USA


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-01 Thread John Gilmore

I don't want to put words in EJ's mouth; but if 'an exposure' were
replaced by what I should call 'misuse' what he said is correct and
not even controversial.

I think there is an exposure, in the sense that this device lends
itself very readily to abuse.  I have seen no evidence that it has
actually been misused in any but the tenuous sense that it adds
clandestine overhead to the processing of every interrupt.

The device itself has been much misused elsewhere.  A number of
viruses have, for example, used a Windows scheduled task---PC Health
Data Collection is a favorite---to hijack PCs.

Moreover, now that its use has been publicized here, the scheme it
embodies---not, a fortiori, the offender's code itself---is all but
certain to be used irresponsibly by others; even though, as I believe,
the the offender's code itself commits no substantive offense it it
is, I think, guilty of the admittedly much subtler offense of
providing a template for others, who are bent on mischief, to use.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-01 Thread David Cole


Ed,

Let me quote to you what Bill Fairchild posted earlier on this thread:

At 2/23/2012 05:42 PM, Bill Fairchild wrote:
I found a similar (and maybe the same) vendor hook in 1996, 
disassembled the code, and discovered that one of its purposes was 
to put an unauthorized caller into various protect keys, supervisor 
state, etc., based on the contents of a register.   I alerted the 
vendor that using a hook such as this was not the optimal way to get 
into some authorized state.  Literally anyone could have 
disassembled the code enough to see how to exploit the hook and get 
an unauthorized program into supervisor state and key 0.  The vendor 
made some changes shortly thereafter and claimed that the 
enhancement was now much better.


[***===>] I didn't have time to disassemble the new version and 
figure out how to hack into it, but a colleague of mine did and said 
it was still relatively easy to subvert. [<===***]


This vendor has many products which are typically installed in a 
system all at the same time, and many of their products make use of 
this program FLIH hook to do authorized things.


That is the genesis of my very strong reaction to this thread.

Certainly hooking xFLIH or SVCs or whatever is not, in and of itself, 
evil. However, then using said hook to grant "your" programs 
authority is where it all goes very very south! As Fairchild's 
colleague demonstrates, such backdoors generally can be subverted.


That fact that "we" do not "know" that the code is still subvertable 
is no excuse for inaction. The threat, as described in this thread, 
is significant. Doing nothing is just burying one's head in the sand.


Dave Cole  REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA 22920FAX:  540-456-6658






At 3/1/2012 11:52 AM, Edward Jaffe wrote:

On 3/1/2012 6:52 AM, David Cole wrote:


This is not just despicable, under today's law, it is actually criminal! Any
vendor who does this could be (and should be) jailed in criminal courts and
sued out of existence in civil courts.

I do not know who is doing this, but I believe utmost pressure must 
be brought
to bear upon that vendor so that it will commit every resource to 
removing the

breach from its products.


Just to clear: intercepting the FLIH does not itself constitute an 
exposure and,

as far as state changes go, the checking and requirements could be complete
enough to avoid any integrity problem. For example, the methodology could be
similar to that employed by IBM's IGX00011 "magic" SVC and its 
intended caller.
Unless someone can prove there really is an exposure, which to my 
knowledge has

not been done, I suggest that passing such judgment is premature.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

51 matches

Mail list logo