Carol describes what the QUSEADPAUT is and why you may want to use it.

Not too long ago, someone showed me an “exploit” that their auditor had devised that allowed him to take advantage of the adopted authority used by a vendor product. Concerned, the organization asked for my opinion on the issue. This article describes the issue raised by the auditor and the simple way IBM i provides to thwart it.

The Exploit

First, let me state that, in my opinion, no auditor could have randomly come up with this scenario because it involved a very deep understanding of both IBM i security and this particular vendor’s code (not a HelpSystems product, by the way). Clearly, the auditor had been given the explicit steps that enabled him to demonstrate this issue. The issue is that the vendor code was owned by and adopted a powerful profile. The owner of the product had all special authorities (*ALLOBJ, *AUDIT, *JOBCTL, *IOSYSCFG, *SAVSYS, *SECADM, *SERVICE, and *SPLCTL). In addition, the application programs were configured to adopt authority—that is, all of the application programs had been set to User profile *OWNER so that the owner’s authority could be used as long as one of these programs was active (still in the call stack.)

The exploit was to get a user-written program created with the same parameters as an application program and then compiled and inserted into a library in the library list higher in the library list than the application programs. When the application was run, the user-written program (aka trojan horse) was called prior to the real application program. Because the application adopted QSECOFR, the user-written program could do anything they wanted it to. OK. That sounds pretty bad, but, in reality, there’s one very simple way to shut down this vulnerability.

The Resolution

Enter the system value QUSEADPAUT. Let me explain. The only way this issue could be considered an “exploit” is due to the fact that, once a program that adopts is called, as long as the program remains in the call stack, the adopted authority (that is, the program owner’s authority) is available to subsequently called programs. The adopted authority is available to programs called after the original one due to the program attribute Use adopted authority being set to *YES. If this program attribute is set to *NO, adopted authority is not used within that program. The key to mitigating this exploit is to make sure only approved users can create programs and service programs with Use adopted authority set to *YES. How does one control that? By using the QUSEADPAUT system value. QUSEADPAUT takes, as input, the name of an authorization list. If a user has *USE or greater authority to the list named in QUSEADPAUT, then they can compile or change their programs and set the program attribute Use adopted authority to *YES. If they don’t have authority, when they compile their programs, regardless of the setting they specify for the Use adopted authority attribute, it will always be set to *NO. Nor can they change their programs and service programs to anything other than Use adopted authority *NO.

For most organizations, it’s quite easy to shut down this exploit, especially on production. They create an authorization list, specify the name in QUSEADPAUT system value, set the authorization list to *PUBLIC *EXCLUDE, and authorize the change management profile used for promoting program and service program objects to the list. That way, only the change management profile can create or change programs with the Use adopted authority attribute set to *YES. (Of course, anyone with *ALLOBJ inherently has authority to the authorization list.) Depending on the security model of your application, you may need to grant additional users authority to the authorization list on development partitions.

Additional Ways to Prevent the Abuse of Adopted Authority

Several additional ways to limit or eliminate the exploitation of adopted authority exist:

• Adopt only the power you need. If you’re writing a utility to manage user profiles, then yes, you may need to have the program’s owner have all special authorities. But it’s sufficient for most applications to have the same profile own all of the application objects. In other words, there’s no reason to have the application owner have *ALLOBJ. I encourage our clients to have applications be owned by a profile with no special authorities. This way, if anything is exploited, it’s contained to the objects owned by the application owning profile and not the entire system as is the case when the application owner has *ALLOBJ.
• Make library-qualified calls. This is a controversial but highly effective way to avoid the adopted authority exploit described above. Developers are loath to make library-qualified program calls (for example, CALL PRODLIB/PGM1). That’s because it greatly reduces the flexibility of having multiple program/test/ production environments. However, if a program is coded to call a program out of a specific library rather than coding it to call from the first one it finds in the library list, then there’s no opportunity to have a trojan horse called rather than the application program.
• Create a baseline of the programs currently adopting and review new ones that are created or restored. I recommend that you focus on the programs that are owned by and adopt a profile that has *ALLOBJ.
• Make sure all libraries are *PUBLIC *USE, especially for libraries in the system portion of the library list. You must have *CHANGE authority to a library to create or move an object into a library. If a person can’t get a program added to a library ahead of the application library in the library list, this exploit goes nowhere.

Summary

I hope that you’ve found this discussion helpful and that you’ll consider whether it’s appropriate to use the QUSEADPAUT system value in your own environment.