RE: security hole in interactive sql call statement?

> Unless the application is designed to allow it, there is
> no way for user to assume the identity of another user if
> LMTCPB is (*YES).

Sure there is - in fact there are multiple ways - here is one that you
pointed out yourself...

> > Well, wrong.  In the STRSQL session, programmer can do
> > CALL QCMDEXC('sbmjob cmd(clrpfm xxx) jobd(PRODJOBD)
> > user(*JOBD)', 000000060.00000)).

This can also be done with DDM, REXEC, RMTCMD, and maybe a 1/2 dozen
other ways to call a program on the iseries.  You should know that the
LMTCPB parameter is (so far) only enforced by QCMD and the FTP remote
command server - a whole host of other services do not prevent users
with LMTCPB(*YES) from running commands.

The reason this SBMJOB can assume the identity of another user is
because the Job Description and the QSECURITY system value conspire to
allow the programmer to run commands using the identity of whoever is
named in job description PRODJOBD.   

If you haven't done so already, DSPJOBD PRODJOBD and inspect the USER
field.  That is the user who's identity (and authority) is being
hijacked by this SBMJOB.

jte


--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
> Sent: Tuesday, November 16, 2004 1:07 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: security hole in interactive sql call
> statement?
> 
> Unless the application is designed to allow it, there is
> no way for user to assume the identity of another user if
> LMTCPB is (*YES).
> Raising the security level would require a bit more work.
> Oh, well, got to do what you got to do, right.
> 
> 
> 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of John
> Earl
> Sent: Tuesday, November 16, 2004 2:57 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: security hole in interactive sql call
> statement?
> 
> 
> > Well, wrong.  In the STRSQL session, programmer can do
> > CALL QCMDEXC('sbmjob cmd(clrpfm xxx) jobd(PRODJOBD)
> > user(*JOBD)', 000000060.00000)).
>   ^^^^^^^^^^
>   ||||||||||
> 
> There's your problem - you're running at QSECURITY level
> 30 (or less),
> or else all of your programmers have *USE (or better)
> authority to the
> user named in the PRODJOBD job description.
> 
> The rules for assuming another user's authority via the
> SBMJOB...
> User(*JOBD) method are as follows:
> 
> At QSECURITY 30 and lower.
> The User that submits the job must have *USE authority to
> the *JOBD
> only.
> 
> At QSECURITY 40 and higher.
> The User that submits the job must have *USE authority to
> the *JOBD, and
> 
> The User that submits the job must have *USE authority to
> the *USRPRF
> that is named in the *JOBD.
> 
> The problem with your QCMDEXC scenario is that users can
> assume the
> identity of the user named in the *JOBD PRODJOBD.  You can
> put a stop to
> that with two simple steps
> 1) Raise your QSECURITY level to at least 40 (See the
> Security Reference
> Guide for specific instructions on auditing before the
> change)
> 2) Make sure no one (especially *PUBLIC) has more than
> *EXCLUDE
> authority to the User Profile named in the *JOBD (Or to
> any user profile
> for that matter)
> 
> The problem is not that programmers have the authority to
> CLRPFM, the
> problem is that they can assume the identity of another
> user that has
> authority CLRPFM on production data.
> 
> jte
> 
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.