Skip to content

Conversation

ppkarwasz
Copy link
Contributor

This update includes resource: in the list of allowed URL schemes for retrieving configuration files. See log4j2.configurationAllowedProtocols.

Currently, the resource: protocol is used exclusively by a URLStreamHandler that retrieves files from the embedded resources in a GraalVM native image. This makes it a secure and appropriate source for trusted configuration files.

This change cannot be easily and reliably tested through a unit test. An integration test will be provided in apache/logging-log4j-samples#345

Closes #3790

This update includes `resource:` in the list of allowed URL schemes for retrieving configuration files.
See [`log4j2.configurationAllowedProtocols`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.configurationAllowedProtocols)

Currently, the `resource:` protocol is used exclusively by a `URLStreamHandler` that retrieves files from the embedded resources in a GraalVM native image. This makes it a secure and appropriate source for trusted configuration files.

This change cannot be easily and reliably tested through a unit test. An integration test will be provided in apache/logging-log4j-samples#345

Closes #3790
@vy
Copy link
Member

vy commented Jul 3, 2025

resource: protocol is used exclusively by a URLStreamHandler

I have some concerns regarding this change:

  • This introduces a behavioral change. If I am not mistaken, one even can classify this as a vulnerability with sufficient imagination: "I had this malicious resource in my classpath, containing a malicious Log4j configuration, I've upgraded to 2.26.0, and now this malicious configuration starts getting loaded!"
  • AFAIK, there is no such USH in JDK and this is a USH provided by Spring. Hence, this makes this fix Spring-only, which I am reluctant to make available for everyone.

Can we instead fix this in the upstream, i.e., Spring Boot itself? If we can, I understand that this will only apply to users using the latest and greatest Spring Boot – though we can detail this document and share the log4j2.configurationAllowedProtocols workaround in the installation guide.

This change introduces an internal `SystemUtils.isGraalVm()` method to detect the presence of GraalVM and enable the `resource` protocol.
@ppkarwasz
Copy link
Contributor Author

If I am not mistaken, one even can classify this as a vulnerability with sufficient imagination: "I had this malicious resource in my classpath, containing a malicious Log4j configuration, I've upgraded to 2.26.0, and now this malicious configuration starts getting loaded!"

If an attacker has already gained the ability to place a malicious resource in the classpath, the system has already been compromised.

AFAIK, there is no such USH in JDK and this is a USH provided by Spring. Hence, this makes this fix Spring-only, which I am reluctant to make available for everyone.

The URLStreamHandler for the resource: protocol is actually provided by the GraalVM runtime, not Spring Boot.

That said, I understand your concerns about allowing a protocol whose semantics are not fully defined. In 0f1af39, I introduced a helper method, SystemUtils.isGraalVm(), which ensures that the resource protocol is only added when running in a GraalVM environment.

@ppkarwasz ppkarwasz requested a review from vy July 3, 2025 13:59
@ppkarwasz ppkarwasz enabled auto-merge (squash) July 4, 2025 18:14
@ppkarwasz ppkarwasz merged commit c5a1955 into 2.x Jul 4, 2025
7 checks passed
@ppkarwasz ppkarwasz deleted the fix/2.x/3790_allow-resource-protocol branch July 4, 2025 18:33
@github-project-automation github-project-automation bot moved this from To triage to Done in Log4j bug tracker Jul 4, 2025
ppkarwasz added a commit that referenced this pull request Jul 5, 2025
* fix: Add `resource:` protocol to allowed URL schemes by default

This update includes `resource:` in the list of allowed URL schemes for retrieving configuration files.
See [`log4j2.configurationAllowedProtocols`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.configurationAllowedProtocols)

Currently, the `resource:` protocol is used exclusively by a `URLStreamHandler` that retrieves files from the embedded resources in a GraalVM native image. This makes it a secure and appropriate source for trusted configuration files.

This change cannot be easily and reliably tested through a unit test. An integration test will be provided in apache/logging-log4j-samples#345

Closes #3790

* fix: Add `resource` protocol only in native images

This change introduces an internal `SystemUtils.isGraalVm()` method to detect the presence of GraalVM and enable the `resource` protocol.

* Reword changelog entry

---------

Co-authored-by: Volkan Yazıcı <[email protected]>
vy added a commit to ashr123/logging-log4j2 that referenced this pull request Jul 20, 2025
…he#3795)

* fix: Add `resource:` protocol to allowed URL schemes by default

This update includes `resource:` in the list of allowed URL schemes for retrieving configuration files.
See [`log4j2.configurationAllowedProtocols`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.configurationAllowedProtocols)

Currently, the `resource:` protocol is used exclusively by a `URLStreamHandler` that retrieves files from the embedded resources in a GraalVM native image. This makes it a secure and appropriate source for trusted configuration files.

This change cannot be easily and reliably tested through a unit test. An integration test will be provided in apache/logging-log4j-samples#345

Closes apache#3790

* fix: Add `resource` protocol only in native images

This change introduces an internal `SystemUtils.isGraalVm()` method to detect the presence of GraalVM and enable the `resource` protocol.

* Reword changelog entry

---------

Co-authored-by: Volkan Yazıcı <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

**Log4j's Support Issues with GraalVM**
2 participants