ppkarwasz commented on code in PR #2219: URL: https://github.com/apache/logging-log4j2/pull/2219#discussion_r1459885175
########## src/site/asciidoc/security.adoc: ########## @@ -46,6 +46,89 @@ If you have encountered an unlisted security vulnerability or other unexpected b The threat model that Log4j uses considers configuration files as safe input controlled by the programmer; **potential vulnerabilities that require the ability to modify a configuration are not considered vulnerabilities** as the required access to do so implies the attacker can execute arbitrary code. ==== +[#model] +== Threat Model + +Log4j is a low level library where configuration inputs and the classpath are expected to be controlled by the programmer. +Configurations have the ability to execute arbitrary code through custom plugins. +While specific Log4j plugins (such as a JNDI lookup) may use constraint validators or conditionals to require additional settings to opt in to functionality, this is not universally required by custom plugins. +Specific security considerations involved in our threat model are detailed below. + +=== Parameterized Logging + +When using a log message containing template parameters like `{}`, only the format string is evaluated for parameters to be substituted. +The message parameters themselves are not evaluated for parameters; they are only included in the format string corresponding to their template position. +The conversion of message parameters into a string is done on-demand depending on the layout being used. +When structure-preserving transformations of log message data are required, the `Message` API should be used for logging structured data. + +=== Unstructured Logging + +When using an unstructured layout such as `PatternLayout`, no guarantees can be made about the output format. +This layout is mainly useful for development purposes and should not be relied on in production applications. +For example, if a log message contains new lines, these are not escaped or encoded specially unless the configured pattern uses the `%encode{pattern}{CRLF}` wrapper pattern converter (which will encode a carriage return as the string `\r` and a line feed as the string `\n`) or some other `%encode` option. Review Comment: I would also remind the user that `%xEx` is appended to the pattern, unless already present. ########## src/site/asciidoc/security.adoc: ########## @@ -46,6 +46,89 @@ If you have encountered an unlisted security vulnerability or other unexpected b The threat model that Log4j uses considers configuration files as safe input controlled by the programmer; **potential vulnerabilities that require the ability to modify a configuration are not considered vulnerabilities** as the required access to do so implies the attacker can execute arbitrary code. ==== +[#model] +== Threat Model + +Log4j is a low level library where configuration inputs and the classpath are expected to be controlled by the programmer. +Configurations have the ability to execute arbitrary code through custom plugins. +While specific Log4j plugins (such as a JNDI lookup) may use constraint validators or conditionals to require additional settings to opt in to functionality, this is not universally required by custom plugins. +Specific security considerations involved in our threat model are detailed below. + +=== Parameterized Logging + +When using a log message containing template parameters like `{}`, only the format string is evaluated for parameters to be substituted. +The message parameters themselves are not evaluated for parameters; they are only included in the format string corresponding to their template position. +The conversion of message parameters into a string is done on-demand depending on the layout being used. +When structure-preserving transformations of log message data are required, the `Message` API should be used for logging structured data. Review Comment: I would advise users to only use compile-time constants as format strings and under no circumstance build format strings from user data. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org