3.2. Patching JBoss EAP 6
3.2.1. About Patching Mechanisms
Important
- 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.
Important
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.
3.2.2. Patching a Zip/Installer Installation
3.2.2.1. The Patch Management System
patch
command, or through the Management Console.
Important
Note
patch
command.
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. |
3.2.2.2. Installing Patches in Zip Form Using the Patch Management System
Prerequisites:
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
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
Procedure 3.1. Apply a zip patch to a JBoss EAP 6 server instance using the Management CLI
- Download the patch zip file from the Customer Portal at https://access.redhat.com/downloads/
- 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
Thepatch
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 availablepatch
command switches to re-run the command to resolve any conflicts. - 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
- Download the patch zip file from the Customer Portal at https://access.redhat.com/downloads/
- 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.
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.
Figure 3.2. The Patch Management view for a managed domain
- Click.
- If you are patching a managed domain host, on the next screen select whether to shutdown the servers on the host, and click.
- Click thebutton, select the downloaded patch you want to apply, and then click .
Figure 3.3. Apply Patch dialog
- 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 . Overriding conflicts will result in the content of the patch overriding any user modifications.
- 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.
The JBoss EAP 6 server instance is patched with the latest update.
3.2.2.3. Rollback the Application of a Patch in Zip Form Using the Patch Management System
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
Important
Prerequisites
- A patch that was previously applied using the JBoss EAP 6 patch management system.
- Access to the Management CLI or the Management Console for the JBoss EAP 6 server. See Launch the Management CLI or Log in to the Management Console in the Administration and Configuration Guide located on the Customer Portal at https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/?version=6.4.
Warning
Reset Configuration
option:
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.
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
- 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 thepatch info
output. - Individual security or bug fix patch IDs are listed as the value of the first
patches
shown in thepatch info
output, with the most recently applied individual patch listed first.
- 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
Thepatch
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 availablepatch
command switches to re-run the command to resolve any conflicts. - 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
- 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.
- In the Recent Patch History table, select the patch that you want to rollback, then click .
Figure 3.4. Recent Patch History table for Patch Management
- For a managed domain host, on the next screen select whether to shutdown the servers on the host, and click.
- Choose your options for the rollback process, then click.
Figure 3.5. Choose Options dialogue
- Confirm the options and the patch to be rolled back, then click.
- 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 and try the operation again with the Override all check box selected. Overriding conflicts will result in the rollback operation overriding any user modifications.
- 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.
The patch, and optionally also the server configuration files, are rolled back on the JBoss EAP 6 server instance.
3.2.2.4. Clearing Patch History
/core-service=patching:ageout-history
Important
3.2.3. Patching an RPM Installation
Prerequisites:
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
yum
.
Note
patch
command.
Warning
- 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.
- Read the errata for the security patch and confirm that it applies to a JBoss product in your environment.
- 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.
- Use
to install the patch.yum update
Important
When updating an RPM installation, your JBoss product is updated cumulatively with all RPM-released fixes.
The JBoss product is patched with the latest update using the RPM format.
3.2.4. Subscribe to Patch Mailing Lists
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
- Click the following link to go to the JBoss Watch mailing list page: JBoss Watch Mailing List.
- Enter your email address in the Subscribing to Jboss-watch-list section.
- [You can enter your name and select a password for yourself. Doing so is optional but recommended.]
- Press thebutton to start the subscription process.
- You can browse the archives of the mailing list by going to: JBoss Watch Mailing List Archives.
After confirmation of your email address, you will be subscribed to receive security related announcements from the JBoss patch mailing list.
3.2.5. Severity and Impact Rating 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.
|
Example 3.1. CVSS v2 Impact Score
C:N/I:P/A:C
3.2.6. Manage Security Updates for Dependencies Bundled Inside the Applications Deployed on JBoss EAP
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.