CVE-2025-55113

BMC Control-M/Agent unescaped NULL byte in access control list checks

Severity: Critical (9.0)

If the Access Control List is enforced by the Control-M/Agent and the C router is in use (default in out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions; non-default but configurable using the JAVA_AR setting in newer versions), the verification stops at the first NULL byte encountered in the email address referenced in the client certificate. An attacker could bypass configured ACLs by using a specially crafted certificate.

A Control-M/Agent is only affected by this CVE if all of the following apply:

• The Agent is using SSL/TLS for communication with the Control-M/Server.
• The Agent is using the Access Control List (ACL) feature.
• If the Agent is version 9.0.21 and higher, the non-default JAVA_AR=N parameter is configured

1. Determine which Agents are using SSL/TLS:
   1. Open the Control-M Configuration Manager (CCM)
   2. If the SSL column is not currently showing, right click on any column header and select "Column chooser"
   3. From the Column chooser dialog, drag the "SSL" column into the columns view.
   4. Select each Control-M/Server in the tree on the left to view the Control-M/Agents in the middle pane
   5. In the "Type" column header, set the filter to "Control-M Agent"
   6. Sort by the SSL column and any Agents with SSL set to "Enabled" will need to be handled below
   7. To create a file with this list of Agents, select the dropdown on the top left next to Home, then select Exports List
2. Determine if the Access Control List (ACL) feature is used. Check the following file on all Agents found in Step 1:

   UNIX/Linux: <Agent Home Directory>/data/SSL/cert/access

   Windows: <Agent Home>\Control-M Agent\<Agent Name>\DATA\SSL\CERT\access

   The ALLOW_ACL and DENY_ACL

   • If ALLOW_ACL is set to an asterisk (*), and DENY_ACL is blank, then ACL is not used and this Agent is not affected.
   • If ALLOW_ACL or DENY_ACL contain email addresses, then ACL is used. Continue to the next step.

3. Check the default Agent settings.

   • Control-M/Agent versions 9.0.21 and higher:
     NOTE: the default value for JAVA_AR is Y and, unless previously advised by BMC to change it to N, the Agent is not affected and no further action is required.

     1. Run the following command as the Control-M/Agent user (Unix/Linux) or Command Prompt (Windows) to check the value for the parameter "JAVA_AR":
        ctmcfg -TABLE CONFIG -ACTION DISPLAY -PARAMETER JAVA_AR
        If set to Y, no further action is needed.
     2. If the "JAVA_AR" parameter is currently set to N:
        1. Upgrade the Control-M/Agent to 9.0.21.300 or higher. All known issues that required JAVA_AR=N are resolved in 9.0.21.300.
        2. Once the Agent is upgraded, backup the Agent's CONFIG.dat file
           1. Unix/Linux: $CONTROLM/data/CONFIG.dat
           2. Windows: <Agent install>\data\CONFIG.dat
        3. Change the value to Y by running the following command:
           ctmcfg -TABLE CONFIG -ACTION UPDATE -PARAMETER JAVA_AR -VALUE Y
        4. Recycle the Control-M/Agent to make the configuration change take effect.

   • Control-M/Agent versions 9.0.20 and lower:

     Primary Solution:

     Upgrade to a fully supported version of Control-M/Agent.
     BMC recommends the latest major version and fix pack available.
     The upgrade process will change the JAVA_AR to Y.

     
     

     Alternate Solution:

     1. Determine the Control-M/Agent keystore name and file type on each Agent.
        • UNIX/Linux:
          grep -i keyfile $CONTROLM/data/SSL/site.plc

        • Windows:
          reg query "HKLM\SOFTWARE\BMC Software\Control-M/Agent" /v keyfile /s

          If the "keyfile" points to a KDB file (e.g. agkey.kdb), then the keystore type is KDB, go to the next step.
          If the "keyfile" points to a PKCS#12 file (.pfx or .p12), then skip the next step and continue with the one after to remove third party certificates

     2. For Control-M/Agents that utilize the KDB keystore type, deploy a PKCS12 by following the procedure described in the documentation:
        NOTE: In step 7 in the below documentation, this only needs to be applied on the SSL/TLS and ACL Agents found in previous steps, not for Control-M/Enterprise Manager or Control-M/Server.

        https://documents.bmc.com/supportu/9.0.20/help/Main_help/en-US/index.htm#98210.htm

        Additional Information describing the process: https://youtu.be/3Jz-to-0e50?si=4nIJbPKpveouPTe0

     3. To remove all copies of third-party certificates from the existing PKCS#12 keystore, do one of the following:
        • Create a new keystore with only the certificates needed for Control-M/Server <-> Agent communication, following the best practices described in article 000442271
        • Backup the keystore file and run the following command on each Agent (keyfile is the keyfile parameter found above in site.plc or registry):
          1. keytool -list -keystore "<keyfile>" -storepass <password> -rfc
             A list of all keystore entries appears.
          2. Locate any aliases from the -list output.
             The only alias that should exist is "agdn".
          3. Make a backup copy of the the current keystore file.
          4. To delete any other aliases, run the following command:
             keytool -delete -keystore "<keyfile>" -storepass <password> -alias <alias to delete>
     4. Once the new PKCS#12 keystore has been deployed or the third-party certificates from the existing PKCS#12 keystore have been removed:
        Recycle the Control-M/Agent so it uses the new keystore.