जमा करें #866089: lmammino oidc-authorizer 0.4.0 Resource Consumptionजानकारी

शीर्षकlmammino oidc-authorizer 0.4.0 Resource Consumption
विवरणUnauthenticated denial of service in oidc-authorizer via UTF-8 panic in Authorization header parsing Affected package: oidc-authorizer Affected component: Authorization token parsing logic Affected source: src/parse_token_from_header.rs Summary: oidc-authorizer version 0.4.0 contains an input validation flaw in its Authorization header parsing logic. An unauthenticated attacker can cause the Lambda authorizer to panic by sending a crafted non-ASCII authorizationToken value that triggers invalid UTF-8 string slicing. Because the panic occurs during authorization header parsing, the authorizer aborts before returning a normal Deny response. This can cause protected API requests to fail and may allow unauthenticated denial of service against APIs using the affected authorizer. Technical details: The vulnerable function slices a Rust str using fixed byte offsets: parse_token_from_header(authorization_token: &str) The relevant logic checks whether the input starts with "Bearer " by slicing the string at byte offsets 0..7, and then returns authorization_token[7..] as the token. Rust str values must be sliced only at valid UTF-8 character boundaries. The vulnerable code does not verify that byte offset 7 is a valid character boundary before slicing. If an attacker supplies a string with at least 8 bytes where byte offset 7 falls inside a multibyte UTF-8 character, the slice operation panics at runtime. Example malicious input: 中中中 The string "中中中" is 9 bytes in UTF-8. Its valid character boundaries are at byte offsets 0, 3, 6, and 9. Byte offset 7 is inside the third multibyte character. Therefore, attempting to evaluate authorization_token[0..7] causes a runtime panic. Observed panic: thread 'main' panicked at src/parse_token_from_header.rs: byte index 7 is not a char boundary; it is inside '中' (bytes 6..9) of `中中中` This crash occurs before the function can safely return an authorization Deny response. Steps to reproduce: 1. Deploy or run oidc-authorizer version 0.4.0 as an AWS Lambda authorizer. 2. Create a test event with a crafted non-ASCII authorizationToken: { "authorizationToken": "中中中", "methodArn": "arn:aws:execute-api:ap-southeast-1:111122223333:apiid/dev/GET/test" } 3. Invoke the Lambda authorizer with the test event. 4. Observe that the function aborts instead of returning a normal Deny policy. Observed result: The Lambda execution fails with a runtime exit error. Example observed result: { "errorType": "Runtime.ExitError", "errorMessage": "RequestId: <id> Error: Runtime exited with error: signal: aborted" } CloudWatch or execution logs show a Rust panic similar to: thread 'main' panicked at src/parse_token_from_header.rs: byte index 7 is not a char boundary; it is inside '中' (bytes 6..9) of `中中中` Control case: Malformed ASCII inputs that do not use the "Bearer " prefix are handled normally and return Deny. The crash is specifically triggered by non-ASCII input that makes the fixed byte offset fall inside a multibyte UTF-8 character. Expected result: Malformed or unsupported Authorization header values should be rejected gracefully and return a Deny authorization response. The authorizer should not panic or abort on attacker-controlled input. Impact: This is an unauthenticated denial-of-service vulnerability. Any external attacker who can reach an API protected by this authorizer can repeatedly send crafted non-ASCII authorizationToken values and cause authorizer invocations to fail before the backend is reached. Potential impact includes: - Denial of service against protected API endpoints - Failed authorization requests before normal Deny handling - Disruption of legitimate traffic - Repeated low-cost authorizer crashes - Increased Lambda invocation and logging costs - Broader service disruption if the same authorizer is shared across multiple routes, stages, or APIs Rationale: The attack is network-accessible, requires low complexity, requires no privileges, and requires no user interaction. Scope is unchanged. Confidentiality and integrity are not directly affected. Availability impact is Low because the attack crashes the authorizer invocation and can disrupt protected API access. Recommended remediation: - Do not slice Rust str values using unchecked byte offsets on attacker-controlled input. - Use safe string APIs such as strip_prefix("Bearer "). - Return a controlled parse error when the Authorization header is malformed. - Add tests for non-ASCII and multibyte UTF-8 authorizationToken values. - Ensure all malformed authorization headers return Deny instead of panicking. - Consider wrapping authorizer parsing logic so unexpected parsing errors cannot abort the Lambda runtime. Example safer parsing approach: Use authorization_token.strip_prefix("Bearer ") and return an error if the prefix is absent. This avoids slicing at invalid UTF-8 boundaries. Disclosure status: A private GitHub Security Advisory already exists for this issue: GHSA-h378-g8x9-jwcj No CVE has been assigned at the time of this submission. The advisory has been pending maintainer action for approximately one month. This CVE request is submitted with the intent to avoid duplicate assignment and to coordinate tracking of the affected public package version. References: https://github.com/lmammino/oidc-authorizer https://github.com/lmammino/oidc-authorizer/security/advisories/GHSA-h378-g8x9-jwcj
स्रोत⚠️ https://github.com/lmammino/oidc-authorizer
उपयोगकर्ता
 changli (UID 99220)
सबमिशन23/06/2026 10:08 AM (2 महीनों पहले)
संयम08/08/2026 10:18 PM (2 months later)
स्थितिस्वीकृत
VulDB प्रविष्टि387216 [lmammino oidc-authorizer 0.4.0 Authorization Header Parsing parse_token_from_header.rs parse_token_from_header authorization_token सेवा अस्वीकार]
अंक20

Want to know what is going to be exploited?

We predict KEV entries!