Re: Un-authorized caller calling authorized services.

[Andy Wood]

On Wed, 4 Dec 2013 16:57:29 +, DASDBILL2  wrote:

>It appears that if R1 contains a -4, -8, or -12, then the code will go into an 
>infinite loop.  This would not cause a security breach, but it is still an 
>error. 
>Bill Fairchild 
>Franklin, TN 

That is true, but given the vast range it can be made to branch to, a loop is 
but one of probably thousands of different outcomes.

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

Re: Un-authorized caller calling authorized services.

[DASDBILL2]

It appears that if R1 contains a -4, -8, or -12, then the code will go into an 
infinite loop.  This would not cause a security breach, but it is still an 
error. 
Bill Fairchild 
Franklin, TN 

- Original Message -

From: "Robert A. Rosenberg"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, December 3, 2013 9:54:00 PM 
Subject: Re: Un-authorized caller calling authorized services. 

Definitely a large positive number over 2^16-1 (so there is something 
other than zeros in the high 2 bytes). 

The low 2 bytes have to be between x"" and x"0008" to pass the CH 
R1,=H8" check. 

As to negative numbers, that number also has to be within certain 
boundaries so the low bytes meet the same range check. 


At 12:59 -0600 on 12/03/2013, Ray Overby wrote about Re: 
Un-authorized caller calling authorized services.: 

>>Flawed function code validation. Like this in an SVC routine that 
>>was "supposed" to be called with a function code of 0, 4 or 8 in R1. 
>> 
>>           CH    R1,=H'8'       IF FUNCTION CODE TOO LARGE 
>>           BH    RETURN         THEN IGNORE IT 
>>           B     BTABLE(R1)     USE BRANCH TABLE TO GO TO REQUIRED 
>>*                                 FUNCTION 
>>BTABLE   B     HERE           FUNCTION=0 
>>           B     THERE          FUNCTION=4 
>>           B     EVERYWHERE     FUNCTION=8 

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

Re: Un-authorized caller calling authorized services.

[Andy Wood]

On Tue, 3 Dec 2013 21:54:00 -0600, Robert A. Rosenberg  
wrote:

>Definitely a large positive number over 2^16-1 (so there is something
>other than zeros in the high 2 bytes).
>
>The low 2 bytes have to be between x"" and x"0008" to pass the CH
>R1,=H8" check.
>
>As to negative numbers, that number also has to be within certain
>boundaries so the low bytes meet the same range check.
>
>
>At 12:59 -0600 on 12/03/2013, Ray Overby wrote about Re:
>Un-authorized caller calling authorized services.:
>

I'm not sure what you are saying there. 

CH does not ignore the high order bytes of the register - in effect it 
sign-extendeds the halfword (H'8' there) to a fullword for comparison with the 
register. The problem is with negative function codes, not "large" positive 
ones. 

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

Re: Un-authorized caller calling authorized services.

[Robert A. Rosenberg]

Definitely a large positive number over 2^16-1 (so there is something 
other than zeros in the high 2 bytes).


The low 2 bytes have to be between x"" and x"0008" to pass the CH 
R1,=H8" check.


As to negative numbers, that number also has to be within certain 
boundaries so the low bytes meet the same range check.



At 12:59 -0600 on 12/03/2013, Ray Overby wrote about Re: 
Un-authorized caller calling authorized services.:


flawed function code validation - If you pass a negative number or a 
large positive number you can control where the SVC branches to. I 
have seen these types of problems "in the wild" where I was able to 
branch to a private area where any code you wanted could be executed.



Ray Overby
Key Resources, Inc
Ensuring System Integrity for z/Series
(312) 574-0007

On 12/3/2013 12:46 PM, Andy Wood wrote:

On Mon, 2 Dec 2013 13:36:43 -0600, Ray Overby  wrote:


When creating authorized code I use the following guidelines:

-   It is not good enough that the authorized code "functions" as
designed. Authorized code has a higher standard that it must adhere to.
Your code must not allow malicious or uninformed users to make it do
things outside of its scope.
-   Pay attention to how you obtain your parameters.
  -Parameters should be accessed in the requesters PSW Key.
  -Make a copy of the parameters so that they cannot be changed
after you have validated them and before you use them (time of check 2
time of use vulnerability).
-Make sure sensitive data is kept in fetch protected storage.
-Make sure your design does not allow the requester to control where
the authorized code branches to:
  -By branching to a user specified address in an authorized state
  -By branching on a function code whose value is not verified
to be in a specific range
-Be careful issuing authorized services in your code AND allowing
user parameters to be specified in the authorized services parameter list.
-   Return data to requester in their PSW Key.
-   Don't return control to the requester with a higher level of authority
 -Don't dynamically  elevate their security credentials
 -Don't allow the requester the ability to MODESET
 -Don't return control in a different PSW Key or State


Ray Overby
Key Resources, Inc
Ensuring System Integrity for z/Series
(312) 574-0007

I've lost track of the number of issues I found in this sort of 
code over the years. A lot of those problems would have been 
avoided by following the advice above.


Some of the more common problems:

Flawed function code validation. Like this in an SVC routine that 
was "supposed" to be called with a function code of 0, 4 or 8 in R1.


  CHR1,=H'8'   IF FUNCTION CODE TOO LARGE
  BHRETURN THEN IGNORE IT
  B BTABLE(R1) USE BRANCH TABLE TO GO TO REQUIRED
* FUNCTION
BTABLE   B HERE   FUNCTION=0
  B THERE  FUNCTION=4
  B EVERYWHERE FUNCTION=8
  So what happens if it is called with a function code that is not 
a multiple of 4? Actually, it has a bigger problem than that, can 
you spot it?


