logging-log4j2

logging-log4j2 copied to clipboard

We should document our security model on our security page. An example of such a description is the Commons Security Model

@rm5248, @swebb2066, @fluffynuts and @grobmeier: maybe this could be a document shared by all the projects? The security risks seems pretty much similar to me.

From the top of my head, our security model should relieve us from any responsibility for:

• CRLF injections if the user uses a line-oriented tool to parse logs,
• other kinds of data corruption if the user uses PatternLayout to generate JSON, XML or other structured formats,

Attacks that require access to a configuration file should not be considered vulnerabilities.

I agree, one security model should match for all logging projects - maybe some extensions are necessary for Flume and Chainsaw

This Commons discussion might be interesting.

When the document is ready, we might ask @raboof to proofread it.

Some initial thoughts about this:

• Configuration files or configuration code have the ability to execute arbitrary code by using custom plugins; as such, configurations must be controlled by the programmer, not arbitrary users.
• Log message parameters are not evaluated for any sort of template strings like {}; template strings are limited to the non-parameter message argument. As such, log message parameters are not treated specially (such as with a prepared statement in SQL). When structure-preserving encoding is desired for things besides the log message as a whole, the Message API should be used for logging structured data rather than strings.
• Unstructured layouts shouldn't be used if any user-controlled data can be logged through them; this largely includes logging exceptions if said exceptions can contain user input (which is a common use case for exceptions).
• Code signing and verification is only performed at the artifact level (i.e., our jars, zips, and tarballs); we do not rely on jar signing to validate plugins or extensions (unlike, say, the Java cryptography APIs which require signed jars typically).
• Given the equivalence to the halting problem, we cannot generically support any form of log masking for sensitive data. While external plugins may support limited forms of masking (e.g., for credit card numbers or similar easily identifiable byte patterns), it is up to the programmer to explicitly mark sensitive data for masking.
• While the project goes to great lengths to minimize performance overhead along with options for minimizing latency or maximizing throughput, we cannot guarantee absolute availability of the system when using synchronous logging. If your application is writing log data faster than it can store it to disk, synchronous logging will affect the availability of your application. Using asynchronous logging can help to an extent here, though we do not support back pressure signals (this might be a patches welcome area; not sure if we need to define this in the security model).
• We do not support running in a Java SecurityManager; this API is being removed from Java anyways.
• Configurations can read system properties, environment variables, arguments to the main program, and any other data sources made available via StrLookup plugins (which includes some HTTP-related data if you use the WebLookup plugin).

Then we have some bits that are specific to various systems:

• When using JNDI for configuration files (as in a JavaEE/JakartaEE application server) or for use with dependency injection of shared server resources (such as JMS connection pools, JDBC connection pools, etc.), only the java scheme is supported. We do not support nor recommend use of other JNDI providers that interact with potentially untrusted remote data sources due to the weak security model of JNDI itself. Yes, that means we don't support LDAP, RMI, DNS, or any other Context providers.
• When using an unstructured layout, we cannot guarantee that user input cannot interfere with the output of the formatted log message. Within the pattern layout plugin specifically, we do offer various encoding methods to help address this for different use cases (such as encoding or escaping new lines or other special characters used in various formats), but they're all opt-in.
• When using a structured layout such as JsonTemplateLayout, XML, etc., log message input data is encoded appropriately to the target layout (e.g., a log message containing XML data will be properly escaped inside an XML layout).
• Advanced methods of handling configuration (such as a refresh period for the config file, JMX remote management, or other remote methods for updating a config) must be protected by the programmer behind some form of authentication and authorization; it is beyond the scope of this library to hand wave away your identity solution or file permissions.
• Use of string lookup plugins that can reference user-controlled data should not be used with unstructured layouts
• Use of PatternLayout is more of a developer convenience than a production-quality layout that can be reliably parsed by log collectors or other derivative systems. In that sense, any inline JSON, whitespace, XML, etc., are not treated differently as pattern layouts are fairly arbitrary. When a reliable format is needed for parsing the output of logs, a structured layout should be used.
• Any form of encryption or signatures used on log data directly from the library must use a proper key management system. Use of cryptography anywhere requires a properly designed key management system, and any plugins or extensions that offer to do so using a single static key (symmetric or asymmetric) are likely broken beyond repair.
• When using compression, if logs can contain user input, then the compressed log output must not be viewable directly or indirectly by the user if said logs are supposed to be private. This relates to the CRIME attack which affects older versions of TLS.

The Securing Tomcat page might also help as an example.

We should probably also cite JMX as category of problems we don't consider our vulnerabilities. Anyway JMX has MLet as an easier way for remote code execution.

Yes, I covered that point in

Advanced methods of handling configuration (such as a refresh period for the config file, JMX remote management, or other remote methods for updating a config) must be protected by the programmer behind some form of authentication and authorization; it is beyond the scope of this library to hand wave away your identity solution or file permissions.

Though I suppose JMX in general could use a warning about using it properly, especially once it's been extracted into a standalone module.