See how jboss compares to other vendors in security performance
A flaw was found in modcluster's AdvertiseListenerImpl (org.jboss.modcluster core module). A single crafted UDP multicast datagram with a valid HTTP status line and a "Server:" header but without the "Date:", "Digest:", and "Sequence:" headers triggers a NullPointerException in verifyDigest() that is not caught by the worker thread's exception handler. This causes the advertise listener thread to terminate permanently. The failure is silent (isListening() continues to return true) and persists until the node is restarted. The crash occurs before the AdvertiseSecurityKey comparison, so deployments with a configured security key are still affected.
Reported via PSIRTSUPT-20286 by Ta Duc Thien from Ninh Thanh Cyber Security (NTCS).
Vulnerability in org.jboss.modcluster core module, class AdvertiseListenerImpl. A crafted UDP multicast datagram (missing Date/Digest/Sequence headers) triggers an uncaught NullPointerException in verifyDigest() that kills the advertise worker thread permanently. Works even with AdvertiseSecurityKey configured (NPE fires before key comparison). Silent failure — isListening() keeps returning true.
Upstream: https://github.com/modcluster/modcluster Affected version: 2.1.0.Final (confirmed by reporter, same code on current main branch) Reporter's PoC and full write-up attached to PSIRTSUPT-20286.
original reported in: https://docs.google.com/document/d/1Rf4NtLudECimDNy8F9clUblm6Avx8yF/edit
Remote Class Loading — openjdk-orb JDKBridge honours CDR codebase URL under -secmgr (pre-auth :3528) (JBoss EAP)
Pre-auth remote class loading via IIOP: when EAP runs with -secmgr, the openjdk-orb's JDKBridge honours attacker-supplied CDR codebase URLs during object unmarshalling on :3528, allowing an unauthenticated attacker to load and instantiate arbitrary classes from a remote URL in the server JVM before EJB security interceptors run. findings/jboss-eap44.md
A flaw was found in Undertow. When Undertow receives an HTTP request where the first header line starts with one or more spaces, it incorrectly processes the request by stripping these leading spaces. This behavior, which violates HTTP standards, can be exploited by a remote attacker to perform request smuggling. Request smuggling allows an attacker to bypass security mechanisms, access restricted information, or manipulate web caches, potentially leading to unauthorized actions or data exposure.
Undertow splits header names from values on either space or colon, whichever comes first. This allows for the construction of crafted requests with headers that are visible only to Undertow, but not upstream proxies, which can be used to launch request smuggling attacks.
When Undertow receives a request in which the first header line begins with one or more spaces, it strips them before processing the request. This is usable as a request smuggling primitive.
The HTTP RFCs state that when a field-line begins with a space or tab, it is permissible to concatenate it into the previous field-line's value. This is referred to as obs-fold in the RFCs. However, it is always invalid to obs-fold on the first line, since there is no previous field-line to concatenate into. Thus, the message should be rejected.
Problems with Undertow cookie parsing may lead to smuggling or spoofing of cookies in certain conditions.
Bug URL: https://issues.jboss.org/browse/KEYCLOAK-10389
In order to be aligned with the other adapters, the NodeJS Adapter should also support the "verify-token-audience" configuration parameter.
Undertow has a file handler leak vulnerability caused by JarURLConnection.getLastModified(). A remote attacker could exploit this to cause a denial of service.
External References:
https://issues.jboss.org/browse/UNDERTOW-1338 https://bugs.openjdk.java.net/browse/JDK-6956385
A vulnerability was found in the way RemoteMessageChannel, introduced in jboss-remoting versions 3.3.10, reads from an empty buffer. An attacker could use this flaw to cause denial of service via high CPU caused by an infinite loop.
A flaw was found in Wildfly 9.x. A patch traversal vulnerability through the org.wildfly.extension.undertow.deployment.ServletResourceManager.getResource method could lead to information disclosure of arbitrary local files.
Upstrea bug:
https://issues.jboss.org/browse/WFLY-9620
References:
https://developer.jboss.org/thread/276826
Undertow keeps a cache of seen HTTP headers in persistent connections. It was found that this cache can easily exploited to fill memory with garbage, up to "max-headers" (default 200) "max-header-size" (default 1MB) per active TCP connection.
Upstream bug:
https://issues.jboss.org/browse/WFLY-7725
JBoss BPM Suite 6.3.0 is vulnerable to a stored XSS via business process editor. Remote authenticated attackers that have privileges to create business processes can store scripts in them, which are not properly sanitized before showing to other users, including admins.
An SQL injection vulnerability was found in dashbuilder.
Original Jira: https://issues.jboss.org/browse/DASHBUILDE-113
It was reported that HTTPS NIO connector uses no timeout when reading SSL handshake from a client to tie up a thread on the server just by creating a socket. Attacker could create socket and then never sends the handshake or any data at all, which causes the thread to remain occupied indefinitely so long as the socket remains open.
Product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1307039
It was discovered that when dealing with undefined security domains, the org.jboss.security.plugins.mapping.JBossMappingManager implementation would fall back to the default security domain if available. A user with valid credentials in the defined default domain, with a role that is valid in the expected application domain, can perform actions that was otherwise not available to them. When using the SAML2 STS Login Module, JBossMappingManager exposes this issue since PicketLink Trust SecurityActions implementation use a hardcoded default value when defining the context.
Teiid before 8.4.3 and before 8.7 and Red Hat JBoss Data Virtualization 6.0.0 before patch 3 allows remote attackers to read arbitrary files via a crafted request to a REST endpoint, related to an XML External Entity (XXE) issue.
It was discovered that by requesting a large enough image size for a generated QR code, a remote attacker could cause uncontrolled resource consumption leading to denial of service for legitimate users.
Upstream Issue:
https://issues.jboss.org/browse/KEYCLOAK-699
JBoss Enterprise Portal Platform is the open source implementation of theJava EE suite of services and Portal services running atop JBoss EnterpriseApplication Platform. It comprises a set of offerings for enterprisecustomers who are looking for pre-configured profiles of JBoss EnterpriseMiddleware components that have been tested and certified together toprovide an integrated experience.It was found that XStream could deserialize arbitrary user-supplied XMLcontent, representing objects of any type. A remote attacker able to passXML to XStream could use this flaw to perform a variety of attacks,including remote code execution in the context of the server running theXStream application. (CVE-2013-7285)It was found that the secure processing feature of Xalan-Java hadinsufficient restrictions defined for certain properties and features.A remote attacker able to provide Extensible Stylesheet LanguageTransformations (XSLT) content to be processed by an application usingXalan-Java could use this flaw to bypass the intended constraints of thesecure processing feature. Depending on the components available in theclasspath, this could lead to arbitrary remote code execution in thecontext of the application server running the application that usesXalan-Java. (CVE-2014-0107)All users of JBoss Enterprise Portal Platform 5.2.2 as provided from theRed Hat Customer Portal are advised to install this update.
It was identified that security auditing provided by JBossSX/PicketBox logged sensitive information into a world readable audit.log file. This information could be used by a local attacker to gain otherwise protected information about user sessions etc.
A code execution vulnerability has been discovered in JBoss SOA RTgov. The flaw allows remote authenticated attackers to submit arbitrary Java code in MVEL expressions submitted through RTgov, the code would be executed within the security context of the application server.
IssueDescription:
It was identified that PicketBox/JBossSX allowed any deployed application to alter or read the underlying application server configuration and state without any authorization checks. An attacker able to deploy applications could use this flaw to circumvent security constraints applied to other applications deployed on the same system, disclose privileged information, and in certain cases allow arbitrary code execution.
It was found that the InterfaceGenerator handler in JBoss Seam Remoting will expose details of all classes and methods on the server's classpath, not just methods with the org.jboss.seam.annotations.remoting.WebRemote annotation. A remote attacker could use this flaw to determine which classes are deployed on the JBoss server.
An attack technique against the W3C XML Encryption Standard when blockciphers were used in CBC mode could allow a remote attacker to conductchosen-ciphertext attacks, leading to the recovery of the entire plain textof a particular cryptogram. (CVE-2011-1096)JBoss Web Services leaked side-channel data when distributing symmetrickeys (for XML encryption), allowing a remote attacker to recover the entireplain text form of a symmetric key. (CVE-2011-2487)Spring framework could possibly evaluate Expression Language (EL)expressions twice, allowing a remote attacker to execute arbitrary code inthe context of the application server, or to obtain sensitive informationfrom the server. Manual action is required to apply this fix. Refer to theSolution section. (CVE-2011-2730)Apache CXF checked to ensure XML elements were signed or encrypted by aSupporting Token, but not whether the correct token was used. A remoteattacker could transmit confidential information without the appropriatesecurity, and potentially circumvent access controls on web servicesexposed via Apache CXF. Refer to the Solution section for details.(CVE-2012-2379)When an application used FORM authentication, along with another componentthat calls request.setUserPrincipal() before the call toFormAuthenticator#authenticate() (such as the Single-Sign-On valve), it waspossible to bypass the security constraint checks in the FORM authenticatorby appending "/jsecuritycheck" to the end of a URL. (CVE-2012-3546)The JMX Console was vulnerable to CSRF attacks, allowing a remote attackerto hijack the authenticated JMX Console session of an administrator.(CVE-2011-2908)An XSS flaw allowed a remote attacker to perform an XSS attack againstvictims using the JMX Console. (CVE-2011-4575)SecurityAssociation.getCredential() returned the previous credential ifno security context was provided. Depending on the deployed applications,this could possibly allow a remote attacker to hijack the credentials of apreviously-authenticated user. (CVE-2012-3370)Configuring the JMX Invoker to restrict access to users with specificroles did not actually restrict access, allowing remote attackers withvalid JMX Invoker credentials to perform JMX operations accessible toroles they are not a member of. (CVE-2012-5478)twiddle.sh accepted credentials as command line arguments, allowing localusers to view them via a process listing. (CVE-2009-5066)The JMXInvokerHAServlet and EJBInvokerHAServlet invoker servlets allowunauthenticated access by default in some profiles. The securityinterceptor's second layer of authentication prevented direct exploitationof this flaw. If the interceptor was misconfigured or inadvertentlydisabled, this flaw could lead to arbitrary code execution in the contextof the user running the JBoss server. (CVE-2012-0874)The JGroups diagnostics service was enabled with no authentication when aJGroups channel was started, allowing attackers on the adjacent network toread diagnostic information. (CVE-2012-2377)CallerIdentityLoginModule retained the password from the previous call if anull password was provided. In non-default configurations this couldpossibly lead to a remote attacker hijacking a previously-authenticateduser's session. (CVE-2012-3369)Red Hat would like to thank Juraj Somorovsky of Ruhr-University Bochum forreporting CVE-2011-1096 and CVE-2011-2487; the Apache CXF project forreporting CVE-2012-2379; and Tyler Krpata for reporting CVE-2011-4575.CVE-2012-3370 and CVE-2012-3369 were discovered by Carlo de Wolf of RedHat; CVE-2012-5478 discovered by Derek Horton of Red Hat; CVE-2012-0874discovered by David Jorm of Red Hat; and CVE-2012-2377 was discovered byRed Hat.
The IronJacamar container before 1.0.12.Final for JBoss Application Server, when allow-multiple-users is enabled in conjunction with a security domain, does not use the credentials supplied in a getConnection function call, which allows remote attackers to obtain access to an arbitrary datasource connection in opportunistic circumstances via an invalid connection attempt.
When using multi-user authentication provided by the "allow-multiple-users" option for the datasource's connection pool together with a security domain, the credentials provided as arguments to the getConnection(uid,pwd) function are ignored. This means that a valid connection will be returned for an invalid credential.
This could also mean that, provided the correct subject, a datasource connection can be obtained that which might belong to a privileged user.
A fix for this issue is already available up-stream. The up-stream fix is located at [jira JBJCA-864].
When a JGroups channel is started, the JGroups diagnostics service will be enabled by default with no authentication. This service is exposed via IP multicast. On JBoss Enterprise Application Platform 6, an attacker on an adjacent network can exploit this flaw to read diagnostics information and invoke JMX operations on the server (limited remote code execution). On other affected JBoss products, an attacker on an adjacent network can exploit this flaw only to read diagnostics information (information disclosure).
JBoss Web is the web container, based on Apache Tomcat, in JBoss EnterpriseApplication Platform. It provides a single deployment platform for theJavaServer Pages (JSP) and Java Servlet technologies.A flaw was found in the way JBoss Web handled UTF-8 surrogate paircharacters. If JBoss Web was hosting an application with UTF-8 characterencoding enabled, or that included user-supplied UTF-8 strings in aresponse, a remote attacker could use this flaw to cause a denial ofservice (infinite loop) on the JBoss Web server. (CVE-2011-4610)It was found that the Java hashCode() method implementation wassusceptible to predictable hash collisions. A remote attacker could usethis flaw to cause JBoss Web to use an excessive amount of CPU time bysending an HTTP request with a large number of parameters whose names mapto the same hash value. This update introduces a limit on the number ofparameters and headers processed per request to mitigate this issue. Thedefault limit is 512 for parameters and 128 for headers. These defaultscan be changed by setting theorg.apache.tomcat.util.http.Parameters.MAXCOUNT andorg.apache.tomcat.util.http.MimeHeaders.MAXCOUNT system properties in"jboss-as/server/[PROFILE]/deploy/properties-service.xml". (CVE-2011-4858)It was found that JBoss Web did not handle large numbers of parameters andlarge parameter values efficiently. A remote attacker could make a JBossWeb server use an excessive amount of CPU time by sending an HTTP requestcontaining a large number of parameters or large parameter values. Thisupdate introduces limits on the number of parameters and headers processedper request to address this issue. Refer to the CVE-2011-4858 descriptionfor information about the org.apache.tomcat.util.http.Parameters.MAXCOUNTand org.apache.tomcat.util.http.MimeHeaders.MAXCOUNT system properties.(CVE-2012-0022)Multiple flaws were found in the way JBoss Web handled HTTP DIGESTauthentication. These flaws weakened the JBoss Web HTTP DIGESTauthentication implementation, subjecting it to some of the weaknesses ofHTTP BASIC authentication, for example, allowing remote attackers toperform session replay attacks. (CVE-2011-1184, CVE-2011-5062,CVE-2011-5063, CVE-2011-5064)A flaw was found in the way JBoss Web handled sendfile request attributeswhen using the HTTP APR (Apache Portable Runtime) or NIO (Non-Blocking I/O)connector. A malicious web application running on a JBoss Web instancecould use this flaw to bypass security manager restrictions and gain accessto files it would otherwise be unable to access, or possibly terminate theJava Virtual Machine (JVM). (CVE-2011-2526)Red Hat would like to thank NTT OSSC for reporting CVE-2011-4610; oCERT forreporting CVE-2011-4858; and the Apache Tomcat project for reportingCVE-2011-2526. oCERT acknowledges Julian Wälde and Alexander Klink as theoriginal reporters of CVE-2011-4858.Warning: Before applying this update, back up your JBoss EnterpriseApplication Platform's "jboss-as/server/[PROFILE]/deploy/" directory, alongwith all other customized configuration files.All users of JBoss Enterprise Application Platform 5.1.2 as provided fromthe Red Hat Customer Portal are advised to install this update.
RESTEasy permits XXE (XML eXternal Entity) attacks. If a RESTEasy endpoint is deployed, a user can submit a request containing an external XML entity. This XML entity will be resolved, allowing a remote attacker to read files in the context of the user running the application server. This flaw affects DOM Document, JAXB and Fast Infoset (FI) input.
Upstream bugs: https://issues.jboss.org/browse/RESTEASY-637 https://issues.jboss.org/browse/RESTEASY-647 https://issues.jboss.org/browse/RESTEASY-659
The JMX console as shipped with JBoss EAP 5.1.1 is vulnerable to cross-site request forgery (CSRF) attacks. This vulnerability allows an attacker to invoke operations on mbeans via the JMX console.