- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1574) No SSL hostname verification
by QOS.CH (JIRA) 14 Oct '21

14 Oct '21

1 0

[JIRA] (LOGBACK-1583) @NoAutoStart ignored on interfaces and parent classes
by QOS.CH (JIRA) 13 Oct '21

13 Oct '21

1 0

[JIRA] (LOGBACK-1583) @NoAutoStart ignored on interfaces and parent classes
by QOS.CH (JIRA) 13 Oct '21

13 Oct '21

1 0

[JIRA] Updates for LOGBACK-1583: @NoAutoStart ignored on interfaces and parent classes
by QOS.CH (JIRA) 13 Oct '21

13 Oct '21

logback / LOGBACK-1583 [Open] @NoAutoStart ignored on interfaces and parent classes ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1583 ============================== Issue created ------------------------------ Bertrand Renuart created this issue on 13/Oct/21 4:10 PM Summary: @NoAutoStart ignored on interfaces and parent classes Issue Type: Bug Affects Versions: 1.2.6 Assignee: Logback dev list Components: Joran Created: 13/Oct/21 4:10 PM Environment: The {{@NoAutoStart}} annotation can be used to tell Joran not to start the component event it implements the {{Lifecycle}} interface. Unfortunately, the annotation seems to be ignored when not set directly on the component class but on an interface or a base/parent class of the hierarchy. After digging into the source code, it looks like the [(NoAutoStart#notMarkedWithNoAutoStart()|https://github.com/qos-ch/logback/bl…] method could be enhanced to look for the annotation in the hierarchy and implement interfaces in addition the the class itself. Priority: Major Reporter: Bertrand Renuart ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1583) @NoAutoStart ignored on interfaces and parent classes
by QOS.CH (JIRA) 13 Oct '21

13 Oct '21

1 0

[JIRA] Updates for LOGBACK-1582: CompositeConverters children are not given Context
by QOS.CH (JIRA) 11 Oct '21

11 Oct '21

logback / LOGBACK-1582 [Open] CompositeConverters children are not given Context ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1582 ============================== Issue created ------------------------------ Bill Koch created this issue on 11/Oct/21 4:56 PM Summary: CompositeConverters children are not given Context Issue Type: Bug Affects Versions: 1.2.6 Assignee: Logback dev list Components: logback-core Created: 11/Oct/21 4:56 PM Priority: Major Reporter: Bill Koch Description: With a logback.xml configuration like this: {code:java} <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>[%thread] %-5level - %msg%n%replace(%rootException{5 , sun.reflect , java.lang , java.util , org.gradle , com.sun , org.junit}){'\\n', '~~'}%nopexception</pattern> </encoder> </appender> <logger name="test" level="debug" additivity="false"> <appender-ref ref="STDOUT"/> </logger> <root level="error"> <appender-ref ref="STDOUT"/> </root> </configuration> {code} Logback throws a NullPointerException on startup: {code:java} 10:52:50,790 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@11:19 - RuntimeException in Action for tag [encoder] java.lang.NullPointerException10:52:50,790 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@11:19 - RuntimeException in Action for tag [encoder] java.lang.NullPointerException at java.lang.NullPointerException at at ch.qos.logback.classic.pattern.ThrowableProxyConverter.start(ThrowableProxyConverter.java:75) at at ch.qos.logback.core.pattern.ConverterUtil.startConverters(ConverterUtil.java:37) at at ch.qos.logback.core.pattern.ConverterUtil.startConverters(ConverterUtil.java:33) at at ch.qos.logback.core.pattern.PatternLayoutBase.start(PatternLayoutBase.java:89) at at ch.qos.logback.classic.encoder.PatternLayoutEncoder.start(PatternLayoutEncoder.java:28){code} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1580: logback-access uses response.getStatus improperly
by QOS.CH (JIRA) 09 Oct '21

09 Oct '21

logback / LOGBACK-1580 [Open] logback-access uses response.getStatus improperly ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1580 ============================== Issue created ------------------------------ Joakim Erdfelt created this issue on 09/Oct/21 3:34 PM Summary: logback-access uses response.getStatus improperly Issue Type: Bug Assignee: Logback dev list Components: logback-access Created: 09/Oct/21 3:34 PM Priority: Major Reporter: Joakim Erdfelt Description: The use of HttpServletResponse.getStatus is not reliable for a request logging library. The status code is not immutable on the servlet spec and is often reset or change from when the status code was committed (sent over the network) vs when it reaches the request logging implementation in `logback-access`. Libraries like spring-framework, spring-mvc, spring-boot, spring-security, all change the status code on the way out of the context dispatch. Every decent servlet container tracks the "committed state" of the Request and Response objects and use those values for their own request logging implementation just to ensure that their request logging contains accurate (as seen on the network) information in the request log. Example: Jetty has `response.getCommittedMetaData().getStatus()` for the status code. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1581: loback-access should not use Request.getParameterNames
by QOS.CH (JIRA) 09 Oct '21

09 Oct '21

logback / LOGBACK-1581 [Open] loback-access should not use Request.getParameterNames ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1581 ============================== Issue created ------------------------------ Joakim Erdfelt created this issue on 09/Oct/21 3:39 PM Summary: loback-access should not use Request.getParameterNames Issue Type: Bug Assignee: Logback dev list Components: logback-access Created: 09/Oct/21 3:39 PM Priority: Major Reporter: Joakim Erdfelt Description: logback-access has exposed an interesting DOS attack. logback-access uses the `HttpServletRequest.getParameterNames()` API during it's attempt at logging the request. The use of `getParameterNames` should never occur in request logging. The use of the getParameterNames API has side effects that will cause the Request body content to be read (if it hasn't been read before, and the Content-Type is `application/x-www-form-urlencoded` or `multipart/form-data`). This in combination of when the request logging occurs means your request logging is subverting the intended behavior of the application, and the request logging is now also impacting the behavior of the request / response exchange. Scenario 1: * Request arrives, it's a POST request, with `Content-Type: multipart/form-data`, and contains 2GB of body content. * Container dispatches to the Application, it determines that the request should not be processed (missing headers, bad authentication, bad authorization, etc. It can be countless list of things). * Application uses HttpServletResponse.sendError(403) * Dispatch to the Application is done. * Container finishes sending the response. * Container calls the request logging implementation. In this scenario, `logback-access` just read the request body content, all 2GB, just to throw it away. And there was no protection on sizes or MultipartConfigElement as the context dispatch is done and the request logging occurred on Server level. Your request logging now consumed server resources that the application wasn't in control over. Scenario 2: * Request arrives, it's a trash, complete garbage, not even recognizable as HTTP. * Container responds with status code 400. * Container calls the request logging implementation. The request is bad, the status code is 400, logback-access should not be attempting to access the request details at all in this scenario, but it does. Scenario 3: * Request arrives, it's from a bad, but well meaning HTTP Client. * Request contains something that breaks the HTTP spec (like using a `Content-Length` + `Transfer-Encoding` at the same time) * Container responds with status code 400. * Container calls the request logging implementation. The request is bad, the status code is 400, logback-access should not be attempting to access the request details at all in this scenario, but it does. But in this scenario, the request is actually HTTP, but the request body content is suspect. It could be valid, it could be malicious. logback-access should not be attempting to cause a request body read by using the `HttpServletRequest.getParameterNames()`. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1574) No SSL hostname verification
by QOS.CH (JIRA) 07 Oct '21

07 Oct '21

1 0

[JIRA] (LOGBACK-1574) No SSL hostname verification
by QOS.CH (JIRA) 05 Oct '21

05 Oct '21

1 0