GHSA-36qh-35cm-5w2w BIT-tomcat-2021-30640 CVE-2021-30640
Authentication Bypass by Alternate Name in Apache Tomcat
Medium
Maven
- Severity
- 6.5 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 9.89%
- Chance of exploitation in the next 30 days. Higher than 95.57% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-116 Improper Encoding or Escaping of Output
- CWE-287 Improper Authentication
- CWE-289 Authentication Bypass by Alternate Name
- Fix
10.0.5- Upgrade org.apache.tomcat:tomcat to this version or later
Description
A vulnerability in the JNDI Realm of Apache Tomcat allows an attacker to authenticate using variations of a valid user name and/or to bypass some of the protection provided by the LockOut Realm. This issue affects Apache Tomcat 10.0.0-M1 to 10.0.5; 9.0.0.M1 to 9.0.45; 8.5.0 to 8.5.65.
Affected versions
Maven
| Package | Vulnerable | Fixed in |
|---|---|---|
| org.apache.tomcat:tomcat | >= 10.0.0-M1, < 10.0.5 |
10.0.5 |
| org.apache.tomcat:tomcat | >= 9.0.0M1, < 9.0.45 |
9.0.45 |
| org.apache.tomcat:tomcat | >= 8.5.0, < 8.5.65 |
8.5.65 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
org.apache.tomcat:tomcat Maven → 10.0.5
- maven
<dependency><groupId>org.apache.tomcat</groupId><artifactId>tomcat</artifactId><version>10.0.5</version></dependency>- gradle
implementation("org.apache.tomcat:tomcat:10.0.5")
Severity breakdown
CVSS 3.1 6.5
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- High
- Availability
- None
Weakness
CWE-116: Improper Encoding or Escaping of Output
The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
How to prevent it
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error. Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.
- Architecture and Design: If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.
- Architecture and Design, Implementation: Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
- Architecture and Design: In some cases, input validation may be an important strategy when output encoding is not a complete solution. For example, you may be providing the same output that will be processed by multiple consumers that use different encodings or representations. In other cases, you may be required to allow user-supplied input to contain control information, such as limited HTML tags that support formatting in a wiki or bulletin board. When this type of requirement must be met, use an extremely strict allowlist to limit which control sequences can be used. Verify that the resulting syntactic structure is what you expect. Use your normal encoding methods for the remainder of the input.
- Architecture and Design: Use input validation as a defense-in-depth measure to reduce the likelihood of output encoding errors (see CWE-20).
- Requirements: Fully specify which encodings are required by components that will be communicating with each other.
- Implementation: When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
CWE-287: Improper Authentication
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
How to prevent it
- Architecture and Design: Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CWE-289: Authentication Bypass by Alternate Name
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
How to prevent it
- Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
References
Advisories
Other links
- lists.apache.org/thread.html/r59f9ef03929d32120f91f4ea7e6e79edd5688d75d0a9b65fd26d1fe…
- lists.debian.org/debian-lts-announce/2021/08/msg00009.html
- security.gentoo.org/glsa/202208-34
- security.netapp.com/advisory/ntap-20210827-0007
- debian.org/security/2021/dsa-4952
- debian.org/security/2021/dsa-4986
- oracle.com//security-alerts/cpujul2021.html
- oracle.com/security-alerts/cpujan2022.html
- oracle.com/security-alerts/cpuoct2021.html
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-69r9-qgr7-g2wj Apache Tomcat Missing Encryption of Sensitive Data vulnerability | High Known exploited | Also affects org.apache.tomcat:tomcat |
| GHSA-h3x4-894j-xpx5 Apache Tomcat's FORM authentication process has an Incorrect Authorization vulnerability | Critical | Also affects org.apache.tomcat:tomcat |
| GHSA-9xv2-5v5q-p794 Apache Tomcat's DIGEST authenticator has an Authentication Bypass by Capture-replay vulnerability | Critical | Also affects org.apache.tomcat:tomcat |
| GHSA-gcx9-497g-6cp6 Apache Tomcat has an Improper Access Control, Incorrect Authorization vulnerability | Critical | Also affects org.apache.tomcat:tomcat |
| GHSA-5m62-pw8w-7w9f Apache Tomcat - Security constraints not correctly applied | Critical | Also affects org.apache.tomcat:tomcat |
| GHSA-9m89-8frq-c98c Apache Tomcat - AJP secret compared in non-constant time | Low | Also affects org.apache.tomcat:tomcat |
| GHSA-5mp6-jrq3-r938 Apache Tomcat: LockOutRealm treats user names as case-sensitive | High | Also affects org.apache.tomcat:tomcat |
| GHSA-h6fc-48rj-7qqh Apache Tomcat - Digest authenticator will authenticate any unknown user | Critical | Also affects org.apache.tomcat:tomcat |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor