Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

3.2. Patching JBoss EAP 6

3.2.1. About Patching Mechanisms

JBoss patches are distributed in two forms: zip (for all products) and RPM (for a subset of products).

Important

A JBoss product installation must always only be updated using one patch method: either zip or RPM patches. Only security and cumulative patches will be available via RPM, and customers using an RPM installation will not be able to update using zip patches.
JBoss patches can be either an asynchronous update, or a planned update:
  • Asynchronous updates: Individual patches which are released outside the normal update cycle of the existing product. These may include security patches, as well as other individual patches provided by Red Hat Global Support Services (GSS) to fix specific issues.
  • Planned updates: The cumulative patches of an existing product, which includes all previously developed updates for that version of the product.
Deciding whether a patch is released as part of a planned update or an asynchronous update depends on the severity of the issue being fixed. An issue of low impact is typically deferred, and is resolved in the next cumulative patch or minor release of the affected product. Issues of moderate or higher impact are typically addressed in order of importance as an asynchronous update to the affected product, and contain a fix for only a specific issue.
Security updates for JBoss products are provided by an erratum (for both zip and RPM methods). The erratum encapsulates a list of the resolved flaws, their severity ratings, the affected products, textual description of the flaws, and a reference to the patches. Bug fix updates are not announced via an erratum.

Important

It is important to note that after a patch has been applied, the jars picked up at runtime are picked up from the EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE directory. The original files are left in EAP_HOME/modules/system/layers/base/$MODULE. The patching mechanism cripples the original jar files for security reasons. This means that if you apply a patch which updates a module, the original module's jar files are altered to be unusable. If the patch is rolled back, the original files will be reverted back to a usable state. This also means that the proper rollback procedure must be used to rollback any applied patch. See Section 3.2.2.3, “Rollback the Application of a Patch in Zip Form Using the Patch Management System” for the proper rollback procedure.
For more information on how Red Hat rates JBoss security flaws, refer to: Section 3.2.5, “Severity and Impact Rating of JBoss Security Patches”
Red Hat maintains a mailing list for notifying subscribers about security related flaws. See Section 3.2.4, “Subscribe to Patch Mailing Lists”
Report a bug

3.2.2. Patching a Zip/Installer Installation

3.2.2.1. The Patch Management System

The JBoss EAP 6 patch management system is used to apply downloaded ZIP patches to a single JBoss EAP 6 standalone server or domain host. It can be accessed either through the Management CLI by using the patch command, or through the Management Console.
The patch management system cannot be used to automatically patch JBoss EAP 6 hosts across a Managed Domain, but hosts in a Managed Domain can be patched individually. When you patch a managed domain host, all JBoss EAP servers on that host will be updated with the patch. When patching a JBoss EAP managed domain, the domain controller must be patched first.

Important

JBoss EAP 6 server instances which have been installed using the RPM method cannot be updated using the patch management system. See Section 3.2.3, “Patching an RPM Installation” to update RPM-installed JBoss EAP 6 servers.

Note

The patch management system can only be used with patches produced for versions of JBoss EAP 6.2 and later. For patches for versions of JBoss EAP prior to 6.2, you should instead refer to the relevant version's documentation available at https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/.
In addition to applying patches, the patch management system can provide basic information on the state of installed patches, and also provides a way to immediately rollback the application of a patch.
When applying or rolling back a patch, the patch management system will check the modules and other miscellaneous files that it is changing for any user modifications. If a user modification is detected, and a conflict-handling switch has not been specified, the patch management system will abort the operation and warn that there is a conflict. The warning will include a list of the modules and other files that are in conflict. To complete the operation, it must be retried with a switch specifying how to resolve the conflict: either to preserve the user modifications, or to override them.
The table below lists the arguments and switches for the Management CLI patch command.

Table 3.1. patch Command Arguments and Switches

