SecureMyi.com Security and Systems Management Newsletter for the IBM i                 October 9, 2013 - Vol 3, Issue 37
Security Training from SecureMyi.com
Security software from Powertech

Security? See how SKYVIEW PARTNERS can help!

iSecurity from SEA







Library and Object Vulnerabilities when using
Adoption of Authority and Swap User Profile APIs

By Dan Riehl

Each job has an associated list of libraries called the job's library list or, as is often seen, *LIBL. When an object is requested during the job, the library list is searched, in order, to locate the object. There are several distinct portions of the library list: the System Portion, The Current Library, the Product Portion and the User Portion.

You can see the library list for your current job by using the command DSPLIBL (Display Library List), as shown here.

               Display Library List                              
                                               System:   SECUREMYI 
                                                                                
  Type options, press Enter.                                                     
   5=Display objects in library                                                 
                                                                                
  Opt       Library          Type    Text                                                
   _        ALTQSYS          SYS     Alternate QSYS library            
   _        QSYS             SYS     System Library                                      
   _        QSYS2            SYS     System Library for CPI's                            
   _        QHLPSYS          SYS                                                           
   _        QUSRSYS          SYS                                                           
   _        QPDA             PRD                                                           
   _        DRIEHL           CUR     Dan Riehl test library                              
   _        QGPL             USR     General Purpose Library                             
   _        QTEMP            USR

The libraries in the System Portion (SYS) are controlled by the system administrator and are stored as the System Value QSYSLIBL. The Current Library (CUR) is specified in the User Profile of the user who started the job and can be changed dynamically by using the command CHGCURLIB (Change Current Library). The Product Portion (PRD) is dependent on applications that are currently running, and as such is dynamic within the job. The User Portion (USR) is controlled by the System Value QUSRLIBL but is often overridden by a Job Description or initial program that sets the User Portion as needed for the application.

Changing the Library List

There are many commands that are used to manipulate the library list. You can add and remove libraries by using CL commands such as EDTLIBL (Edit Library List), ADDLIBLE (Add Library List Entry) and RMVLIBLE (Remove Library List Entry).

Authority to Libraries on the Library List

When a job starts, the initial library list for the job is loaded, and the authority that the user has to each library in the list is retrieved and stored with the job's library list information. When a library is added to the list, its authority is also saved in the job's library list information.

The user's authority to the library, having already been resolved, remains consistent throughout the life of the job. This is true even if the user's authority to the library is changed or revoked during the job.

When an unqualified reference is made to an object, as in the Display File commands shown here:

DSPF FILE(MYFILE)     or     DSPF FILE(*LIBL/MYFILE)

the stored library list authority information is used. A new authority lookup is not performed when the library is already on the library list.

If a qualified object reference is made, as in DSPF FILE(MYLIBRARY/MYFILE), an authority lookup is performed, even if the library is on the job's library list.

Adding Libraries During Adopted Authority or Job User Profile Swap

If a program that adopts authority adds a library to the library list, the authority information stored with the library list information will be set according to the adopted authority and not necessarily according to the Job User's own authority.

The same is true for Job User Profile Swap operations using the Security Profile Handle APIs. If you swap to a different profile and then add a library to the library list, the authority information stored for your job will be as it is for the Swapped-To user and not for the Job User.

The Library and Object Vulnerabilities

So, even if you have *EXCLUDE rights to a library (no access allowed), the library can be added to your library list by an adopting program or during a Swap User Profile activity. Even after you return from the Swap Profile activity or exit out of the adopting program, the library will remain on your library list with a designation that you have *USE, *CHANGE, or even *ALL authority to the library. And since the library is already on your list, the authority to the library will not be checked again and will remain the same until you sign off.

Here is a common scenario. It might not be exactly like yours, but I think it will make the point.

Here, we assume that *PUBLIC has *EXCLUDE authority to the production libraries that make up the business applications. We further assume that IT staff fall under the category *PUBLIC for these production libraries. IT has no access to production libraries, except through a special menu option.

IT staff and others log on and are presented with their Main Menu. Option 5 from the menu takes the user to the "Production Environment." The Option 5 program is a CL program that adopts the authority of the Application Owner profile. The program adds the production data libraries and production program libraries to the library list. Because the Application Owning profile has *ALL authority to the libraries, they are added to the job's library list, and the stored information specifies that my job has *ALL authority to the production libraries. When Option 5 ends, it does not remove the production libraries from the library list. My authority to the libraries has already been resolved.

