CVE-2023-24998 : Apache Denial of Service

2023-03-15 Thread S Abirami
Hi All,

Currently, In our product we are using 9.0.65 version of Tomcat.
We are not using FileUpload option in any of our application and in Servlet.
We don't have any config to limit the file uploads also.

Whether our attacker still able to perform a malicious upload to our server via 
url.
Please let me know you input regarding this CVE-2023-24998 vulnerability. 
Whether our application is vulnerable (or) not.

Regards,
Abirami.S

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



Re: Excluded service.bat From Maven Artefact

2023-03-15 Thread LANDER Tim
> On 3/15/23 22:01, LANDER Tim wrote:
> > Hi, I've noticed that service.bat and Tomcat.exe (Actually all exe's: 
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fblob%2F6de806a21adc68a23aa4043c67c0d80bbab1c458%2Fbuild.xml%23L2825-L2828=05%7C01%7C%7Ce96c8721d0554f67c2d708db25d3fd88%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C638145364653337506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=FQXKYh0X%2BKPY%2B0IS52L2j25hpnHL0SScWsRkZqwfj%2BY%3D=0)
> >  are excluded from the tomcat maven artefact (org.apache.tomcat:tomcat). 
> > What's the reason for this? I couldn't find it documented anywhere.
> >
> > This makes it a bit annoying trying to add tomcat to a (Windows) installer. 
> > I know I can download and extract those files from
> > archieve.apache.org, but it makes automating this process unnecessarily 
> > annoying.
> > -
>>  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> Isn't Tomcat a java app, using jar files?

There's a apache-tomcat-10.0.27-windows-x64.zip under 
https://archive.apache.org/dist/tomcat/tomcat-10/v10.0.27/bin/ that contains 
service.bat and Tomcat.exe.
In fact, org.apache.tomcat:tomcat contains several bat/sh files under /bin. So 
it's clear to me that Tomcat is more than just a java app.
Also apologises for safelinks butchering my links, I can't disable that on this 
account.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Excluded service.bat From Maven Artefact

2023-03-15 Thread Rob Sargent




On 3/15/23 22:01, LANDER Tim wrote:

Hi, I've noticed that service.bat and Tomcat.exe (Actually all exe's: 
https://github.com/apache/tomcat/blob/6de806a21adc68a23aa4043c67c0d80bbab1c458/build.xml#L2825-L2828)
 are excluded from the tomcat maven artefact (org.apache.tomcat:tomcat). What's 
the reason for this? I couldn't find it documented anywhere.

This makes it a bit annoying trying to add tomcat to a (Windows) installer. I 
know I can download and extract those files from
archieve.apache.org, but it makes automating this process unnecessarily 
annoying.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


Isn't Tomcat a java app, using jar files?

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



Excluded service.bat From Maven Artefact

2023-03-15 Thread LANDER Tim
Hi, I've noticed that service.bat and Tomcat.exe (Actually all exe's: 
https://github.com/apache/tomcat/blob/6de806a21adc68a23aa4043c67c0d80bbab1c458/build.xml#L2825-L2828)
 are excluded from the tomcat maven artefact (org.apache.tomcat:tomcat). What's 
the reason for this? I couldn't find it documented anywhere.

This makes it a bit annoying trying to add tomcat to a (Windows) installer. I 
know I can download and extract those files from 
archieve.apache.org, but it makes automating this process unnecessarily 
annoying.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-15 Thread Bhavesh Mistry
Hi Mark and Tomcat Team,

We have been using tomcat 9 from version 0 to 70 and no issues so far with
our application and firefox.  We also tried to upgrade to 9.0.73, and show
the same issue:

As you can see from Devtools it is missing Protocol HTTP2 and is hung there.
[image: image.png]

[04/Mar/2023:00:40:47 +] 10.40.207.127 -
https-jsse-nio-127.0.0.1-8443-exec-54 Administrator "GET
/versa/ncs-services/vnms/analyticgroup/all *HTTP/2.0*" 204 - 148ms 148ms


Any clue you have in the filter or why it might be 204 response caused
firefox to be hung?  we have added a custom header to the response that is
all.   I remove them still same issue.  Any theory or clue you have further
to debug this notorious issue?

Thanks,


Bhavesh


On Thu, Mar 9, 2023 at 11:54 AM Mark Thomas  wrote:

> On 09/03/2023 18:19, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > Your sample application worked 204 Firefox and our application does not
> > work.  That leads me to believe *Application Filter *is an issue. But
> > should tomcat throw an exception if the response is already committed?
>
> A call to setStatus() after the response has been committed will be a
> NO-OP.
>
> >  I
> > will try to see if I can reproduce it using a filter with the sample app
> > you gave me.Only one line change  (streamOutputBuffer.closed = true)
> > would make our application work.  So it seems to me that the application
> > filter is writing something after the stream is closed and this may lead
> to
> > this behavior.  I will try to reproduce using this app.   Do still
> consider
> > this application bug or a tomcat platform bug?
>
> Definitely an application bug.
>
> Mark
>
> >
> > Thank you so far for your excellent support and quick responses.
> >
> > Thanks,
> >
> > Bhavesh
> >
> >
> >
> > On Thu, Mar 9, 2023 at 1:14 AM Mark Thomas  wrote:
> >
> >> On 08/03/2023 21:32, Bhavesh Mistry wrote:
> >>> Hi  Mark,
> >>>
> >>> We have a NAT rule that forwards 443 to 8443.
> >>
> >> OK. That explains the change in port.
> >>
> >>> Trust me on that, we have a
> >>> direct connection. To rule out any networking layer issues, I did
> >>> direct ssh -L 8443:localhost:8443 admin@10.40.207.140 and created a
> >> tunnel
> >>> (https://localhost:8443/)  to bypass port 443. Yet, the issue is still
> >>> reproducible. So there is *NOTHING* in the middle that could cause this
> >>> issue.
> >>
> >> There must be. Could be a FireFox plugin, a Filter used by the web
> >> application, a Valve for a third-party authentication module, etc.
> >>
> >> Try deploying this war:
> >> https://people.apache.org/~markt/dev/no-content-test.war
> >>
> >> It contains 2 JSPs.
> >> index.jsp has a link to no-content.jsp
> >> no-content.jsp just returns a 204
> >>
> >> This works as expected, with no errors with the latest 9.0.x code,
> >> 9.0.72, Chrome and FireFox.
> >>
> >> If it works when deployed to your server, that points to something in
> >> the web application. If it doesn't work, that points to something in the
> >> network and/or browser.
> >>
> >> Mark
> >>
> >> * Is publicly exposing tomcat enough for debugging *or do you still
> >>> need an independent application?  I can have SSH open but you will have
> >> to
> >>> give me your private email to email credentials and public IP.
> >>>
> >>> sudo iptables -t nat -L
> >>> Chain PREROUTING (policy ACCEPT)
> >>> target prot opt source   destination
> >>> VNMS   all  --  anywhere anywhere
> >>>
> >>> Chain INPUT (policy ACCEPT)
> >>> target prot opt source   destination
> >>>
> >>> Chain OUTPUT (policy ACCEPT)
> >>> target prot opt source   destination
> >>>
> >>> Chain POSTROUTING (policy ACCEPT)
> >>> target prot opt source   destination
> >>> MASQUERADE  tcp  --  172.17.0.2   172.17.0.2   tcp
> >> dpt:8000
> >>>
> >>> Chain DOCKER (0 references)
> >>> target prot opt source   destination
> >>> DNAT   tcp  --  anywhere anywhere tcp
> >> dpt:8000
> >>> to:172.17.0.2:8000
> >>>
> >>> Chain VNMS (1 references)
> >>> target prot opt source   destination
> >>> DNAT   tcp  --  anywhere anywhere tcp
> >> dpt:http
> >>> to:127.0.0.1:8080
> >>> *DNAT   tcp  --  anywhere anywhere tcp
> >>> dpt:https to:127.0.0.1:8443 // this rule
> >> Fowards
> >>> it to the 8443.*
> >>> admin@SDWAN-VOAE1:~$
> >>>
> >>> On Wed, Mar 8, 2023 at 12:29 PM Mark Thomas  wrote:
> >>>
>  On 08/03/2023 19:52, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > It is a *direct connection* with no proxy or no reverse proxy or no
> >> load
> > balancer in the middle.  We have a web app (UI) that make backend
> call
>  and
> > return 204 with no content and send it to the browser.  An
> interesting
>  fact
> > is very thing works on Chrome but not with firefox.  We have tried
> > 

RE: HTTP2: How to check if the client aborted a request

2023-03-15 Thread EXT-Denton, Sam T
I am also interested in this.  In my case, we added an "Abort Request" link to 
the placeholder page that is displayed while the calculation is on-going, but 
naturally nobody ever clicks on it.  :O  I am solidly In favor of anything that 
fixes this.

Sam Denton (he/him)
Advisor, Solutions Architect 
Mobile (314) 827-4017
24x7 SBS Suppot (405) 312-9936

Advanced Leave Notice: NONE

-Original Message-
From: Robin Stevens  
Sent: Tuesday, March 14, 2023 4:01 AM
To: users@tomcat.apache.org
Subject: HTTP2: How to check if the client aborted a request

Use case / problem:

The frontend is doing requests that trigger heavy calculations in the backend. 
Often these requests get cancelled by the frontend before the backend has 
finished doing the calculations.

The cancellation of the requests is done by using an AbortController 
(https://developer.mozilla.org/en-US/docs/Web/API/AbortController) to abort the 
fetch (similar to this example 
https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort#examples).

When aborting a fetch that happens over HTTP2, an RST_FRAME is send to the 
server.

I'm trying to figure out how to detect in the backend that such an RST_FRAME 
has been received, and stop doing my calculation.

This is done in a Spring Boot Application using the embedded Tomcat webserver, 
but I would already be glad if I can get a pointer on how to get this 
information in Tomcat through public apis. 
I'm hopeful I can figure out the integration with Spring myself.


Investigation:

What I already found is that the RST_FRAME is received in the backend, at which 
point the state in the org.apache.coyote.http2.StreamStateMachine switches to 
CLOSED_RST_TX. 
After that state switch, the 
org.apache.coyote.http2.StreamStateMachine#canWrite method returns false which 
I think is the information I need.
After all, if the result of my calculation cannot be written to the stream, 
there is no point in doing it.

The problem is that this information is hidden behind a bunch of package 
visible/protected classes and methods so I cannot access it without relying on 
reflection and implementation details.
And I couldn't find anything in the source code that exposes this information 
publicly. 
So I'm not even sure I'm on the right track here.

Does anybody has a pointer on how to obtain this info through official APIs, or 
to some documentation related to this that I might have missed ?

Thanks,

Robin


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



CVE-2023-24998 : Apache Denial of Service

2023-03-15 Thread S Abirami
Hi All,

Currently, In our product we are using 9.0.65 version of Tomcat.
We are not using FileUpload option in any of our application and in Servlet.
We don't have any config to limit the file uploads also.

Whether our attacker still able to perform a malicious upload to our server via 
url.
Please let me know you input regarding this CVE-2023-24998 vulnerability. 
Whether our application is vulnerable (or) not.

Regards,
Abirami.S