Argument or Switch Description
apply Applies a patch.
--override-all If there is a conflict, the patch operation overrides any user modifications.
--override-modules If there is a conflict as a result of any modified modules, this switch overrides those modifications with the contents of the patch operation.
--override=path(,path) For specified miscellaneous files only, this will override the conflicting modified files with the files in the patch operation.
--preserve=path(,path) For specified miscellaneous files only, this will preserve the conflicting modified files.
--host=HOST_NAME Available for Managed Domain servers, this specifies the host that the patch operation will be performed on.
info
Returns information on currently installed patches.
You can optionally provide --patch-id=PATCH_ID -v for detailed information for a specific patch, including layer/add-on patches.
inspect Inspects a downloaded patch file and returns important information about the patch.
history Returns information on the patching history.
rollback Rollsback the application of a patch.
--patch-id=PATCH_ID Required for rollback, the ID of the patch to rollback.
--reset-configuration=TRUE|FALSE Required for rollback, this specifies whether to restore the server configuration files as part of the rollback operation.
--rollback-to If the patch to rollback is an individual (one-off) patch, using this argument specifies that the rollback operation will also rollback all other one-off patches that have been applied on top of the specified patch.
Report a bug

3.2.2.2. Installing Patches in Zip Form Using the Patch Management System

Prerequisites:

Summary

Patches that are in the zip format can be installed using the JBoss EAP 6 patch management system via either the Management CLI or the Management Console.

Important

The patch management system is a feature that was added in JBoss EAP 6.2. For versions of JBoss EAP prior to 6.2, the process to install patches in zip form is different, and you should instead refer to the relevant version's documentation available at https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/.

Prerequisites

  • Valid access and subscription to the Red Hat Customer Portal.
  • A current subscription to a JBoss product installed in zip format.
  • Access to either the Management CLI or the Management Console for the JBoss EAP 6 server to be updated. Refer to either the Log in to the Management Console or Launch the Management CLI chapters of the Administration and Configuration Guide for instructions on accessing these interfaces.

Warning

Before installing a patch, you should backup your JBoss product along with all customized configuration files.

Procedure 3.1. Apply a zip patch to a JBoss EAP 6 server instance using the Management CLI

  1. Download the patch zip file from the Customer Portal at https://access.redhat.com/downloads/
  2. From the Management CLI, apply the patch with the following command including the appropriate path to the patch file: 
    patch apply /path/to/downloaded-patch.zip
    The patch tool will warn if there are any conflicts in attempting the apply the patch. Refer to Section 3.2.2.1, “The Patch Management System” for available patch command switches to re-run the command to resolve any conflicts.
  3. Restart the JBoss EAP 6 server for the patch to take effect: 
    shutdown --restart=true

Procedure 3.2. Apply a zip patch to a JBoss EAP 6 server instance using the Management Console

  1. Download the patch zip file from the Customer Portal at https://access.redhat.com/downloads/
  2. Navigate to the Patch Management View:
    • For a standalone server, in the Management Console, click on the Administration tab at the top of the screen, then click Patch Management.
      Description

      Figure 3.1. The Patch Management view for a standalone server

    • For a managed domain, in the Management Console, click on the Administration tab at the top of the screen, then click Patch Management. Select the host you want to patch from the Host table, then click View.
      Description

      Figure 3.2. The Patch Management view for a managed domain

  3. Click Apply a New Patch.
    1. If you are patching a managed domain host, on the next screen select whether to shutdown the servers on the host, and click Next.
  4. Click the Browse button, select the downloaded patch you want to apply, and then click Next.
    Description

    Figure 3.3. Apply Patch dialog

    1. If there are any conflicts in attempting to apply the patch, a warning will be displayed. Click View error details to see the detail of the conflicts. If there is a conflict, you can either cancel the operation, or select the Override all conflicts check box and click Next. Overriding conflicts will result in the content of the patch overriding any user modifications.
  5. After the patch has been successfully applied, select whether to restart the JBoss EAP 6 server now for the patch to take effect, and click Finish.
Result

The JBoss EAP 6 server instance is patched with the latest update.

Report a bug

3.2.2.3. Rollback the Application of a Patch in Zip Form Using the Patch Management System

Summary

The JBoss EAP 6 patch management system can be used to rollback the application of a previously applied zip patch, via either the Management CLI or the Management Console.

Warning

Rolling back the application of a patch using the patch management system is not intended as a general uninstall functionality. It is only intended to be used immediately after the application of a patch which had undesirable consequences.

Important

The patch management system is a feature that was added in JBoss EAP 6.2. For versions of JBoss EAP prior to 6.2, the process to rollback patches in zip form is different, and you should instead refer to the relevant version's documentation available at https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/?version=6.4.

Prerequisites

Warning

