-----BEGIN PGP SIGNED MESSAGE-----
AUSCERT External Security Bulletin Redistribution
Important: Red Hat JBoss BRMS 5.3.1 update
2 July 2013
AusCERT Security Bulletin Summary
Product: Red Hat JBoss BRMS
Publisher: Red Hat
Operating System: Windows
UNIX variants (UNIX, Linux, OSX)
Impact/Access: Provide Misleading Information -- Remote with User Interaction
Reduced Security -- Remote/Unauthenticated
Unauthorised Access -- Remote with User Interaction
CVE Names: CVE-2012-5887 CVE-2012-5886 CVE-2012-5885
CVE-2012-5783 CVE-2012-5575 CVE-2011-2487
Comment: This advisory references vulnerabilities in products which run on
platforms other than Red Hat. It is recommended that administrators
running Red Hat JBoss BRMS check for an updated version of the
software for their operating system.
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Red Hat Security Advisory
Synopsis: Important: Red Hat JBoss BRMS 5.3.1 update
Advisory ID: RHSA-2013:1006-01
Product: Red Hat JBoss Middleware
Advisory URL: https://rhn.redhat.com/errata/RHSA-2013-1006.html
Issue date: 2013-07-01
CVE Names: CVE-2012-5575 CVE-2012-5783 CVE-2012-5885
Red Hat JBoss BRMS 5.3.1 roll up patch 2, which fixes multiple security
issues and various bugs, is now available from the Red Hat Customer Portal.
The Red Hat Security Response Team has rated this update as having
important security impact. Common Vulnerability Scoring System (CVSS) base
scores, which give detailed severity ratings, are available for each
vulnerability from the CVE links in the References section.
Red Hat JBoss BRMS is a business rules management system for the
management, storage, creation, modification, and deployment of JBoss Rules.
This roll up patch serves as a cumulative upgrade for Red Hat JBoss BRMS
5.3.1. It includes various bug fixes. The following security
issues are also fixed with this release:
XML encryption backwards compatibility attacks were found against various
frameworks, including Apache CXF. An attacker could force a server to use
insecure, legacy cryptosystems, even when secure cryptosystems were enabled
on endpoints. By forcing the use of legacy cryptosystems, flaws such as
CVE-2011-1096 and CVE-2011-2487 would be exposed, allowing plain text to be
recovered from cryptograms and symmetric keys. This issue affected both the
JBoss Web Services CXF (jbossws-cxf) and JBoss Web Services Native
(jbossws-native) stacks. (CVE-2012-5575)
If you are using jbossws-cxf, then automatic checks to prevent this flaw
are only run when WS-SecurityPolicy is used to enforce security
requirements. It is best practice to use WS-SecurityPolicy to enforce
If you are using jbossws-native, the fix for this flaw is implemented by
two new configuration parameters in the 'encryption' element. This element
can be a child of 'requires' in both client and server wsse configuration
descriptors (set on a per-application basis via the application's
jboss-wsse-server.xml and jboss-wsse-client.xml files). The new attributes
are 'algorithms' and 'keyWrapAlgorithms'. These attributes should contain a
blank space or comma separated list of algorithm IDs that are allowed for
the encrypted incoming message, both for encryption and private key
wrapping. For backwards compatibility, no algorithm checks are performed by
default for empty lists or missing attributes.
For example (do not include the line break in your configuration):
encryption algorithms="aes-192-gcm aes-256-gcm"
Specifies that incoming messages are required to be encrypted, and that the
only permitted encryption algorithms are AES-192 and 256 in GCM mode, and
RSA-OAEP only for key wrapping.
Before performing any decryption, the jbossws-native stack will verify that
each algorithm specified in the incoming messages is included in the
allowed algorithms lists from these new encryption element attributes. The
algorithm values to be used for 'algorithms' and 'keyWrapAlgorithms' are
the same as for 'algorithm' and 'keyWrapAlgorithm' in the 'encrypt'
The Jakarta Commons HttpClient component did not verify that the server
hostname matched the domain name in the subject's Common Name (CN) or
subjectAltName field in X.509 certificates. This could allow a
man-in-the-middle attacker to spoof an SSL server if they had a certificate
that was valid for any domain name. (CVE-2012-5783)
Multiple weaknesses were found in the JBoss Web DIGEST authentication
implementation, effectively reducing the security normally provided by
DIGEST authentication. A remote attacker could use these flaws to perform
replay attacks in some circumstances. (CVE-2012-5885, CVE-2012-5886,
Red Hat would like to thank Tibor Jager, Kenneth G. Paterson and Juraj
Somorovsky of Ruhr-University Bochum for reporting CVE-2012-5575.
Warning: Before applying the update, back up your existing Red Hat JBoss
BRMS installation (including its databases, applications, configuration
files, and so on).
All users of Red Hat JBoss BRMS 5.3.1 as provided from the Red Hat Customer
Portal are advised to apply this roll up patch.
The References section of this erratum contains a download link (you must
log in to download the update). Before applying the update, back up your
existing Red Hat JBoss BRMS installation (including its databases,
applications, configuration files, and so on).
Note that it is recommended to halt the Red Hat JBoss BRMS server by
stopping the JBoss Application Server process before installing this
update, and then after installing the update, restart the Red Hat JBoss
BRMS server by starting the JBoss Application Server process.
4. Bugs fixed (http://bugzilla.redhat.com/):
873317 - CVE-2012-5783 jakarta-commons-httpclient: missing connection hostname check against X.509 certificate name
873664 - CVE-2012-5885 CVE-2012-5886 CVE-2012-5887 tomcat: three DIGEST authentication implementation issues
880443 - CVE-2012-5575 jbossws-native, jbossws-cxf, apache-cxf: XML encryption backwards compatibility attacks
The Red Hat security contact is <firstname.lastname@example.org>. More contact
details at https://access.redhat.com/security/team/contact/
Copyright 2013 Red Hat, Inc.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to email@example.com
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
Australian Computer Emergency Response Team
The University of Queensland
Internet Email: firstname.lastname@example.org
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----