Still, that is better than the two SVC routines I encountered, both 
of which were only two bytes long, and that could have been called 
IEFBR15 and IEFBR1 respectively, or the SVC which performed an MVCL 
using caller provided addresses and lengths, with absolutely no 
validation at all.


Another common problem was SVC routines that found it necessary to 
examine a CDE to assist with distinguishing the good guys from the 
bad (a notoriously difficult task if the bad guys refuse to 
cooperate). They followed a pointer from the caller's RB to locate 
the CDE, "forgetting" that not all RBs point to CDEs. The result 
was that they could be trivially deceived by calling them from an 
IRB.


Another issue was inadvertently making an assumption about the 
contents of some register. This was more common in PC routines but 
I also saw more than one SVC that started out with:

  STM   R14,R12,12(R13)

Another flawed "good guy" test I saw over and over again was to 
assume that if you knew the location of your caller (say PLPA) or 
if the caller's code resided in system key storage, then they could 
be trusted. I suspect this false notion may have its roots in the 
original, and somewhat infamous "SPFCOPY" SVC.


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



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


-

Re: Un-authorized caller calling authorized services.

[Gerhard Postpischil]

On 12/3/2013 1:59 PM, Ray Overby wrote:

flawed function code validation - If you pass a negative number or a
large positive number you can control where the SVC branches to. I have
seen these types of problems "in the wild" where I was able to branch to
a private area where any code you wanted could be executed.


BTDTGTTS - long ago I "discovered" how to kill two flies with one stone 
- in the example, change the test to CL R1,=F'8' - after that, 
extraneous bits may be tested with an EX R1,


Gerhard Postpischil
Bradford, Vermont

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

Re: Un-authorized caller calling authorized services.

[Shmuel Metz (Seymour J.)]

In <2958507380311552.wa.woodagozemail.com...@listserv.ua.edu>, on
12/03/2013
   at 12:46 PM, Andy Wood  said:

>So what happens if it is called with a function code that is not a
>multiple of 4? Actually, it has a bigger problem than that, can you
>spot it?

ITYM a smaller problem 

My favorite was an SVC with an exposure that I was ordered to not tell
the auditors about, although I was eventually allowed to fix it.
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Un-authorized caller calling authorized services.

[Shmuel Metz (Seymour J.)]

In , on 12/02/2013
   at 07:47 PM, Binyamin Dissen  said:

>On Sun, 1 Dec 2013 18:04:18 -0500 "Shmuel Metz (Seymour J.)"
> wrote:

>:>In
>:>,
>:>on 11/30/2013
>:>   at 09:53 PM, "Blaicher, Christopher Y." 
>:>said:
>:>
>:>>- Don't ever read data from a caller's address space when you are 
>:>.not in the caller's key.

>:>MVCK

>MVCSK

MVCOS

>:>>- Don't EVER, EVER write data to a caller's address space when 
>:>>you are not in the caller's key.

>:>MVCK

>MVCDK

MVCOS

The point being that there are half a dozen specialized instructions
that do the necessary key checking without any need to be in the
callers key; the particular instructions that are appropriate depend,
e.g., on the environment. MVCK was just a particular counterexample,
appropriate for some cases but not for others.
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Un-authorized caller calling authorized services.

[Ray Overby]

flawed function code validation - If you pass a negative number or a 
large positive number you can control where the SVC branches to. I have 
seen these types of problems "in the wild" where I was able to branch to 
a private area where any code you wanted could be executed.



Ray Overby
Key Resources, Inc
Ensuring System Integrity for z/Series
(312) 574-0007

On 12/3/2013 12:46 PM, Andy Wood wrote:

On Mon, 2 Dec 2013 13:36:43 -0600, Ray Overby  wrote:


When creating authorized code I use the following guidelines:

-   It is not good enough that the authorized code "functions" as
designed. Authorized code has a higher standard that it must adhere to.
Your code must not allow malicious or uninformed users to make it do
things outside of its scope.
-   Pay attention to how you obtain your parameters.
  -Parameters should be accessed in the requesters PSW Key.
  -Make a copy of the parameters so that they cannot be changed
after you have validated them and before you use them (time of check 2
time of use vulnerability).
-Make sure sensitive data is kept in fetch protected storage.
-Make sure your design does not allow the requester to control where
the authorized code branches to:
  -By branching to a user specified address in an authorized state
  -By branching on a function code whose value is not verified
to be in a specific range
-Be careful issuing authorized services in your code AND allowing
user parameters to be specified in the authorized services parameter list.
-   Return data to requester in their PSW Key.
-   Don't return control to the requester with a higher level of authority
 -Don't dynamically  elevate their security credentials
 -Don't allow the requester the ability to MODESET
 -Don't return control in a different PSW Key or State


Ray Overby
Key Resources, Inc
Ensuring System Integrity for z/Series
(312) 574-0007


I've lost track of the number of issues I found in this sort of code over the 
years. A lot of those problems would have been avoided by following the advice 
above.

Some of the more common problems:

Flawed function code validation. Like this in an SVC routine that was 
"supposed" to be called with a function code of 0, 4 or 8 in R1.

  CHR1,=H'8'   IF FUNCTION CODE TOO LARGE
  BHRETURN THEN IGNORE IT
  B BTABLE(R1) USE BRANCH TABLE TO GO TO REQUIRED
* FUNCTION
BTABLE   B HERE   FUNCTION=0
  B THERE  FUNCTION=4
  B EVERYWHERE FUNCTION=8
  
So what happens if it is called with a function code that is not a multiple of 4? Actually, it has a bigger problem than that, can you spot it?