When following either procedure, use caution when specifying the value of the Reset Configuration option:
If set to TRUE, the patch rollback process will also rollback the JBoss EAP 6 server configuration files to their pre-patch state. Any changes that were made to the JBoss EAP 6 server configuration files after the patch was applied will be lost.
If set to FALSE, the server configuration files will not be rolled back. In this situation, it is possible that the server will not start after the rollback, as the patch may have altered configurations, such as namespaces, which may no longer be valid and have to be fixed manually.

Procedure 3.3. Rollback a patch from a JBoss EAP 6 server instance using the Management CLI

  1. From the Management CLI, use the patch info command to find the ID of the patch that is to be rolled back.
    • For cumulative patches, the patch ID is the value of the first cumulative-patch-id shown in the patch info output.
    • Individual security or bug fix patch IDs are listed as the value of the first patches shown in the patch info output, with the most recently applied individual patch listed first.
  2. From the Management CLI, rollback the patch with the appropriate patch ID from the previous step. 
    patch rollback --patch-id=PATCH_ID --reset-configuration=TRUE
    The patch tool will warn if there are any conflicts in attempting the rollback the patch. Refer to Section 3.2.2.1, “The Patch Management System” for available patch command switches to re-run the command to resolve any conflicts.
  3. Restart the JBoss EAP 6 server for the patch rollback to take effect: 
    shutdown --restart=true

Procedure 3.4. Rollback a patch from a JBoss EAP 6 server instance using the Management Console

  1. In the Management Console:
    • For a standalone server: click on the Administration tab at the top of the screen, then click Patch Management.
    • For a managed domain: click on the Administration tab at the top of the screen, then click Patch Management. From the Patch Management table, select the relevant host, then click View.
  2. In the Recent Patch History table, select the patch that you want to rollback, then click Rollback.
    Description

    Figure 3.4. Recent Patch History table for Patch Management

    1. For a managed domain host, on the next screen select whether to shutdown the servers on the host, and click Next.
  3. Choose your options for the rollback process, then click Next.
    Choose Options dialogue

    Figure 3.5. Choose Options dialogue

  4. Confirm the options and the patch to be rolled back, then click Next.
    1. If the Override all option was not selected and there are any conflicts in attempting to rollback the patch, a warning will be displayed. Click View error details to see the detail of the conflicts. If there is a conflict, you can either cancel the operation, or click Choose Options and try the operation again with the Override all check box selected. Overriding conflicts will result in the rollback operation overriding any user modifications.
  5. After the patch has been successfully rolled back, select whether to restart the JBoss EAP 6 server now for the changes to take effect, and click Finish.
Result

The patch, and optionally also the server configuration files, are rolled back on the JBoss EAP 6 server instance.

Report a bug

3.2.2.4. Clearing Patch History

When patches are applied to a JBoss EAP 6 server, the content and history of the patches are preserved for use in rollback operations. If multiple cumulative patches are applied, the patch history may use a significant amount of disk space.
You can use the Management CLI command below to remove all older patches that are not currently in use. When using this command, only the latest cumulative patch is preserved along with the GA release. This is only useful for freeing space if multiple cumulative patches have previously been applied. 
/core-service=patching:ageout-history

Important

If you clear the patch history, you will not be able to rollback a previously applied patch.
Report a bug

3.2.3. Patching an RPM Installation

Prerequisites:

Summary

JBoss patches are distributed in two forms: ZIP (for all products) and RPM (for a subset of products). This task describes the steps you need to take to install the patches via the RPM format.

Prerequisites

  • A valid subscription to the Red Hat Network.
  • A current subscription to a JBoss product installed via an RPM package.

Procedure 3.5. Apply a patch to a JBoss product via the RPM method

Security updates for JBoss products are provided by errata (for both zip and RPM methods). The errata encapsulates a list of the resolved flaws, their severity ratings, the affected products, textual description of the flaws, and a reference to the patches.
For RPM distributions of JBoss products, the errata include references to the updated RPM packages. The patch can be installed by using yum.

Note

Only zip installations allow for patching using the Management Console or Management CLI patch command.

Warning

