Feature Article

Checkup - CL Command Security Vulnerabilities

By Carsten Flensburg

Editors Note: This is an encore presentation of this great security utility(source code provided). The utility, written by Carsten Flensburg, is a "must have" for anyone serious about security assessment for IBM i. Oh--And as you'll see, Carsten's code is GREAT!

The IBM i Operating System includes several hundred Control Language(CL) commands, many of which provide access to critical and sensitive system and security functions. IBM puts a lot of effort into restricting access to these commands by setting public authority adequately and, if necessary, requires additional user profile special authority in order to successfully execute sensitive commands.

The command’s public or private authority could however for some reason be changed at a later point and so could the command’s Allow limited user attribute, which normally excludes end-users from running most CL commands. Add to this the number of user created commands and 3rd party vendor supplied commands that exist on most systems and you’re looking at quite a challenge in order to manage, monitor and audit access to the CL commands.

Are the CL Commands Created by IBM?

We often assume that all commands in the main operating system library QSYS were supplied to us by IBM. But, how can you be sure? User created commands possibly masquerading as legitimate IBM supplied commands may be implementing malware on your system. WRKCMDSEC can help you detect commands that were not created by IBM.

And the Validity Checking Program(VCP)?

Another area of Security/Audit concern is that a Validity Checking Program(VCP) may have been added to an IBM or Vendor supplied command. This method is used by some to enforce additional command rules or to add some additional logic to a CL command when it is used. A Validity Checking Program may also be used as an insertion point for potential malware.

The WRKCMDSEC command can help you determine if a command has a Validity Checking Program.

Commands for Limited Users

Each CL command(*CMD) definition contains an attribute named ALWLMTUSR(Allow Limited User) that determines if the command can be run at a command line by users that have been created as Limited Capabilities Users (i.e. LMTCPB(*YES)).

IBM ships certain non-intrusive commands like DSPMSG(Display Message) and DSPJOBLOG(Display Job log) as ALWLMTUSR(*YES), thereby allowing Limited Capabilities users to run these commands at a command line. But, for protection, IBM ships almost all CL commands with the setting ALWLMTUSR(*NO), in which Limited Capabilities Users cannot run the commands at a command line.

CL Commands like DLTLIB(Delete Library) and DLTF(Delete File) would be very dangerous in the hands of an end-user, but thankfully these are two of the commands that are shipped from IBM with the attribute ALWLMTUSR(*NO). For more information on the Misconceptions on User Limited Capabilities and Command Line access, see Dan Riehl's article in the July 10, 2012 issue of the SecureMyi Newsletter.

When it comes to a command's Allow Limited User attribute, there are occasions when a software vendor will ship you commands that allow limited users to use those commands. I have also seen occasions when a system administrator has changed the attribute on certain IBM and other vendor supplied commands to enable otherwise restricted users to run these commands at a command line. These commands may cause vulnerabilities when you rely upon a user's command line restriction to prevent them from running CL commands at a command line. Commands that are specified as ALWLMTUSR(*YES) CAN be run by a user that is command line restricted.

Read More and Download the Code