Still, that is better than the two SVC routines I encountered, both of which 
were only two bytes long, and that could have been called IEFBR15 and IEFBR1 
respectively, or the SVC which performed an MVCL using caller provided 
addresses and lengths, with absolutely no validation at all.

Another common problem was SVC routines that found it necessary to examine a CDE to 
assist with distinguishing the good guys from the bad (a notoriously difficult task if 
the bad guys refuse to cooperate). They followed a pointer from the caller's RB to locate 
the CDE, "forgetting" that not all RBs point to CDEs. The result was that they 
could be trivially deceived by calling them from an IRB.

Another issue was inadvertently making an assumption about the contents of some 
register. This was more common in PC routines but I also saw more than one SVC 
that started out with:
  STM   R14,R12,12(R13)

Another flawed "good guy" test I saw over and over again was to assume that if you knew 
the location of your caller (say PLPA) or if the caller's code resided in system key storage, then 
they could be trusted. I suspect this false notion may have its roots in the original, and somewhat 
infamous "SPFCOPY" SVC.

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



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

Re: Un-authorized caller calling authorized services.

[Andy Wood]

On Mon, 2 Dec 2013 13:36:43 -0600, Ray Overby  wrote:

>When creating authorized code I use the following guidelines:
>
>-   It is not good enough that the authorized code "functions" as
>designed. Authorized code has a higher standard that it must adhere to.
>Your code must not allow malicious or uninformed users to make it do
>things outside of its scope.
>-   Pay attention to how you obtain your parameters.
>  -Parameters should be accessed in the requesters PSW Key.
>  -Make a copy of the parameters so that they cannot be changed
>after you have validated them and before you use them (time of check 2
>time of use vulnerability).
>-Make sure sensitive data is kept in fetch protected storage.
>-Make sure your design does not allow the requester to control where
>the authorized code branches to:
>  -By branching to a user specified address in an authorized state
>  -By branching on a function code whose value is not verified
>to be in a specific range
>-Be careful issuing authorized services in your code AND allowing
>user parameters to be specified in the authorized services parameter list.
>-   Return data to requester in their PSW Key.
>-   Don't return control to the requester with a higher level of authority
> -Don't dynamically  elevate their security credentials
> -Don't allow the requester the ability to MODESET
> -Don't return control in a different PSW Key or State
>
>
>Ray Overby
>Key Resources, Inc
>Ensuring System Integrity for z/Series
>(312) 574-0007
>

I've lost track of the number of issues I found in this sort of code over the 
years. A lot of those problems would have been avoided by following the advice 
above.

Some of the more common problems:

Flawed function code validation. Like this in an SVC routine that was 
"supposed" to be called with a function code of 0, 4 or 8 in R1.

 CHR1,=H'8'   IF FUNCTION CODE TOO LARGE
 BHRETURN THEN IGNORE IT
 B BTABLE(R1) USE BRANCH TABLE TO GO TO REQUIRED
* FUNCTION
BTABLE   B HERE   FUNCTION=0 
 B THERE  FUNCTION=4
 B EVERYWHERE FUNCTION=8
 
So what happens if it is called with a function code that is not a multiple of 
4? Actually, it has a bigger problem than that, can you spot it?

Still, that is better than the two SVC routines I encountered, both of which 
were only two bytes long, and that could have been called IEFBR15 and IEFBR1 
respectively, or the SVC which performed an MVCL using caller provided 
addresses and lengths, with absolutely no validation at all.

Another common problem was SVC routines that found it necessary to examine a 
CDE to assist with distinguishing the good guys from the bad (a notoriously 
difficult task if the bad guys refuse to cooperate). They followed a pointer 
from the caller's RB to locate the CDE, "forgetting" that not all RBs point to 
CDEs. The result was that they could be trivially deceived by calling them from 
an IRB.

Another issue was inadvertently making an assumption about the contents of some 
register. This was more common in PC routines but I also saw more than one SVC 
that started out with:
 STM   R14,R12,12(R13) 

Another flawed "good guy" test I saw over and over again was to assume that if 
you knew the location of your caller (say PLPA) or if the caller's code resided 
in system key storage, then they could be trusted. I suspect this false notion 
may have its roots in the original, and somewhat infamous "SPFCOPY" SVC.

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

Re: Un-authorized caller calling authorized services.

[Tony Harminc]

On 1 December 2013 20:47, Jim Thomas  wrote:
> That said, AFAIK, there's really not much, save but for a RACROUTE
> REQUEST=AUTH perhaps, that I could do in terms of validation, I could do.
> Then again, even w/a RACROUTE/AUTH, it
> still does not guarantee integrity.
> All the above does is to make things a little harder for inappropriate
> users. Perhaps that is all we can do ??.

One should be able to do better than making it a little harder; it
should be very hard indeed.

Part of this is carefully thinking through the authorization model.
You mention RACROUTE REQUEST=AUTH, and that may well be a good start.
But you need to be clear in your mind about what sort of entity you
are authorizing to do what action(s). A RACF userid generally
represents a real person, but it may also represent a department (e.g.
operations), or various other non-person things. A hard-line view says
that there should be a one-to-one mapping of people to userids, but
both a principled view and common practice make that unlikely to be
what you encounter everywhere.

So will your RACROUTE authorize a person to run your magic code, or
will it authorize the calling code to do something, or...? Is there a
Trojan horse attack in there somewhere, for example can an
unauthorized person convince an authorized one to run something from
an inappropriate library?

These are some quick thoughts; as well as good coding practices you
need an authorization model (i.e. how the the good guys will be
determined), and a threat model for how the notional bad guys will
subvert your authorization process.

