Restricting remote program execution

One of the major goals for an attacker attempting to exploit a system is to gain the ability to execute arbitrary program code remotely. Unfortunately, as an application server, Enterprise Server is designed and intended to do precisely that: enable the remote execution of programs. So restricting which programs can be executed, and access to those programs, is a key aspect of hardening Enterprise Server.

There are two main contexts in which Enterprise Server executes arbitrary (customer-supplied) programs:

  1. Conventional COBOL applications might be exposed as Web services and Enterprise JavaBeans (EJBs) when an enterprise server region is used to support the COBOL service-oriented architecture.
  2. Under the Mainframe Subsystem Support (MSS) feature, programs written in COBOL, PL/I, Mainframe Assembler, and REXX, and scripts written in JCL can be executed by the Enterprise Server CICS, JES, and IMS subsystems.

In either context, there are three main avenues for hostile remote program execution:

  1. Hostile code is deployed as part of a legitimate application, through an authorized process for deploying applications to Enterprise Server. This might be done by an organization's employee (for example, a developer), or through a supply chain attack in which an attacker gains access to the application source code or the build or deployment pipeline. This document does not cover this category of threats in detail, but there are some notes below.
  2. An existing legitimate application is abused. This can be mitigated by improving application security, which is also out of scope for this document, and restricting illegitimate access to applications.
  3. An attacker is able to deploy a hostile application to an enterprise server region. This differs from a conventional supply chain attack in that the attacker is not subverting a legitimate application, but deploying an entirely new one. In some cases this can use an organization's approved deployment mechanism; in others, it might use an alternative mechanism.

Improving application security to protect against remote code execution

Application security can cover many aspects, but particular attention should address the following potential vulnerabilities:

  • Executing external programs using CALL "SYSTEM", pipe syntax with file I/O, and so forth.
  • Dynamic loading of program objects using the CALL statement, when the name of the program or path information might be controlled by an attacker. Watch for CALL statements using a data-item rather than a literal for the program name. Entry-point name mapping is also a potential vector. For CICS programs, watch for dangerous use of EXEC CICS LINK and EXEC CICS XCTL.

Restricting access to existing applications and programs

Ways to control access to applications hosted in an enterprise server instance include:

  • Application security features, such as requiring user sign-on and enforcing authorized access internally. This is outside the scope of this document.
  • Resource access control rules in the security configuration. This only applies to MSS applications; COBOL Web services and EJBs do not currently make use of external security. Resource classes that apply here include the TCICSTRN and MCICSPCT classes for CICS and the TIMS class for IMS. Unfortunately, there is no equivalent resource checks for JES, but access to job submission can be controlled using the JESINPUT class.
  • Communications security. Since remote program execution requires network communications, the vulnerability can be partly mitigated by restricting how attackers can connect to the region. This includes restricting which interfaces listeners use, using conversation filtering, and using TLS with client authentication. Communications can also be secured after a connection is made, for example, by requiring sign-on after connecting over TN3270.

Job submission to the JES engine is a particularly dangerous vulnerability for any enterprise server region which has JES enabled. The problem is that any user authorized to submit a job can run arbitrary programs, as long as they are found on the region's program path and have appropriate permissions for the system account under which Enterprise Server is running; and those programs can access any files on the system with the permissions of that account by using PCDSN syntax.

Features for restricting access to JCL submission are not entirely satisfactory. Micro Focus recommends the following:

  • Set the environment variable CASRDO44_NEWSUB=OFF. This will prevent submitting local JCL through ESCWA or ESMAC. These Web interfaces will only allow you to submit JCL by reference, that is JCL which already exists on the server system. This prevents one method of submitting arbitrary JCL. There is no practical way to prevent submitting arbitrary JCL remotely using cassub or similar.
  • Use rules of the form SUBMIT.region.jobname.userid in the JESJOBS class to restrict which users can submit which jobs.
  • Consider using JESINPUT or TSUINRDR to restrict job submission to only a single userid, then configure MFBSI to use that userid. This will force all job submission to occur through a scheduler, which could perform additional checks.
  • It would also be possible to use JESINPUT or TSUINRDR to disallow direct submission entirely, then submit JCL only through CICS or IMS (controlled by STCINRDR) and other JCL jobs (INTRDR). Then access to job submission could be controlled by CICS or IMS applications.

For CICS, prevent unauthorized users from adding CICS resource definitions, either through the administration user interfaces or by using CICS system APIs, as discussed in previous sections. This will mitigate against attackers executing existing programs by creating CICS transactions for them, or by specifying them as queue trigger programs, and so forth.

Disable or restrict access to the CRUN CICS transaction, which executes an arbitrary program.

Preventing the deployment of hostile applications

This vulnerability applies primarily to the COBOL Web service and EJB feature of Enterprise Server, and specifically to the remote-deployment feature. Remote deployment is convenient for developers, but should always be disabled in a production environment. It is an extremely dangerous vulnerability, because in the default configuration (once enabled) it lets anyone install any program under an enterprise server region.

If deployment is enabled, additional security measures can be configured for it. See Security Considerations for Service Interface Deployment in your product Help for more information.

Parent topic: Hardening enterprise server region