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.
Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.
Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.
MC Press books written by Carol Woodbury available now on the MC Press Bookstore.
 |
||
 |
|
IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
|
 |
|
IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
|
|
||
 |
|
IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online