The documentation surrounding IBM's original MVS statement of system
integrity from the early 1970s remains to this day a remarkably
current taxonomy of threats and failures, and it avoids listing what
Schneier much later called "movie plot threats" in favour of
categorizing them in a way that can be defended against.

Tony H.

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

Re: Un-authorized caller calling authorized services.

[Ray Overby]

When creating authorized code I use the following guidelines:

-   It is not good enough that the authorized code "functions" as 
designed. Authorized code has a higher standard that it must adhere to. 
Your code must not allow malicious or uninformed users to make it do 
things outside of its scope.

-   Pay attention to how you obtain your parameters.
 -Parameters should be accessed in the requesters PSW Key.
 -Make a copy of the parameters so that they cannot be changed 
after you have validated them and before you use them (time of check 2 
time of use vulnerability).

-Make sure sensitive data is kept in fetch protected storage.
-Make sure your design does not allow the requester to control where 
the authorized code branches to:

 -By branching to a user specified address in an authorized state
 -By branching on a function code whose value is not verified 
to be in a specific range
-Be careful issuing authorized services in your code AND allowing 
user parameters to be specified in the authorized services parameter list.

-   Return data to requester in their PSW Key.
-   Don't return control to the requester with a higher level of authority
-Don't dynamically  elevate their security credentials
-Don't allow the requester the ability to MODESET
-Don't return control in a different PSW Key or State


Ray Overby
Key Resources, Inc
Ensuring System Integrity for z/Series
(312) 574-0007

On 12/1/2013 7:47 PM, Jim Thomas wrote:

Shmuel,

Thank you for your responses, this and  previous.

I concur w/what you've said and w/what others have said. Before I go on, as
Peter pointed out, I admit that I've
used incorrect terminology (e.g. call / invoke a SRB) and I apologize.

That said, AFAIK, there's really not much, save but for a RACROUTE
REQUEST=AUTH perhaps, that I could do
in terms of validation, I could do. Then again, even w/a RACROUTE/AUTH, it
still does not guarantee integrity.
All the above does is to make things a little harder for inappropriate
users. Perhaps that is all we can do ??.

I've taken everybody's suggestions and advice and think I've, decided to
take a slight variation to PC / SVC's, use
RACROUTE and have a separate load library that will be clearly documented as
needing to be APF'd.

Though I am responding to Shmuel, I thank everybody for taking the time to
respond / advice.

Once again, thank you everybody.

Kind Regards.

Jim Thomas


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Sunday, December 01, 2013 5:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

In <021001ceee3c$9f1fe880$dd5fb980$@TheThomasResidence.us>, on
11/30/2013
at 08:25 PM, Jim Thomas  said:


In a nutshell, I'm trying to find out what the best way is for an
un-authorized called to call  / invoke a SRB.

It can't. The only ways for unauthorized code to invoke authorized services
are PC and SVC. You need an interface service (either PC or
SVC) that will accept parameters, validity check everything and schedule the
SRB.
  


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

Re: Un-authorized caller calling authorized services.

[Binyamin Dissen]

On Sun, 1 Dec 2013 18:04:18 -0500 "Shmuel Metz (Seymour J.)"
 wrote:

:>In
:>,
:>on 11/30/2013
:>   at 09:53 PM, "Blaicher, Christopher Y." 
:>said:
:>
:>>- Don't ever read data from a caller's address space when you are 
:>.not in the caller's key.

:>MVCK

MVCSK

:>>- Don't EVER, EVER write data to a caller's address space when 
:>>you are not in the caller's key.

:>MVCK

MVCDK

--
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Un-authorized caller calling authorized services

[Peter Relson]

>trying to stay away from 
>having to add a new address space to the product

I have seen programs do the following:
- Create/Schedule an IRB to run in ASID=1 under what one
  might call the "NIP task" (there is possibly no intended 
  interface to determine this task; it happens to be the task
  that ran the RIMs during IPL).
- Issue the cross-memory services definitions from the IRB 
  (thus they persist for the life of the IPL). That avoids having
  an "extra" address space for no purpose other than 
  persistance

Any PC in such a scheme would be non-space-switch (it would not be 
appropriate to stash your data in ASID=1 thus there would be no reason to 
have a space-switch PC into ASID=1).

Peter Relson
z/OS Core Technology Design

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

Re: Un-authorized caller calling authorized services.

[Jim Thomas]

Shmuel,

Thank you for your responses, this and  previous. 

I concur w/what you've said and w/what others have said. Before I go on, as
Peter pointed out, I admit that I've
used incorrect terminology (e.g. call / invoke a SRB) and I apologize. 

That said, AFAIK, there's really not much, save but for a RACROUTE
REQUEST=AUTH perhaps, that I could do
in terms of validation, I could do. Then again, even w/a RACROUTE/AUTH, it
still does not guarantee integrity.
All the above does is to make things a little harder for inappropriate
users. Perhaps that is all we can do ??. 

I've taken everybody's suggestions and advice and think I've, decided to
take a slight variation to PC / SVC's, use
RACROUTE and have a separate load library that will be clearly documented as
needing to be APF'd. 

Though I am responding to Shmuel, I thank everybody for taking the time to
respond / advice.

Once again, thank you everybody.

Kind Regards.

Jim Thomas 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Sunday, December 01, 2013 5:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

In <021001ceee3c$9f1fe880$dd5fb980$@TheThomasResidence.us>, on
11/30/2013
   at 08:25 PM, Jim Thomas  said:

>In a nutshell, I'm trying to find out what the best way is for an 
>un-authorized called to call  / invoke a SRB.

It can't. The only ways for unauthorized code to invoke authorized services
are PC and SVC. You need an interface service (either PC or
SVC) that will accept parameters, validity check everything and schedule the
SRB.
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Un-authorized caller calling authorized services.

