esapi next release?

[Eyal Kalimi]

Hi,

We are using esapi 2.5.1.0 which has some vulnerability issue

Where can I see what the planed date of the next release is?

Thanks!

 - Eyal

[Kevin W. Wall]

On Wed, Mar 22, 2023 at 11:15 AM Eyal Kalimi <naz...@gmail.com> wrote:

Hi,

We are using esapi 2.5.1.0 which has some vulnerability issue

Where can I see what the planed date of the next release is?

Eyal,

 

No promises, but now that I finally have gotten my 2022 taxes submitted (just mailed them today), I'm going to try getting a new release out this weekend. That is if I can motivate myself to write up release notes and a new security bulletin to cover that CVE in Apache Commons File Upload that you are referring to (CVE-2023-24998).

That said, if you are not doing file uploads via ESAPI, that attack scenario portrayed in that CVE is not applicable at all. I suspect that most ESAPI users fall into that category. While analyzing the exploitability of CVE-2023-24998 through ESAPI, I found out that that particular CVE is not exploitable because ESAPI doesn't use the class in question that was fixed. However, CVE-2023-24998 states this:

Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads. Note that, like all of the file upload limits, the new configuration option (FileUploadBase#setFileCountMax) is not enabled by default and must be explicitly configured.

Essentially, if an application was using org.apache.commons.fileupload.FileUploadBase prior to release 1.5 and not restricting the number of files by setting a maximum via FileUploadBase.setFileCountMax(), then it was exploitable as it will allow an attacker who was able to do file uploads to your application to mount a DoS attack by uploading some unbounded # of files to  your application. ESAPI doesn't use the affected class, but instead it uses ServletFileUpload. However, while ESAPI has an upper bound on the total size of all the files uploaded per session, it does not place a maximum on the # of files uploaded per session, so I imagine that a similar DoS may still be possible with ESAPI regardless of what version of Apache Commons File Upload it is using.

I wrote about it in more detail on an issue that was mistakenly assigned to the wrong ESAPI GitHub repo. You can read more about my analysis here:

https://github.com/ESAPI/esapi-java/issues/16#issuecomment-1473118224

But if you are just interested in getting an ESAPI update to make your favorite SCA tool to stop squawking about it, then you can just exclude the version associated with ESAPI 2.5.1.0 and explicitly use the release 1.5 version. For Maven builds, you would use something like this in your pom.xml file:

<dependency>
    <groupId>org.owasp.esapi</groupId>
    <artifactId>esapi</artifactId>
    <version>2.5.1.0</version>
    <exclusions>
        <exclusion>
            <groupId>commons-fileupload</groupId>
            <artifactId>commons-fileupload</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<!-- Add commons-fileupload 1.5 (or later) as an explicit dependency to work around CVE-2023-24998. -->
<dependency>
    <groupId>commons-fileupload</groupId>
    <artifactId>commons-fileupload</artifactId>
    <version>1.5</version>
</dependency>

That should stop your SCA tool from complaining about it.

Fixing this correctly would require something like maybe restricting both the # of files and total file size from a particular remote IP address (which of course could be forged). If you want to do that, I suggest using some RASP technology to support it. Something perhaps like OWASP AppSensor (which can be plugged into ESAPI in place of ESAPI's standard built-in IntrusionDetector) or something like Contrast Security's RASP technology. There may be Web Application Firewalls (WAFs) that may work as well. That said, I will NOT be addressing that potential attack scenario in this next ESAPI release and possibly never. All that is explained in the URL that I provided above, so if you absolutely need this potential DoS attack vector fixed in ESAPI, then write it up as a GitHub issue and share your explicit threat model along with your set of assumptions. But it is a difficult problem to address based on the current ESAPI design because even if we limit the # of files per session, an attacker can always get a new session.

Anyhow, I hope this addresses your concerns. If not, please respond with specific follow-up questions.

-kevin

--

Blog: https://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall | OWASP ESAPI Project co-lead
NSA: All your crypto bit are belong to us.