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, 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_s
>> t
>> 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&ran
>> k
>> =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
>
> ----------------------------------------------------------------------
> 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

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

Reply via email to