[Shmuel Metz (Seymour J.)]

In <021001ceee3c$9f1fe880$dd5fb980$@TheThomasResidence.us>, on
11/30/2013
   at 08:25 PM, Jim Thomas  said:

>In a nutshell, I'm trying to find out what the best way is for an
>un-authorized called to call  / invoke a SRB.

It can't. The only ways for unauthorized code to invoke authorized
services are PC and SVC. You need an interface service (either PC or
SVC) that will accept parameters, validity check everything and
schedule the SRB.
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Un-authorized caller calling authorized services.

[Shmuel Metz (Seymour J.)]

In
,
on 11/30/2013
   at 09:53 PM, "Blaicher, Christopher Y." 
said:

>- Don't ever read data from a caller's address space when you are 
.not in the caller's key.

MVCK

>- Don't EVER, EVER write data to a caller's address space when 
>you are not in the caller's key.

MVCK

-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Un-authorized caller calling authorized services.

[Jim Thomas]

Rob,

Yes, this was, in part, one of the options I'd been considering. I was
however, trying to stay away from 
having to add a new address space to the product. I will take your
suggestions and re-consider again.

Yes, MVCS/DK is what I usually use, as much as possible. 

Thank you for your suggestions and advice. 

Kind Regards.

Jim Thomas  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Rob Scott
Sent: Sunday, December 01, 2013 8:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

Jim

My advice would be to have a resource owning server that the batch caller
would be a client of. 

The client invokes a PC owned by the server that performs some sort of SAF
check before using IEAMSCHD to run the SRB in the client. Personally I would
use a PC-ss and a task level RESMGR routine to protect your caller.

MVCSK and MVCDK are your friends to read from and write to caller storage
when the server key does not match the client caller.

Rob Scott
Rocket Software


> On 1 Dec 2013, at 02:25, "Jim Thomas"  wrote:
> 
> Sir/s et'al,
> 
> My service is a SRB and given, SRBPARM, will be executing some code 
> that I am given.
> 
> No, there will not be any I/O and such, I am adhering to the rules of a
SRB.
> That said, the 'code'
> that I am passed will be referencing and updating storage that will 
> ultimately be hardened after I am done and pass control back to my 
> caller.
> 
> My main issue was to find out ways on how I can be called, given that 
> my caller would be un-authorized.
> 
> Binyamin. Chris and others have stated very good points and what to 
> watch out for. Art I thank you for the .PDF that you referenced.
> 
> In a nutshell, I'm trying to find out what the best way is for an 
> un-authorized called to call  / invoke a SRB.
> 
> Kind Regards.
> 
> Jim Thomas
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Binyamin Dissen
> Sent: Saturday, November 30, 2013 5:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Un-authorized caller calling authorized services.
> 
> On Sat, 30 Nov 2013 21:53:06 + "Blaicher, Christopher Y."
>  wrote:
> 
> :>There are a number of things you need to do to prevent an integrity 
> exposure.  At one point I saw a presentation by IBM on this, but right 
> now I can't place my hands on it.  If I do find it, I will post it.  
> Here are the main points of it, as I remember them.
> 
> :>- Don't ever read data from a caller's address space when you are 
> not in the caller's key.  As an SVC or PC your routine can be entered 
> in key zero/supervisor state, I.E. you are a god and can do anything you
want.
> 
> :>- Don't EVER, EVER write data to a caller's address space when you 
> are not in the caller's key.
> 
> :>- You may have written the routine for your exclusive use, but don't 
> assume/think/hope that no one else is going to find it.  Someone will 
> and then they will try to exploit it or use it for nefarious purposes.
> 
> :>- TPROT data areas to be referenced.
> 
> If you do the above, the TPROT is superfluous. And if you do not, 
> realize that unless appropriately locked,  the results may no longer 
> be valid when you try to use it.
> 
> --
> 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...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Un-authorized caller calling authorized services.

[Jim Thomas]

Walt,

As w/my request to Peter, may I please contact you offline ??.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Sunday, December 01, 2013 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

On Sat, 30 Nov 2013 20:25:36 -0600, Jim Thomas  
wrote:

>My service is a SRB and given, SRBPARM, will be executing some code 
>that I am given.

That sounds extremely unsafe, from a system integrity perspective. In general 
you cannot depend on an unauthorized caller to give you code that is safe to 
run in an authorized state.

It can be safe for an unauthorized caller to request you to do a particular 
function, if you check the parameters fully and if all the actual code that you 
will run is contained within (built into) your authorized function. But if the 
unauthorized caller is providing the code that will run then you will need to 
provide a lot more information about exactly what the unauthorized caller is 
before we can give any advice on how you can do that safely. And it is quite 
likely that there is no safe way for you to do it.

So, more details, please.

--
Walt 

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

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

Re: Un-authorized caller calling authorized services.

[Jim Thomas]

Peter ... my apologies .. I used the wrong terminology. 

May I please contact you offline on this ??. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Sunday, December 01, 2013 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

>TPROT

TPROT can tell you "it is not OK". It almost never can tell you fully "it is
OK" because of time-of-check to time-of-use exposures.

>In a nutshell, I'm trying to find out what the best way is for an 
>un-authorized called to call  / invoke a SRB.

Not only is there no "best way" there is "no way".

You cannot "call" or "invoke" an SRB. You can only schedule an SRB. And
scheduling an SRB is limited to authorized programs.
Thus an unauthorized program would have to "get authorized" (such sa via SVC
or PC) in order to schedule an SRB.

It is also the case that, if you do allow an unauthorized program to invoke
an SVC/PC to schedule an SRB, you might need to provide some throttle to
prevent a malicious unauthorized program from doing this "too often".

