CVE-2023-24998 and why the ESAPI 2.5.2.0 release is momentarily delayed #782
Replies: 2 comments 1 reply
-
|
Some good news. Deeper analysis of Apache Commons FileUpload and the ESAPI WAF shows that the ESAPI WAF is not impacted. I've updated Security Bulletin # 11 to reflect that as well as adding details on the mitigation that ESAPI is rolling out to address CVE-2023-24998. |
Beta Was this translation helpful? Give feedback.
-
|
The updated security bulletin is now there. Much better than the first preliminary draft, especially the consistency of the font! (Looking at you @xeno6696. :-) The biggest change is in the 'Solution' section. Sorry I took so long. I originally accidentally uploaded it to my personal forked repo and then I spent then next 15 minutes wondering what happened to it. D'oh! |
Beta Was this translation helpful? Give feedback.
-
|
PR #784 is underway and being reviewed by the ESAPI team, but there one thing that I wanted to make clear to the ESAPI user community that is, while I believe that I have addressed CVE-2023-24998 as much as possible (and then some), I do believe that without additional work by the ESAPI users in their application and/or production environment, for those of you who are using any of the ESAPI That said, I made extensive revisions to the Therefore, I have a favor to ask all of you...please look at the updated Or you can review the completely revised file here: Since there is a table in the Javadoc, it may be best to just clone https://github.com/kwwall/esapi-java-legacy.git and pull down branch '2.5.2.0-release' and then run ' That said, it should be known that I will be starting to work with GitHub Security to create a new CVE that reflects these DoS attacks from the perspective of someone using ESAPI so that I can point out the more specific remediation that is described in the new security bulletin. However, my bluntness and honesty sometimes has a way of backfiring and it wouldn't surprise me if NVD argues "No, the CVE should not be closed because there still is a DoS attack on the ESAPI file uploads feature". It is what it is. There's not a lot that I or GitHub can do from them deciding that it is not fixed or that the CVSSv3.1 score shouldn't be higher than what GitHub as the CNA suggests. |
Beta Was this translation helpful? Give feedback.
-
Roughly 3 weeks ago, I wrote this response( ESAPI/esapi-java#16 (comment)) to @mbektchiev in answer a question of whether ESAPI was vulnerable to CVE-2023-24998, a DoS vulnerability in Apache Files Commons Upload that potentially could allow an attacker to exhaust all the available inodes on a file system used to host uploaded files. I answered (correctly) that the only parts of ESAPI that used Apache Commons FileUpload was the various
HTTPUtilities.getFileUploads()methods andESAPIWebApplicationFirewallFilter, the ESAPI WAF component. However, at that time I had only did some contextual diffs on between the 1.4 and 1.5 releases of Apache Commons FileUpload rather than a deeper analysis that I always have done when I write up security bulletins. Unfortunately, because I answered without that more thorough analysis, I erred in my initial conclusion that ESAPI was not impacted by this CVE. It, in fact, is.So, that is what caused delay in the 2.5.2.0 release...this last moment mad scramble, to patch ESAPI at least to some degree and rewrite the initial cut at the security bulletin that I had 90% or more finished (albeit with the wrong conclusion).
Things are still not quite ready for release, but I am going to be working with GHAS to get a new CVE created for this for ESAPI so I can be more specific in the guidance offered. (I am not particularly concerned about the bad guys finding out that ESAPI is impacted. Most of them probably knew this before I did, so there is little to be gained by not being 100% transparent. In fact I only refrained from telling people before drafting a suitable new security bulletin lest the ESAPI team be deluged by a bunch of questions that would take most of our time t answer.)
In the meantime, I would suggest that you read the new Security Bulletin # 11, which at this point is still a preliminary draft, complete with a semi-rant by yours truly.
I certainly apologize if I lead anyone astray. That certainly was not my intent.
As to when the 2.5.2.0 release is available, it will be ready as soon as I can get it ready. I hope to have a PR for the ESAPI team to review at least by Friday evening. I am also working with the GitHub Security Team and I want to at least get a CVE # issued before doing the release because doing the actual release ceremony and writing up all the accompanying documentation artifacts is a major undertaking and I do not wish to do two releases in such a short time span. So we ask for your patience.
If you are not using any of the
HTTPUtilities.getFileUploads()methods or the ESAPI WAF you are NOT impacted by CVE-2023-24998 and you can get your SCA tools to stop complaining by using the Workaround section in the new security bulletin. If yo are using one of theHTTPUtilities.getFileUploads()methods or the ESAPI WAF that the "fix" that Apache applied is not really remediation. I just makes it a little harder for an attacker to run your file system out of inodes (or whatever the Windows equivalent is for those of you using NTFS or FAT32 or whatever). I discuss this in the Impact section. In reality, the Apache fix barely raises the bar of difficulty.Anyhow, please read the draft of the new Security Bulletin. It will explain some things. Then if you have questions, you can follow them up here on in the Q&A section.
Beta Was this translation helpful? Give feedback.
All reactions