I apologize for the delay in my response. It took some time to confirm the details.
To get straight to the point, I found that the maxFileSize value was not set. This seems like it could have an impact, but I'd like to ask for your clarification. My setup uses Apache and Tomcat, and I have configured the limit_requestbody.conf in Apache to limit the request body size for all HTTP methods. I understand that in an Apache + Tomcat configuration, limit_requestbody is checked first. Given this, I believe that even if maxFileSize is not specified, the request body size can still be limited by limit_requestbody.conf. Is my understanding correct? ________________________________ 差出人: Mark Thomas <ma...@apache.org> 送信日時: 2025年8月5日 17:09 宛先: users@tomcat.apache.org <users@tomcat.apache.org> 件名: Re: [SECURITY INQUIRY] CVE-2025-52520: Regarding "Unlikely Configurations of Multipart Upload" that are Affected On 05/08/2025 07:03, 加治屋 一輝 wrote: > Thank you for your response, Mark. Based on your answer, I have confirmed the > settings. > Please confirm the settings for maxPostSize and maxFileSize. > > The settings are as follows. > - maxPostSize: set on the Connector. Sets the maximum total size for all > non-file parts > - maxFileSize: set on the multi-part configuration. Sets the maximum size for > a single part (file and non-file) > > We have set maxPostSize in our environment, but we have not set maxFileSize. > When sending files in multipart format via a POST request, the maxPostSize > limit is reached, and large files cannot be transmitted. > In other words, we believe that maxPostSize limits the total size of the > entire POST, including files, but is this incorrect? Generally, yes. It is incorrect. But it depends. There are circumstances in which maxPostSize is used as the default for maxFileSize. To analyse your configuration we would need to see: - the full connector configuration - the multi-part configuration used by the servlet (could be in web.xml or in an annotation) > The implementation we investigated is as follows. > > <form id="mainForm" name="mainForm" action="/hoge/hoge" method="post" > enctype="multipart/form-data" onsubmit="return false;" autocomplete="off"> That is client-side code and plays not role (apart from defining the upload format) in how Tomcat handles the request. All of that said, the size of an uploaded file does not count towards the limit set by maxPostSize. Mark > > Please confirm the above. > ________________________________ > 差出人: Mark Thomas <ma...@apache.org> > 送信日時: 2025年7月25日 15:40 > 宛先: users@tomcat.apache.org <users@tomcat.apache.org> > 件名: Re: [SECURITY INQUIRY] CVE-2025-52520: Regarding "Unlikely Configurations > of Multipart Upload" that are Affected > > On 25/07/2025 03:42, 加治屋 一輝 wrote: > > <snip/> > >> Specifically, the following point is unclear to us: >> The advisory mentions "unlikely configurations of multipart upload." >> Could you please specify what types of configurations are considered >> "unlikely" and would therefore be affected by this vulnerability? Please >> provide specific examples or characteristics. > > There are various limits that apply to a multi-part upload. The ones > that matter in this scenario are: > > - maxPostSize: set on the Connector. Sets the maximum total size for > all non-file parts > - maxFileSize: set on the multi-part configuration. Sets the maximum > size for a single part (file and non-file) > > If maxFileSize + maxPostSize > 2^31 then it was possible to bypass > maxPostSize, load large non-file parts into memory and (with enough > non-file parts / requests) trigger a DoS. > > The unlikely aspect was that untrusted users would be allowed to upload > files ~2Gb in size. > > Kind regards, > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