Peter Relson
z/OS Core Technology Design

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

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

Re: Un-authorized caller calling authorized services.

[Walt Farrell]

On Sat, 30 Nov 2013 20:25:36 -0600, Jim Thomas  
wrote:

>My service is a SRB and given, SRBPARM, will be executing some code that I
>am given.

That sounds extremely unsafe, from a system integrity perspective. In general 
you cannot depend on an unauthorized caller to give you code that is safe to 
run in an authorized state.

It can be safe for an unauthorized caller to request you to do a particular 
function, if you check the parameters fully and if all the actual code that you 
will run is contained within (built into) your authorized function. But if the 
unauthorized caller is providing the code that will run then you will need to 
provide a lot more information about exactly what the unauthorized caller is 
before we can give any advice on how you can do that safely. And it is quite 
likely that there is no safe way for you to do it.

So, more details, please.

-- 
Walt

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

Re: Un-authorized caller calling authorized services.

[John McKown]

It might be helpful to have the OP tell us _exactly_ what authorized
function he needs to be done on behalf of his unauthorized user program.
Perhaps there is another way to "get 'er done".

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

Re: Un-authorized caller calling authorized services.

[Peter Relson]

>TPROT

TPROT can tell you "it is not OK". It almost never can tell you fully "it 
is OK" because of time-of-check to time-of-use exposures.

>In a nutshell, I'm trying to find out what the best way is for 
>an un-authorized called to call  / invoke
>a SRB.

Not only is there no "best way" there is "no way".

You cannot "call" or "invoke" an SRB. You can only schedule an SRB. And 
scheduling an SRB is limited to authorized programs.
Thus an unauthorized program would have to "get authorized" (such sa via 
SVC or PC) in order to schedule an SRB.

It is also the case that, if you do allow an unauthorized program to 
invoke an SVC/PC to schedule an SRB, you might need to provide some 
throttle to prevent a malicious unauthorized program from doing this "too 
often".

Peter Relson
z/OS Core Technology Design

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

Re: Un-authorized caller calling authorized services.

[Rob Scott]

Jim

My advice would be to have a resource owning server that the batch caller would 
be a client of. 

The client invokes a PC owned by the server that performs some sort of SAF 
check before using IEAMSCHD to run the SRB in the client. Personally I would 
use a PC-ss and a task level RESMGR routine to protect your caller.

MVCSK and MVCDK are your friends to read from and write to caller storage when 
the server key does not match the client caller.

Rob Scott
Rocket Software


> On 1 Dec 2013, at 02:25, "Jim Thomas"  wrote:
> 
> Sir/s et'al,
> 
> My service is a SRB and given, SRBPARM, will be executing some code that I
> am given.
> 
> No, there will not be any I/O and such, I am adhering to the rules of a SRB.
> That said, the 'code'
> that I am passed will be referencing and updating storage that will
> ultimately be hardened after
> I am done and pass control back to my caller. 
> 
> My main issue was to find out ways on how I can be called, given that my
> caller would be 
> un-authorized. 
> 
> Binyamin. Chris and others have stated very good points and what to watch
> out for. Art I thank
> you for the .PDF that you referenced. 
> 
> In a nutshell, I'm trying to find out what the best way is for an
> un-authorized called to call  / invoke
> a SRB.
> 
> Kind Regards.
> 
> Jim Thomas
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Binyamin Dissen
> Sent: Saturday, November 30, 2013 5:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Un-authorized caller calling authorized services.
> 
> On Sat, 30 Nov 2013 21:53:06 + "Blaicher, Christopher Y."
>  wrote:
> 
> :>There are a number of things you need to do to prevent an integrity
> exposure.  At one point I saw a presentation by IBM on this, but right now I
> can't place my hands on it.  If I do find it, I will post it.  Here are the
> main points of it, as I remember them.
> 
> :>- Don't ever read data from a caller's address space when you are not in
> the caller's key.  As an SVC or PC your routine can be entered in key
> zero/supervisor state, I.E. you are a god and can do anything you want.
> 
> :>- Don't EVER, EVER write data to a caller's address space when you are not
> in the caller's key.
> 
> :>- You may have written the routine for your exclusive use, but don't
> assume/think/hope that no one else is going to find it.  Someone will and
> then they will try to exploit it or use it for nefarious purposes.
> 
> :>- TPROT data areas to be referenced.
> 
> If you do the above, the TPROT is superfluous. And if you do not, realize
> that unless appropriately locked,  the results may no longer be valid when
> you try to use it.  
> 
> --
> 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...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Un-authorized caller calling authorized services.

[Jim Thomas]

Sir/s et'al,

My service is a SRB and given, SRBPARM, will be executing some code that I
am given.

No, there will not be any I/O and such, I am adhering to the rules of a SRB.
That said, the 'code'
that I am passed will be referencing and updating storage that will
ultimately be hardened after
I am done and pass control back to my caller. 

My main issue was to find out ways on how I can be called, given that my
caller would be 
un-authorized. 

Binyamin. Chris and others have stated very good points and what to watch
out for. Art I thank
you for the .PDF that you referenced. 

In a nutshell, I'm trying to find out what the best way is for an
un-authorized called to call  / invoke
a SRB.

Kind Regards.

Jim Thomas

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Saturday, November 30, 2013 5:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

On Sat, 30 Nov 2013 21:53:06 + "Blaicher, Christopher Y."
 wrote:

:>There are a number of things you need to do to prevent an integrity
exposure.  At one point I saw a presentation by IBM on this, but right now I
can't place my hands on it.  If I do find it, I will post it.  Here are the
main points of it, as I remember them.

