Re: [VOTE] Release Apache Tomcat 10.1.0-M17
On 13/07/2022 23:57, Mark Thomas wrote: [X] Beta - go ahead and release as 10.1.0-M17 (beta) Tested on fedora 36 ;-) -- Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66170] New: change IllegalArgumentException log output
https://bz.apache.org/bugzilla/show_bug.cgi?id=66170 Bug ID: 66170 Summary: change IllegalArgumentException log output Product: Tomcat 9 Version: 9.0.64 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: apa...@resellerdesktop.de Target Milestone: - ATM we get this output in the logs, when a hacker tries to scan for vulnerability: Juli 19, 2022 11:45:22 VORM. org.apache.coyote.http11.Http11Processor service INFORMATION: Error parsing HTTP request header Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Ungültiges Zeichen im Methodennamen [ep.zyxel80;rm+-rf+arm7%3b%23&remoteSubmit=Save0x0d0x0a0x0d0x0a...] gefunden. HTTP Methodennamen müssen Token sein at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:419) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:271) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:890) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1787) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:829) This is as helpfull as a rotten tomato, because: a) Nobody cares for this stacktrace, the error message is important. b) the offending IP is not logged, so you can't defend the server against that attacker. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66170] change IllegalArgumentException log output
https://bz.apache.org/bugzilla/show_bug.cgi?id=66170 --- Comment #1 from Don't show my email --- a helpful log message would : IP: what happend : offending line of http request it needs to parseable by NIDS systems -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.65
On 14/07/2022 15:17, Rémy Maucherat wrote: [X] Stable - go ahead and release as 9.0.65 (stable) Tested on fedora 36 with tc-native 1.2.35 -- Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] exabrial commented on pull request #532: Don't perform protection checks in Unix Domain Socket mode
exabrial commented on PR #532: URL: https://github.com/apache/tomcat/pull/532#issuecomment-1189381572 Just want to say thanks! Our initial testing shows that bypassing the TCP layer and using Unix sockets is _very significant_ performance increase like _a lot_ faster. Pretty danged cool! We'd probably terminate TCP/TLS with Haproxy then load balance to Tomcat listening on Unix sockets. We still have a few more issues to overcome, but those are separate items or perhaps bugs, for another discussion: * We noticed the the socket file doesn't seem to get cleaned up, despite the documentation indicating it should. As a workaround, we have the systemd unit remove the file after Tomcat stops. We are trying to root cause this in Tomcat code and see if we can figure out whats wrong. * We noticed `request.getRemoteAddr()` and `request.getRemoteHost()` are broken (expected). We improvised a Valve to hardcode `127.0.0.1` for each and that seems to do the trick, then use the RemoteAddrValve to set the real values. A better option might be: Haproxy has something akin to AJP called "Proxy Protocol" that can pass a lot of information from the original request. There's a open bug about it that we might look into helping get across the finish line: https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 Anyway thank you! Very much appreciated! -- 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: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tcnative crashes during shutdown (TC 10.x unit tests)
Roughly the same pattern I saw for TC 10.0 now also seen for TC 10.1. Am 18.07.2022 um 12:09 schrieb Rainer Jung: Hi there, this is just an info, at this point probably not a showstopper. The topic is crashes in tcnative 1.2 and 2.0 for TC 10.0 during shutdown after TLS unit tests. Details: I ran the TC unit tests for latest 9.x, 10.x and 10.1.x with tcnative 1.2.35 OpenSSL 1.1.1q, 1.2.35 OpenSSL 3.0.2 and 2.0.1 OpenSSL 3.0.2. I ran the test for a variety of OpenJDK builds (Adoptium, Zulu, Oracle, RedHat) and versions (latest 1.8.0 except for 10.1, 11, 17 and current 19). The platforms where SLES 11, 12 and 15 and RHEL 6, 7 and 8. For RHEL 7 and 8 there were 48 runs, for the other platforms 39 (no RedHat JDK). I only ran about 150 test classes (for NIO and also for NIO2), because I also ran the full unit tests (about 450 classes) for JSSE and didn't want to rerun all tests for time and efficiency reasons. For TC 10 I observed crashes in TLS tests during shutdown: Out of the roughly 250 test runs, 5 produced such a crash. For TC 9 I did not observe a single one. Tests for TC 10.1 are ongoing, until now no crash, but it is a bit early for a final result. I think the crashes are not new. All hapened in the TLS tests in org.apache.tomcat.util.net. The list of crashes I saw for TC 10.0.23: RHEL7 jdk1.8.0 tcnative 1.2.35 OpenSSL 3.0.2 org.apache.tomcat.util.net.TestSsl FAILED (crashed) openjdk version "1.8.0_332-ea" OpenJDK Runtime Environment (build 1.8.0_332-ea-b06) OpenJDK 64-Bit Server VM (build 25.332-b06, mixed mode) double free or corruption (!prev): 0x7f473c19df50 === Backtrace: = /lib64/libc.so.6(+0x7d56d)[0x7f4742aa456d] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7f472871923d] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x30)[0x7f4728719c10] [0x7f472d018427] RHEL7 jdk17 tcnative 1.2.35 OpenSSL 1.1.1q org.apache.tomcat.util.net.TestCustomSslTrustManager FAILED (crashed) openjdk version "17.0.2" 2022-01-18 OpenJDK Runtime Environment (build 17.0.2+8-86) OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing) corrupted double-linked list: 0x7f6bb8001d10 === Backtrace: = /lib64/libc.so.6(+0x7bfc7)[0x7f6bf481dfc7] /lib64/libc.so.6(+0x7d774)[0x7f6bf481f774] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7f6bc543223d] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x30)[0x7f6bc5432c10] [0x7f6bd572249a] SLES11 oracle_jdk1.8.0 tcnative 2.0.1 OpenSSL 3.0.2 org.apache.tomcat.util.net.TestSsl FAILED (crashed) java version "1.8.0_331" Java(TM) SE Runtime Environment (build 1.8.0_331-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.331-b09, mixed mode) double free or corruption (!prev): 0x7fbf88c1de10 === Backtrace: = /lib64/libc.so.6(+0x75018)[0x7fbf87b35018] /lib64/libc.so.6(cfree+0x6c)[0x7fbf87b39f6c] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7fbf718a5aad] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x34)[0x7fbf718a66f4] [0x7fbf770264a7] SLES11 jdk11 tcnative 1.2.35 OpenSSL 1.1.1q org.apache.tomcat.util.net.TestSsl FAILED (crashed) openjdk version "11.0.15" 2022-04-19 OpenJDK Runtime Environment 18.9 (build 11.0.15+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.15+10, mixed mode) double free or corruption (!prev): 0x7f4f6bb93040 === Backtrace: = /lib64/libc.so.6(+0x75018)[0x7f4f6a171018] /lib64/libc.so.6(cfree+0x6c)[0x7f4f6a175f6c] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7f4f49403aad] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x34)[0x7f4f494046f4] [0x7f4f508b88b0] RHEL 8 Adoptium jdk11 tcnative 1.2.35 OpenSSL 1.1.1q Test org.apache.tomcat.util.net.TestClientCert FAILED (crashed) Since they are rare and happen in various tests and version combinations, it seems the general shutdown behavior w.r.t. the library is not yet perfect. Once the tests for 10.1 complete, I will see, whether I can force the crashes more often by focusing on the TLS tests in org.apache.tomcat.util.net. Best regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: tcnative crashes during shutdown (TC 10.x unit tests)
On 20/07/2022 00:16, Rainer Jung wrote: Roughly the same pattern I saw for TC 10.0 now also seen for TC 10.1. May be something wrong in apr? Which apr version are you using? Am 18.07.2022 um 12:09 schrieb Rainer Jung: Hi there, this is just an info, at this point probably not a showstopper. The topic is crashes in tcnative 1.2 and 2.0 for TC 10.0 during shutdown after TLS unit tests. Details: I ran the TC unit tests for latest 9.x, 10.x and 10.1.x with tcnative 1.2.35 OpenSSL 1.1.1q, 1.2.35 OpenSSL 3.0.2 and 2.0.1 OpenSSL 3.0.2. I ran the test for a variety of OpenJDK builds (Adoptium, Zulu, Oracle, RedHat) and versions (latest 1.8.0 except for 10.1, 11, 17 and current 19). The platforms where SLES 11, 12 and 15 and RHEL 6, 7 and 8. For RHEL 7 and 8 there were 48 runs, for the other platforms 39 (no RedHat JDK). I only ran about 150 test classes (for NIO and also for NIO2), because I also ran the full unit tests (about 450 classes) for JSSE and didn't want to rerun all tests for time and efficiency reasons. For TC 10 I observed crashes in TLS tests during shutdown: Out of the roughly 250 test runs, 5 produced such a crash. For TC 9 I did not observe a single one. Tests for TC 10.1 are ongoing, until now no crash, but it is a bit early for a final result. I think the crashes are not new. All hapened in the TLS tests in org.apache.tomcat.util.net. The list of crashes I saw for TC 10.0.23: RHEL7 jdk1.8.0 tcnative 1.2.35 OpenSSL 3.0.2 org.apache.tomcat.util.net.TestSsl FAILED (crashed) openjdk version "1.8.0_332-ea" OpenJDK Runtime Environment (build 1.8.0_332-ea-b06) OpenJDK 64-Bit Server VM (build 25.332-b06, mixed mode) double free or corruption (!prev): 0x7f473c19df50 === Backtrace: = /lib64/libc.so.6(+0x7d56d)[0x7f4742aa456d] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7f472871923d] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x30)[0x7f4728719c10] [0x7f472d018427] RHEL7 jdk17 tcnative 1.2.35 OpenSSL 1.1.1q org.apache.tomcat.util.net.TestCustomSslTrustManager FAILED (crashed) openjdk version "17.0.2" 2022-01-18 OpenJDK Runtime Environment (build 17.0.2+8-86) OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing) corrupted double-linked list: 0x7f6bb8001d10 === Backtrace: = /lib64/libc.so.6(+0x7bfc7)[0x7f6bf481dfc7] /lib64/libc.so.6(+0x7d774)[0x7f6bf481f774] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7f6bc543223d] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x30)[0x7f6bc5432c10] [0x7f6bd572249a] SLES11 oracle_jdk1.8.0 tcnative 2.0.1 OpenSSL 3.0.2 org.apache.tomcat.util.net.TestSsl FAILED (crashed) java version "1.8.0_331" Java(TM) SE Runtime Environment (build 1.8.0_331-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.331-b09, mixed mode) double free or corruption (!prev): 0x7fbf88c1de10 === Backtrace: = /lib64/libc.so.6(+0x75018)[0x7fbf87b35018] /lib64/libc.so.6(cfree+0x6c)[0x7fbf87b39f6c] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7fbf718a5aad] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x34)[0x7fbf718a66f4] [0x7fbf770264a7] SLES11 jdk11 tcnative 1.2.35 OpenSSL 1.1.1q org.apache.tomcat.util.net.TestSsl FAILED (crashed) openjdk version "11.0.15" 2022-04-19 OpenJDK Runtime Environment 18.9 (build 11.0.15+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.15+10, mixed mode) double free or corruption (!prev): 0x7f4f6bb93040 === Backtrace: = /lib64/libc.so.6(+0x75018)[0x7f4f6a171018] /lib64/libc.so.6(cfree+0x6c)[0x7f4f6a175f6c] /.../tcnative-deps/libapr-1.so.0(apr_allocator_destroy+0x1d)[0x7f4f49403aad] /.../tcnative-deps/libapr-1.so.0(apr_pool_terminate+0x34)[0x7f4f494046f4] [0x7f4f508b88b0] RHEL 8 Adoptium jdk11 tcnative 1.2.35 OpenSSL 1.1.1q Test org.apache.tomcat.util.net.TestClientCert FAILED (crashed) Since they are rare and happen in various tests and version combinations, it seems the general shutdown behavior w.r.t. the library is not yet perfect. Once the tests for 10.1 complete, I will see, whether I can force the crashes more often by focusing on the TLS tests in org.apache.tomcat.util.net. Best regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
