Re: Tomcat 10.1.15 JVM crashes randomly on startup

[Mark Thomas]

On 13/11/2023 07:52, Øyvind Flatval wrote:

Greetings!

We are currently experiencing a very vague problem with our Tomcat 10.1 
instance, where the JVM will crash almost instantly after Tomcat is done 
starting up.
The problem happens somewhat regularly, and only happens within the first 
minute after starting Tomcat. The solution is always to just attempt to restart 
Tomcat and this usually only take 1 attempt.


Tomcat is running a single web application, that sees traffic over both 
Websocket (several 100 clients) and Https (maybe 20-40 users during peak + a 
few API clients)

Our setup is a somewhat old VM.
Windows Server 2016 Standard 1607, buil 14343.6351
Intel Xeon E5-2680 v4 @ 2.40 GHz
4 x Cores
8 GB Memory

JRE version: OpenJDK Runtime Environment Temurin-17.0.8.1+1 (17.0.8.1+1) (build 
17.0.8.1+1)
Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (17.0.8.1+1, mixed mode, 
sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)

Tomcat version is 10.1.15 64 bit

The company we rent our VM servers from has installed Sentinel One that 
connects to the JVM through an agent. I have very little knowledge of what if 
anything this can do. Since this is the only thing out of the ordinary running 
on this setup, my fear is that this might be causing the crashes.


Some web searching suggests that is certainly likely.


I include a partial example of the exception log here, some data may have been 
removed for privacy reasons. Please let med know if I should include the full 
file, since I've removed parts of it due to pure length.


The full file might contain a few more hints as to what went wrong.

Mark