:>- Don't ever read data from a caller's address space when you are not in
the caller's key.  As an SVC or PC your routine can be entered in key
zero/supervisor state, I.E. you are a god and can do anything you want.

:>- Don't EVER, EVER write data to a caller's address space when you are not
in the caller's key.

:>- You may have written the routine for your exclusive use, but don't
assume/think/hope that no one else is going to find it.  Someone will and
then they will try to exploit it or use it for nefarious purposes.

:>- TPROT data areas to be referenced.

If you do the above, the TPROT is superfluous. And if you do not, realize
that unless appropriately locked,  the results may no longer be valid when
you try to use it.  

--
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...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Un-authorized caller calling authorized services.

[Binyamin Dissen]

On Sat, 30 Nov 2013 21:53:06 + "Blaicher, Christopher Y."
 wrote:

:>There are a number of things you need to do to prevent an integrity exposure. 
 At one point I saw a presentation by IBM on this, but right now I can't place 
my hands on it.  If I do find it, I will post it.  Here are the main points of 
it, as I remember them.

:>- Don't ever read data from a caller's address space when you are not in the 
caller's key.  As an SVC or PC your routine can be entered in key 
zero/supervisor state, I.E. you are a god and can do anything you want.

:>- Don't EVER, EVER write data to a caller's address space when you are not in 
the caller's key.

:>- You may have written the routine for your exclusive use, but don't 
assume/think/hope that no one else is going to find it.  Someone will and then 
they will try to exploit it or use it for nefarious purposes.

:>- TPROT data areas to be referenced.

If you do the above, the TPROT is superfluous. And if you do not, realize that
unless appropriately locked,  the results may no longer be valid when you try
to use it.  

--
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Un-authorized caller calling authorized services.

[Art Celestini]

You may find this useful:

https://public.dhe.ibm.com/partnerworld/pub/misc/coding_for_system_integrity_in_zOS_for_isvs.pdf#!

--Art Celestini


At 05:11 PM 11/30/2013, Jim Thomas wrote:
 
>Chris,
>
>Thank you for your reply sir ... I concur w/your suggestions and no, I am not 
>and will not do so.
>
>That said, w/regard to TPROT, I've had a localized routine that I wrote before 
>the hardware 
>got involved. 
>
>Again, thank you for your suggestions.
>
>Kind Regards.
>
>Jim Thomas
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Blaicher, Christopher Y.
>Sent: Saturday, November 30, 2013 3:53 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Un-authorized caller calling authorized services.
>
>There are a number of things you need to do to prevent an integrity exposure.  
>At one point I saw a presentation by IBM on this, but right now I can't place 
>my hands on it.  If I do find it, I will post it.  Here are the main points of 
>it, as I remember them.
>
>- Don't ever read data from a caller's address space when you are not in the 
>caller's key.  As an SVC or PC your routine can be entered in key 
>zero/supervisor state, I.E. you are a god and can do anything you want.
>
>- Don't EVER, EVER write data to a caller's address space when you are not in 
>the caller's key.
>
>- You may have written the routine for your exclusive use, but don't 
>assume/think/hope that no one else is going to find it.  Someone will and then 
>they will try to exploit it or use it for nefarious purposes.
>
>- TPROT data areas to be referenced.
>
>Let's assume the interface calls for R1 pointing to a two word parameter list. 
> First of all, the words pointed to by R1 may be outside of his address space, 
>so you want to verify their location is valid.  Then the individual parms may 
>or may not point to valid data in his address space.
>
>The original presentation went into about 10 different ways a nefarious user 
>can try to get your valid routine to do something bad.  Maybe Peter Relson has 
>access to it and can post it.
>
>Chris Blaicher
>Principal Software Engineer, Software Development Syncsort Incorporated
>50 Tice Boulevard, Woodcliff Lake, NJ 07677
>P: 201-930-8260  |  M: 512-627-3803
>E: cblaic...@syncsort.com
>
>
>-----Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Jim Thomas
>Sent: Saturday, November 30, 2013 3:09 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Un-authorized caller calling authorized services.
>
>Forgive me, 
>
>I have an authorized service that I've written but needs to be able to allow 
>un-authorized callers to use.
>
>Could anybody please provide any direction on the best way to implement this 
>??. I've already looked at PC's (which might be fine) and having a server type 
>address space (not something I want to do).
>
>I just want to use an acceptable API or venue of sorts. 
>
>Lastly, a while back, I'd posted an email asking how to get a product SMP/E 
>instable and while I never got any responses per se, I did get one offline 
>email from someone that faced the same issues as I did.
>
>To that person, if you happen to read this, please re-contact me offline. I 
>apologize but I lost your email but have some information for you. 
>
>Kind Regards.
>
>Jim Thomas
>j...@thethomasresidence.us 
>

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

Re: Un-authorized caller calling authorized services.

[Jim Thomas]

Chris,

Thank you for your reply sir ... I concur w/your suggestions and no, I am not 
and will not do so.

That said, w/regard to TPROT, I've had a localized routine that I wrote before 
the hardware 
got involved. 

Again, thank you for your suggestions.

Kind Regards.

Jim Thomas

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Saturday, November 30, 2013 3:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

There are a number of things you need to do to prevent an integrity exposure.  
At one point I saw a presentation by IBM on this, but right now I can't place 
my hands on it.  If I do find it, I will post it.  Here are the main points of 
it, as I remember them.

- Don't ever read data from a caller's address space when you are not in the 
caller's key.  As an SVC or PC your routine can be entered in key 
zero/supervisor state, I.E. you are a god and can do anything you want.

- Don't EVER, EVER write data to a caller's address space when you are not in 
the caller's key.