After doing my chores in the production environment with Option 5, I return to my Main Menu. I now have a resolved *ALL authority to the production libraries, sitting at a command line. Because almost all files in secured production libraries are secured only at the library level, with files and other data objects created with *PUBLIC AUT(*CHANGE), I can use my favorite file editor to edit the files and can view anything and change anything.

I made a statement that I probably need to explain: "Almost all files - are created *PUBLIC AUT(*CHANGE)." For over 25 years, I have been a contract programmer, consultant, and security specialist. I have been down in the guts of hundreds of production machines and performed countless IBM i vulnerability and security assessments. If there is any object security in place, it is almost always at the library level and at the library level only. A library may be secured by an authorization list, but the authority on the objects within the library are almost always haphazard and inconsistent. If there is any consistency at the object level, it is that almost all files have a *PUBLIC authority of *CHANGE.

Yes, there are exceptions to this statement, plenty of them. You may have great object security. But, generally speaking, if we, the IBM i community, have any security in place, it is at the library level, which makes this vulnerability that much more disturbing.

Testing and Observing the Vulnerability

I ran several tests on this vulnerability to determine the exact consequences. I find that when I use some CL commands (e.g., DSPFD, DSPFFD) to access the objects in the secure library, the vulnerability is not evident and I receive the "Not Authorized" message. But with many other CL commands I tested, the vulnerability is very evident, and I was able to access secure data. I am not sure what the determining factors are, or the differences in why certain CL commands resolve object/library references differently than others do.

There seemed to be no difference in whether I added the library through an adopting program or through a swap user session; the results were consistent.

I added a secure library AUT(*EXCLUDE) to my library list within an adopting program. When the program finished, I examined my library list to confirm that the library to which I had no authority was on my jobs library list. Adopted authority, and program swaps were all ended before I began analyzing the results.

When I ran the following few commands, I received the message that I was not authorized to the library.

CRTDUPOBJ OBJ(ALLUSERS) FROMLIB(*LIBL) OBJTYPE(*FILE)
CPYF FROMFILE(ALLUSERS) TOFILE(ALLUSERS2) MBROPT(*ADD) CRTFILE(*YES)
DSPFD (*LIBL/ALLUSERS)
DSPFFD (*LIBL/ALLUSERS)
DSPPGM PGM(*LIBL/TEST88)

When I ran the following commands, I was able to successfully access and manipulate objects, even though I had no authority to the library in which the objects existed. Each command was specified with *LIBL for the object library.

DSPDTAARA
CHGDTAARA
CHKOBJ ... AUT(*CHANGE)
DSPPFM
DSPF

I was able to successfully call a program in the secure library and was also able to open a database file in the secure library from within a CL program.

What Can I Do About It?

This "feature" of IBM i creates potentially disastrous vulnerabilities. We need to be aware of this problem and examine adopting programs to ensure that they do not add libraries to the library list, and if they need to add a library, make sure that the libraries are removed before exiting the adopting programs. But, as we are well aware, if we cancel an interactive program before it ends (SYSREQ 2, CNLRQS), the libraries will not be removed.

Here's a short list of actions that you can take to start removing this library list vulnerability:

  • Understand your applications, and how the library list is maintained and modified.
  • Check your adopting programs. Use the commands DSPPGMADP (Display Program Adopt) or PRTADPOBJ (Print Adopting Objects) to track down the adopting programs.
  • Many of your adopting programs will be from software vendors; skip those for now and focus on the home-grown ones that you can control.
  • Scan your source code for library list manipulation commands. FNDSTRPDM (Find String using PDM) is a great command for this type of scan.
  • Check the associated program objects to see whether they adopt authority.
  • Just because this one program may not adopt authority does not mean that the program is not run while adopted authority is active.
  • Remove command line access from as many user profiles as is possible and practical.

I hope that this information will be helpful to you as you manage and control your systems. System security and integrity should be a top priority in these days of ever increasing scrutiny and regulation.



Training from The 400 School

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn

   
      Security Services from SecureMyi.com