Before installing a patch, you must backup your JBoss product along with all customized configuration files.
  1. Get notified about the security patch either via being a subscriber to the JBoss watch mailing list or by browsing the JBoss watch mailing list archives.
  2. Read the errata for the security patch and confirm that it applies to a JBoss product in your environment.
  3. If the security patch applies to a JBoss product in your environment, then follow the link to download the updated RPM package which is included in the errata.
  4. Use 
    yum update
    to install the patch.

    Important

    When updating an RPM installation, your JBoss product is updated cumulatively with all RPM-released fixes.
Result

The JBoss product is patched with the latest update using the RPM format.

Report a bug

3.2.4. Subscribe to Patch Mailing Lists

Summary

The JBoss team at Red Hat maintains a mailing list for security announcements for Red Hat JBoss Middleware products. This section covers what you need to do to subscribe to this list.

Prerequisites

  • None

Procedure 3.6. Subscribe to the JBoss Watch List

  1. Click the following link to go to the JBoss Watch mailing list page: JBoss Watch Mailing List.
  2. Enter your email address in the Subscribing to Jboss-watch-list section.
  3. [You can enter your name and select a password for yourself. Doing so is optional but recommended.]
  4. Press the Subscribe button to start the subscription process.
  5. You can browse the archives of the mailing list by going to: JBoss Watch Mailing List Archives.
Result

After confirmation of your email address, you will be subscribed to receive security related announcements from the JBoss patch mailing list.

Report a bug

3.2.5. Severity and Impact Rating of JBoss Security Patches

To communicate the risk of each JBoss security flaw, Red Hat uses a four-point severity scale of low, moderate, important and critical, in addition to Common Vulnerability Scoring System (CVSS) version 2 base scores which can be used to identify the impact of the flaw.

Table 3.2. Severity Ratings of JBoss Security Patches

Severity Description
Critical
This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as critical impact.
Important
This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow local or remote users to cause a denial of service.
Moderate
This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a critical impact or important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
Low
This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.
The impact component of a CVSS v2 score is based on a combined assessment of three potential impacts: Confidentiality (C), Integrity (I) and Availability (A). Each of these can be rated as None (N), Partial (P) or Complete (C).
Because the JBoss server process runs as an unprivileged user and is isolated from the host operating system, JBoss security flaws are only rated as having impacts of either None (N) or Partial (P).

Example 3.1. CVSS v2 Impact Score

The example below shows a CVSS v2 impact score, where exploiting the flaw would have no impact on system confidentiality, partial impact on system integrity and complete impact on system availability (that is, the system would become completely unavailable for any use, for example, via a kernel crash). 
C:N/I:P/A:C
Combined with the severity rating and the CVSS score, organizations can make informed decisions on the risk each issue places on their unique environment and schedule upgrades accordingly.
For more information about CVSS2, please see: CVSS2 Guide.
Report a bug

3.2.6. Manage Security Updates for Dependencies Bundled Inside the Applications Deployed on JBoss EAP

Red Hat provides security patches for all components that are part of the JBoss EAP distribution. However, many users of JBoss EAP deploy applications which bundle their own dependencies, rather than exclusively using components provided as part of the JBoss EAP distribution. For example, a deployed WAR file may include dependency JARs in the WEB-INF/lib/ directory. These JARs are out of scope for security patches provided by Red Hat. Managing security updates for dependencies bundled inside the applications deployed on JBoss EAP is the responsibility of the applications' maintainers. The following tools and data sources may assist in this effort, and are provided without any support or warranty.

Tools and Data Sources

JBoss patch mailing lists
Subscribing to the JBoss patch mailing lists will keep you informed regarding security flaws that have been fixed in JBoss products, allowing you to check whether your deployed applications are bundling vulnerable versions of the affected components.
Security advisory page for bundled components.
Many open source components have their own security advisory page. For example, Struts 2 is a commonly-used component with many known security issues that is not provided as part of the JBoss EAP distribution. The Struts 2 project maintains an upstream security advisory page, which should be monitored if your deployed applications bundle Struts 2. Many commercially-provided components also maintain security advisory pages.
Regularly scan your deployed applications for known vulnerabilities
There are several commercial tools available to do this. There is also an open source tool called Victims, which is developed by Red Hat employees, but comes with no support or warranty. Victims provides plugins for several build and integration tools, which automatically scan applications for bundling known-vulnerable dependencies. Plugins are available for Maven, Ant and Jenkins. For more information about the Victims tool, see https://victi.ms/about.html.
Report a bug