#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x1131b169, pid=2084, 
tid=5160
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.8.1+1 (17.0.8.1+1) 
(build 17.0.8.1+1)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (17.0.8.1+1, mixed mode, 
sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# j  
jakarta.servlet.http.HttpServletRequestWrapper.getDateHeader(Ljava/lang/String;)J+1
#
# Core dump will be written. Default location: E:\tomcat10\hs_err_pid2084.mdmp
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
#

---  S U M M A R Y 

Command Line: -Dcatalina.home=E:\tomcat10 -Dcatalina.base=E:\tomcat10 
-Dignore.endorsed.dirs=E:\tomcat10\endorsed -Djava.io.tmpdir=E:\tomcat10\temp 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.util.logging.config.file=E:\tomcat10\conf\logging.properties 
-Djava.locale.providers=COMPAT --add-opens=java.base/java.lang=ALL-UNNAMED 
--add-opens=java.base/java.io=ALL-UNNAMED 
--add-opens=java.base/java.util=ALL-UNNAMED 
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED 
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED exit abort -Xms768m 
-Xmx5090m -agentpath:C:\Program Files\SentinelOne\Sentinel Agent 
22.3.4.612\SentinelJava64.dll

Host: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz, 4 cores, 7G,  Windows Server 
2016 , 64 bit Build 14393 (10.0.14393.5786)
Time: Sat Nov 11 18:18:30 2023 W. Europe Standard Time elapsed time: 153.828934 
seconds (0d 0h 2m 33s)

---  T H R E A D  ---

Current thread (0x2e6a9bd0):  JavaThread 
"https-openssl-nio-0.0.0.0-443-exec-180" daemon [_thread_in_Java, id=5160, 
stack(0x403a,0x404a)]

Stack: [0x403a,0x404a],  sp=0x4049c1f8,  free 
space=1008k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x1131b169


siginfo: EXCEPTION_ACCESS_VIOLATION (0xc005), reading address 
0x

...

Stack slot to memory mapping:
stack at sp + 0 slots: 0x11309657 is at code_begin+1463 in an 
Interpreter codelet
return entry points  [0x113090a0, 0x11309ba0]  2816 bytes
stack at sp + 1 slots: 0x0061006200650077 is an unknown value
stack at sp + 2 slots: 0x4049c208 is pointing into the stack for 
thread: 0x2e6a9bd0
stack at sp + 3 slots: 0x2a938ae1 is pointing into metadata
stack at sp + 4 slots: 0x4049c268 is pointing into the stack for 
thread: 0x2e6a9bd0
stack at sp + 5 slots: 0x2a93e930 is pointing into metadata
stack at sp + 6 slots: 0x0 is NULL
stack at sp + 7 slots: 0x0006c5fd67d0 is an oop: java.lang.Class
{0x0006c5fd67d0} - klass: 'java/lang/Class'
  -  fields (total size 14 words):
  - private volatile transient 'classRedefinedCount' 'I' @12  0
  - private volatile transient 'cachedConstructor' 
'Ljava/lang/reflect/Constructor;' @40  NULL (0)
  - private transient 'name' 'Ljava/lang/String;' @44  
"jakarta.servlet.http.HttpServletRequestWrapper"{0x0006c5fd6840} (d8bfad08)
  - private transient 'module' 'Ljava/lang/Module;' @48  a 
'jav

Re: CredentialHandler not working for MD5

[Peter Otto]

Chris,

Running the debugger, I found out the DigestAuthenticator wants to use SHA-256. 
  8 months ago there was a change for RFC 7616.
https://github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java

To bypass the array of digest,
I commented out some code so it was forced to use MD5 only.

But In the RealmBase, I really don’t understand what getDigest is doing.
When I create a MD5 digest, I use Username:Realm:Password.
In the code it is using Nonce, nc, cnonce, gop…..




From: Christopher Schultz 
Date: Friday, November 10, 2023 at 1:44 PM
To: users@tomcat.apache.org 
Subject: Re: CredentialHandler not working for MD5
Peter,

On 11/10/23 16:30, Peter Otto wrote:
> With 9.0.82, and the latest version 10, I get the same problem.
> So I assume it stopped working since 9.0.74 all the way up to 9.0.82
>
> Removing the Realm LockOutRealm did not work either.

Thanks for double-checking both of those.

I don't see anything in the changelog that seems like it would be
related. Thing I suspect are related were in an earlier release.

Are you able to run under a debugger, and are you comfortable doing
that? It's pretty easy to set a breakpoint in the Realm and/or
CredentialHandler to see what's being done when you try to authenticate.

-chris

> From: Christopher Schultz 
> Date: Friday, November 10, 2023 at 12:35 PM
> To: users@tomcat.apache.org 
> Subject: Re: CredentialHandler not working for MD5
> Peter,
>
> On 11/10/23 13:27, Peter Otto wrote:
>> Logging into manager using MD5 works in 9.0.73 but now fails in 
>> 9.0.74->current
>> Steps to reproduce.
>>
>> Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 
>> tomcat:UserDatabase:nobueno
>>
>> tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0
>>
>>
>> Step 2. Use the digest # and place it in tomcat-users.xml
>> 
>> 
>> > roles="manager-gui,manager-script"/>
>>
>>
>> Step 3. Edit server.xml and add the CredentialHandler to use MD5
>>
>> 
>> > resourceName="UserDatabase">
>> > className="org.apache.catalina.realm.MessageDigestCredentialHandler" 
>> algorithm="MD5" />
>> 
>> 
>>
>>
>>
>> Step 4. Edit the web.xml in manager to say
>> 
>>   DIGEST
>>   UserDatabase
>> 
>>
>> Step 5 start tomcat and try to access the manager.
>> On WIndows 2019 server/Chrome/OpenJDK11  type tomcat for the user
>> and nobueno for the password.
>>
>> This would work on versions 9.0.73 and earlier
>>
>> This stopped working from 9.0.74 and onwards.
>> The way to access the manager from 9.0.74+ is to use 
>> bb6c1c32b9b6df4f707c0e58f2c900e0 as the password.
>> In other words the text in tomcat-user.xml is the password.
>>
>> Anyone have any ideas how to fix this?  I have to use 9.0.74+ version of 
>> tomcat because of CVEs.
>
> If you temporarily remove the LockOutRealm, does the correct password work?
>
> If you upgrade to 9.0.82, does the correct password work?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> This e-mail and any files transmitted with it are the property of Arthrex, 
> Inc. and/or its affiliates, are confidential, and are intended solely for the 
> use of the individual or entity to whom this e-mail is addressed. If you are 
> not one of the named recipient(s) or otherwise have reason to believe that 
> you have received this message in error, please notify the sender at 
> 239-643-5553 and delete this message immediately from your computer. Any 
> other use, retention, dissemination forwarding, printing or copying of this 
> e-mail is strictly prohibited. Please note that any views or opinions 
> presented in this email are solely those of the author and do not necessarily 
> represent those of the company. Finally, while Arthrex uses virus protection, 
> the recipient should check this email and any attachments for the presence of 
> viruses. The company accepts no liability for any damage caused by any virus 
> transmitted by this email.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This e-mail and any files transmitted with it are the property of Arthrex, Inc. 
and/or its affiliates, are confidential, and are intended solely for the use of 
the individual or entity to whom this e-mail is addressed. If you are not one 
of the named recipient(s) or otherwise have reason to believe that you have 
received this message in error, please notify the sender at 239-643-5553 and 
delete this message immediately from your computer. Any other use, retention, 
dissemination forwarding, printing or copying of this e-mail is strictly 
prohibited. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Fi

Is the HTTP/2 Rapid Reset Exploit still possible on 2.4.58?

[Dan McLaughlin]

In the past several weeks, we've been dealing with what seems to be a
denial of service attack against our site.  We were seeing similar messages
in our logs before Apache became unresponsive. I contributed it to
the HTTP/2 Rapid Reset Exploit because we ran 2.4.57 then.  Last week, I
upgraded to 2.4.58, but we were hit again today.  In this case, these
messages started about 48 hours ago until the httpd process finally became
unresponsive.  There wasn't a single request in the access logs from this
source IP, just these repeated messages in the error log.   Besides
blocking the IP, can I change any settings to protect against this?  Maybe
a mod_qos configuration?

[Mon Nov 13 13:25:49.099207 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:26:49.102423 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:27:49.105261 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:28:49.108454 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:29:49.110794 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:30:49.113728 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:31:49.116023 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:32:49.119196 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:33:49.122450 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:34:49.124970 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:35:49.127724 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:36:49.130275 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:37:49.133470 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:38:49.136233 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:39:49.138935 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:40:49.141993 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:41:49.144710 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:42:49.147057 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:43:49.150223 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:44:49.152579 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:45:49.155121 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:46:49.158183 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:47:49.161432 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:48:49.164256 2023] [http2:warn] [pid 124004:tid 492] [client
172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
scheduled=1, ready=0, out_buffer=0
[Mon Nov 13 13:49:49.167331 2023] [http2:warn] [pid 124004:tid 492] [client
1

Re: AW: FileUpload class not working with Tomcat 10.1

[Mark Foley]

On Mon Nov 13 02:18:49 2023 "Thomas Hoffmann (Speed4Trade GmbH)" 
 wrote:
> Hello,
>
> > -Ursprüngliche Nachricht-
> > Von: Mark Foley 
> > Gesendet: Sonntag, 12. November 2023 19:04
> > An: users@tomcat.apache.org
> > Betreff: Re: FileUpload class not working with Tomcat 10.1
> > 
> > On Fri Nov 10 15:57:50 2023 Christopher Schultz
> >  wrote:
> > >
> > > Mark,
> > >
> > > On 11/10/23 12:53, Mark Foley wrote:
> > > > On Fri, 10 Nov 2023 17:11:59 Mark Thomas  > > >>
> > > >> On 10/11/2023 16:49, Mark Foley wrote:
> > > >>> I recently upgraded from Tomcat 10.0.17 to 10.1.13.  ...
> > > >>>
> > > >>> [deleted]
> > >
> > I've put your suggested code in place. 
> >
> > <%@ page import="jakarta.servlet.http.Part" %>
> >
> > I replaced your:
> > 
> >   throw new IllegalStateException("Expected multi-part");
> > 
> > with:
> > 
> > out.println("Expected multi-part");
> > 
> > Just to get things compiling OK.  I'll deal with errors later. With that 
> > change, it
> > compiled w/o problem.  I then attempted an upload.  The line:
> > 
> >if(null == contentType || 
> > !contentType.startsWith("multipart/form-data;"))
> > {
> > 
> > returned TRUE so it did detect a multipart upload. Yay! That was a relief
> > However
> > 
> >Part fileUpload = request.getPart("param-name");
> > 
> > Gave me the error:
> > 
> > java.lang.IllegalStateException: Unable to process parts as no multi-part
> > configuration has been provided
> > 
> > So, what does it mean that "no multi-part configuration has been provided"?
> > Is "param-name" something I'm supposed to fill in? I tried substituting the
> >  field name, "taxResults", but that gave the same error.
>
> The form element must have the attribute enctype="multipart/form-data".
> Furthermore, the servlet must be annotated by "@MultipartConfig"
>
> I think for jsp files, there is a similar setting in the web.xml.
> This link might help out: 
> https://stackoverflow.com/questions/37965890/add-annotation-to-jsp 

Thanks for your reply Thomas.

I've checked your suggested link and I have no idea where to put all that 
stuff.  Furthermore, the poster of that issue didn't say he got it working.

A respnder to the post said, "Actually every jsp file will be converted to
servlet because tomcat can only address servlet and so every jsp file is
indirectly a servlet and has all the features of it". I think he is suggesting
that the  code is superfluous, but not exlpicitly stated as such.

I am getting a TRUE return for 

  if(null == contentType || !contentType.startsWith("multipart/form-data;"))

so I think it is recognizing it as "multipart/form-data;".

Does anyone have an example of a JSP program with jakarta.servlet.http.Part
class?

I'll search for examples as well, but I really have no idea how to proceed.

--Mark F.

> > >
> > > -chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is the HTTP/2 Rapid Reset Exploit still possible on 2.4.58?

[Chuck Caldarale]

You may have the wrong mailing list - this one is for Tomcat, but your query 
seems to be solely about Apache httpd.

  - Chuck



> On Nov 13, 2023, at 16:03, Dan McLaughlin  wrote:
> 
> In the past several weeks, we've been dealing with what seems to be a
> denial of service attack against our site.  We were seeing similar messages
> in our logs before Apache became unresponsive. I contributed it to
> the HTTP/2 Rapid Reset Exploit because we ran 2.4.57 then.  Last week, I
> upgraded to 2.4.58, but we were hit again today.  In this case, these
> messages started about 48 hours ago until the httpd process finally became
> unresponsive.  There wasn't a single request in the access logs from this
> source IP, just these repeated messages in the error log.   Besides
> blocking the IP, can I change any settings to protect against this?  Maybe
> a mod_qos configuration?
> 
> [Mon Nov 13 13:25:49.099207 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:26:49.102423 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:27:49.105261 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:28:49.108454 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:29:49.110794 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:30:49.113728 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:31:49.116023 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:32:49.119196 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:33:49.122450 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:34:49.124970 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:35:49.127724 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:36:49.130275 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:37:49.133470 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:38:49.136233 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:39:49.138935 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:40:49.141993 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:41:49.144710 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:42:49.147057 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:43:49.150223 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:44:49.152579 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:45:49.155121 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:46:49.158183 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> scheduled=1, ready=0, out_buffer=0
> [Mon Nov 13 13:47:49.161432 2023] [http2:warn] [pid 124004:tid 492] [client
> 172.56.15.1

Re: CredentialHandler not working for MD5

[Peter Otto]

More info….



In the Request Header-> Authorization->Response.  Response is used as the 
clientDigest.  However this response is generated, it is incorrect.

Need to understand where Tomcat generates this Response because it is used for 
comparison of the serverDigest.  And if the server digest equals the 
clientDigest, then it works.



The way I understand it, the clientDigest comes from the client entering in the 
username/pwd on the popup box.




From: Peter Otto 
Date: Monday, November 13, 2023 at 11:05 AM
To: Tomcat Users List 
Subject: Re: CredentialHandler not working for MD5
Chris,

Running the debugger, I found out the DigestAuthenticator wants to use SHA-256. 
  8 months ago there was a change for RFC 7616.
https://urldefense.com/v3/__https://github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java__;!!P192cPdC!gngwaC1JS3mDrQRjm-kpcOFNPuIBaF56P2aVV9vgLqK1CJAqprPgZBsUjm671wxFYUYKD6tJCCzjvQLczAw0$

To bypass the array of digest,
I commented out some code so it was forced to use MD5 only.

But In the RealmBase, I really don’t understand what getDigest is doing.
When I create a MD5 digest, I use Username:Realm:Password.
In the code it is using Nonce, nc, cnonce, gop…..




From: Christopher Schultz 
Date: Friday, November 10, 2023 at 1:44 PM
To: users@tomcat.apache.org 
Subject: Re: CredentialHandler not working for MD5
Peter,

On 11/10/23 16:30, Peter Otto wrote:
> With 9.0.82, and the latest version 10, I get the same problem.
> So I assume it stopped working since 9.0.74 all the way up to 9.0.82
>
> Removing the Realm LockOutRealm did not work either.

Thanks for double-checking both of those.

I don't see anything in the changelog that seems like it would be
related. Thing I suspect are related were in an earlier release.

Are you able to run under a debugger, and are you comfortable doing
that? It's pretty easy to set a breakpoint in the Realm and/or
CredentialHandler to see what's being done when you try to authenticate.

-chris

> From: Christopher Schultz 
> Date: Friday, November 10, 2023 at 12:35 PM
> To: users@tomcat.apache.org 
> Subject: Re: CredentialHandler not working for MD5
> Peter,
>
> On 11/10/23 13:27, Peter Otto wrote:
>> Logging into manager using MD5 works in 9.0.73 but now fails in 
>> 9.0.74->current
>> Steps to reproduce.
>>
>> Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 
>> tomcat:UserDatabase:nobueno
>>
>> tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0
>>
>>
>> Step 2. Use the digest # and place it in tomcat-users.xml
>> 
>> 
>> > roles="manager-gui,manager-script"/>
>>
>>
>> Step 3. Edit server.xml and add the CredentialHandler to use MD5
>>
>> 
>> > resourceName="UserDatabase">
>> > className="org.apache.catalina.realm.MessageDigestCredentialHandler" 
>> algorithm="MD5" />
>> 
>> 
>>
>>
>>
>> Step 4. Edit the web.xml in manager to say
>> 
>>   DIGEST
>>   UserDatabase
>> 
>>
>> Step 5 start tomcat and try to access the manager.
>> On WIndows 2019 server/Chrome/OpenJDK11  type tomcat for the user
>> and nobueno for the password.
>>
>> This would work on versions 9.0.73 and earlier
>>
>> This stopped working from 9.0.74 and onwards.
>> The way to access the manager from 9.0.74+ is to use 
>> bb6c1c32b9b6df4f707c0e58f2c900e0 as the password.
>> In other words the text in tomcat-user.xml is the password.
>>
>> Anyone have any ideas how to fix this?  I have to use 9.0.74+ version of 
>> tomcat because of CVEs.
>
> If you temporarily remove the LockOutRealm, does the correct password work?
>
> If you upgrade to 9.0.82, does the correct password work?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> This e-mail and any files transmitted with it are the property of Arthrex, 
> Inc. and/or its affiliates, are confidential, and are intended solely for the 
> use of the individual or entity to whom this e-mail is addressed. If you are 
> not one of the named recipient(s) or otherwise have reason to believe that 
> you have received this message in error, please notify the sender at 
> 239-643-5553 and delete this message immediately from your computer. Any 
> other use, retention, dissemination forwarding, printing or copying of this 
> e-mail is strictly prohibited. Please note that any views or opinions 
> presented in this email are solely those of the author and do not necessarily 
> represent those of the company. Finally, while Arthrex uses virus protection, 
> the recipient should check this email and any attachments for the presence of 
> viruses. The company accepts no liability for any damage c

Re: Is the HTTP/2 Rapid Reset Exploit still possible on 2.4.58?

[Dan McLaughlin]

Yep, wrong list. Sorry.



On Mon, Nov 13, 2023 at 4:37 PM Chuck Caldarale  wrote:

> You may have the wrong mailing list - this one is for Tomcat, but your
> query seems to be solely about Apache httpd.
>
>   - Chuck
>
>
>
> > On Nov 13, 2023, at 16:03, Dan McLaughlin 
> wrote:
> >
> > In the past several weeks, we've been dealing with what seems to be a
> > denial of service attack against our site.  We were seeing similar
> messages
> > in our logs before Apache became unresponsive. I contributed it to
> > the HTTP/2 Rapid Reset Exploit because we ran 2.4.57 then.  Last week, I
> > upgraded to 2.4.58, but we were hit again today.  In this case, these
> > messages started about 48 hours ago until the httpd process finally
> became
> > unresponsive.  There wasn't a single request in the access logs from this
> > source IP, just these repeated messages in the error log.   Besides
> > blocking the IP, can I change any settings to protect against this?
> Maybe
> > a mod_qos configuration?
> >
> > [Mon Nov 13 13:25:49.099207 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:26:49.102423 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:27:49.105261 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:28:49.108454 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:29:49.110794 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:30:49.113728 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:31:49.116023 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:32:49.119196 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:33:49.122450 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:34:49.124970 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:35:49.127724 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:36:49.130275 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:37:49.133470 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:38:49.136233 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:39:49.138935 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:40:49.141993 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:41:49.144710 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:42:49.147057 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:43:49.150223 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:44:49.152579 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, ready=0, out_buffer=0
> > [Mon Nov 13 13:45:49.155121 2023] [http2:warn] [pid 124004:tid 492]
> [client
> > 172.56.15.107:7282] h2_stream(124004-2515-15,CLEANUP): started=1,
> > scheduled=1, read

AW: AW: FileUpload class not working with Tomcat 10.1

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mark,


> -Ursprüngliche Nachricht-
> Von: Mark Foley 
> Gesendet: Montag, 13. November 2023 23:12
> An: users@tomcat.apache.org
> Betreff: Re: AW: FileUpload class not working with Tomcat 10.1
> 
> On Mon Nov 13 02:18:49 2023 "Thomas Hoffmann (Speed4Trade GmbH)"
>  wrote:
> > Hello,
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Mark Foley 
> > > Gesendet: Sonntag, 12. November 2023 19:04
> > > An: users@tomcat.apache.org
> > > Betreff: Re: FileUpload class not working with Tomcat 10.1
> > >
> > > On Fri Nov 10 15:57:50 2023 Christopher Schultz
> > >  wrote:
> > > >
> > > > Mark,
> > > >
> > > > On 11/10/23 12:53, Mark Foley wrote:
> > > > > On Fri, 10 Nov 2023 17:11:59 Mark Thomas  wrote:
> > > > >>
> > > > >> On 10/11/2023 16:49, Mark Foley wrote:
> > > > >>> I recently upgraded from Tomcat 10.0.17 to 10.1.13.  ...
> > > > >>>
> > > > >>> [deleted]
> > > >
> > > I've put your suggested code in place.
> > >
> > > <%@ page import="jakarta.servlet.http.Part" %>
> > >
> > > I replaced your:
> > >
> > >   throw new IllegalStateException("Expected multi-part");
> > >
> > > with:
> > >
> > > out.println("Expected multi-part");
> > >
> > > Just to get things compiling OK.  I'll deal with errors later. With
> > > that change, it compiled w/o problem.  I then attempted an upload.  The
> line:
> > >
> > >if(null == contentType ||
> > > !contentType.startsWith("multipart/form-data;"))
> > > {
> > >
> > > returned TRUE so it did detect a multipart upload. Yay! That was a
> > > relief However
> > >
> > >Part fileUpload = request.getPart("param-name");
> > >
> > > Gave me the error:
> > >
> > > java.lang.IllegalStateException: Unable to process parts as no
> > > multi-part configuration has been provided
> > >
> > > So, what does it mean that "no multi-part configuration has been
> provided"?
> > > Is "param-name" something I'm supposed to fill in? I tried
> > > substituting the  field name, "taxResults", but that
> gave the same error.
> >
> > The form element must have the attribute enctype="multipart/form-
> data".
> > Furthermore, the servlet must be annotated by "@MultipartConfig"
> >
> > I think for jsp files, there is a similar setting in the web.xml.
> > This link might help out:
> > https://stackoverflow.com/questions/37965890/add-annotation-to-jsp
> 
> Thanks for your reply Thomas.
> 
> I've checked your suggested link and I have no idea where to put all that
>  stuff.  Furthermore, the poster of that issue didn't say he got it
> working.
> 
> A respnder to the post said, "Actually every jsp file will be converted to
> servlet because tomcat can only address servlet and so every jsp file is
> indirectly a servlet and has all the features of it". I think he is 
> suggesting that
> the  code is superfluous, but not exlpicitly stated as such.
> 
> I am getting a TRUE return for
> 
>   if(null == contentType || !contentType.startsWith("multipart/form-data;"))
> 
> so I think it is recognizing it as "multipart/form-data;".
> 
> Does anyone have an example of a JSP program with
> jakarta.servlet.http.Part class?
> 
> I'll search for examples as well, but I really have no idea how to proceed.
> 
> --Mark F.
> 

The servlet specification defines the special folder WEB-INF.
Within this folder, there is the configuration file named web.xml.
Within this xml-File, the application is configured including the servlets.
JSP-Files are compiled to servlets, either on-the-fly or during compilation 
time.

I would recommend to take a look at some sample applications to get familiar 
with some java web-applications and the web.xml file.

It is not only about the jsp-file but also the combination with the application 
configuration within the web.xml
Thus you will need both, jsp-file and a corresponding web.xml configuration.

Greetings!
Thomas

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org