- You may have written the routine for your exclusive use, but don't 
assume/think/hope that no one else is going to find it.  Someone will and then 
they will try to exploit it or use it for nefarious purposes.

- TPROT data areas to be referenced.

Let's assume the interface calls for R1 pointing to a two word parameter list.  
First of all, the words pointed to by R1 may be outside of his address space, 
so you want to verify their location is valid.  Then the individual parms may 
or may not point to valid data in his address space.

The original presentation went into about 10 different ways a nefarious user 
can try to get your valid routine to do something bad.  Maybe Peter Relson has 
access to it and can post it.

Chris Blaicher
Principal Software Engineer, Software Development Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Thomas
Sent: Saturday, November 30, 2013 3:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

Forgive me, 

I have an authorized service that I've written but needs to be able to allow 
un-authorized callers to use.

Could anybody please provide any direction on the best way to implement this 
??. I've already looked at PC's (which might be fine) and having a server type 
address space (not something I want to do).

I just want to use an acceptable API or venue of sorts. 

Lastly, a while back, I'd posted an email asking how to get a product SMP/E 
instable and while I never got any responses per se, I did get one offline 
email from someone that faced the same issues as I did.

To that person, if you happen to read this, please re-contact me offline. I 
apologize but I lost your email but have some information for you. 

Kind Regards.

Jim Thomas
j...@thethomasresidence.us 

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

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

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

Re: Un-authorized caller calling authorized services.

[Blaicher, Christopher Y.]

There are a number of things you need to do to prevent an integrity exposure.  
At one point I saw a presentation by IBM on this, but right now I can't place 
my hands on it.  If I do find it, I will post it.  Here are the main points of 
it, as I remember them.

- Don't ever read data from a caller's address space when you are not in the 
caller's key.  As an SVC or PC your routine can be entered in key 
zero/supervisor state, I.E. you are a god and can do anything you want.

- Don't EVER, EVER write data to a caller's address space when you are not in 
the caller's key.

- You may have written the routine for your exclusive use, but don't 
assume/think/hope that no one else is going to find it.  Someone will and then 
they will try to exploit it or use it for nefarious purposes.

- TPROT data areas to be referenced.

Let's assume the interface calls for R1 pointing to a two word parameter list.  
First of all, the words pointed to by R1 may be outside of his address space, 
so you want to verify their location is valid.  Then the individual parms may 
or may not point to valid data in his address space.

The original presentation went into about 10 different ways a nefarious user 
can try to get your valid routine to do something bad.  Maybe Peter Relson has 
access to it and can post it.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803    
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Thomas
Sent: Saturday, November 30, 2013 3:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

Forgive me, 

I have an authorized service that I've written but needs to be able to allow 
un-authorized callers to use.

Could anybody please provide any direction on the best way to implement this 
??. I've already looked at PC's (which might be fine) and having a server type 
address space (not something I want to do).

I just want to use an acceptable API or venue of sorts. 

Lastly, a while back, I'd posted an email asking how to get a product SMP/E 
instable and while I never got any responses per se, I did get one offline 
email from someone that faced the same issues as I did.

To that person, if you happen to read this, please re-contact me offline. I 
apologize but I lost your email but have some information for you. 

Kind Regards.

Jim Thomas
j...@thethomasresidence.us 

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

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

Re: Un-authorized caller calling authorized services.

[Jim Thomas]

Binyamin,

Thank you for your reply.

Commercial product and I don't want to use a SVC.

I'm kinda leaning toward a PC but was hoping there was an easier way. 

This will (for the most part ..) be purely batch.,.. 

Kind Regards.

Jim Thomas


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Saturday, November 30, 2013 3:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.

On Sat, 30 Nov 2013 14:08:39 -0600 Jim Thomas 
wrote:

:>I have an authorized service that I've written but needs to be able to
allow un-authorized callers :>to use.

:>Could anybody please provide any direction on the best way to implement
this ??. I've already :>looked at PC's (which might be fine) and having a
server type address space (not something I :>want to do).

:>I just want to use an acceptable API or venue of sorts. 

First question: your shop or commercial?

If your shop, why not the old-fashioned SVC? Simple set-up.

A PC is your other choice and unless you do tricky stuff will need a server
address space as its owner.

Under TSO, you can use the parallel TMP

--
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...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Un-authorized caller calling authorized services.

[Binyamin Dissen]

On Sat, 30 Nov 2013 14:08:39 -0600 Jim Thomas 
wrote:

:>I have an authorized service that I've written but needs to be able to allow 
un-authorized callers 
:>to use.

:>Could anybody please provide any direction on the best way to implement this 
??. I've already 
:>looked at PC's (which might be fine) and having a server type address space 
(not something I 
:>want to do).

:>I just want to use an acceptable API or venue of sorts. 

First question: your shop or commercial?

If your shop, why not the old-fashioned SVC? Simple set-up.

A PC is your other choice and unless you do tricky stuff will need a server
address space as its owner.

Under TSO, you can use the parallel TMP

--
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Un-authorized caller calling authorized services.

[Jim Thomas]

Forgive me, 

I have an authorized service that I've written but needs to be able to allow 
un-authorized callers 
to use.

Could anybody please provide any direction on the best way to implement this 
??. I've already 
looked at PC's (which might be fine) and having a server type address space 
(not something I 
want to do).

I just want to use an acceptable API or venue of sorts. 

Lastly, a while back, I'd posted an email asking how to get a product SMP/E 
instable and while I 
never got any responses per se, I did get one offline email from someone that 
faced the same 
issues as I did.

To that person, if you happen to read this, please re-contact me offline. I 
apologize but I lost 
your email but have some information for you. 

Kind Regards.

Jim Thomas
j...@thethomasresidence.us 

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