-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upload delay resulting in DoS #33
Comments
jduo
added a commit
to jduo/gwtupload
that referenced
this issue
Jun 19, 2020
- When a user POSTS with the delay parameter, we no longer modify the servlet state and just use a local variable to hold this. So this no longer affects all subsequent requests. - Add a server setting maxDelay which defaults to 1 minute. - The user-specified delay is capped fro [0, maxDelay] now to avoid the DOS attack.
🛠️ A fix has been provided for this issue. Please reference: 418sec#1 🔥 This fix has been provided through the https://huntr.dev/ bug bounty platform. |
Fix merged, can be closed |
Closed
1 task
This was referenced Feb 14, 2023
mparfianowicz
added a commit
to atlassian-forks/gwtupload
that referenced
this issue
Jan 23, 2024
…lowUploads parameter - `CVE-2020-13128
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is a vulnerability which allows to perform DoS attack against the application
server. The problem lies in handling
delay
parameter when upload isinitiated (
gwtupload.server.UploadServlet#parsePostRequest
). Value fromthis parameter is used as an argument for
Thread.sleep
invocation.Malicious user can specify even max integer value 2147483647, which
would cause a thread to sleep for almost 25 days
(
gwtupload.server.AbstractUploadListener#update
). Additionally, thevalue from
delay
parameter is assigned the field which in case ofservlets behaves as a global variable. It means every further request
will use this value and also will be put to sleep. Putting a thread to
sleep excludes it from a limited set of available threads, so after a
suitable number of upload requests (Tomcat by default has limit of 200
threads) the whole application will become unresponsive and will not
accept any new requests.
https://github.com/manolo/gwtupload/blob/master/core/src/main/java/gwtupload/server/UploadServlet.java
https://github.com/manolo/gwtupload/blob/master/core/src/main/java/gwtupload/server/AbstractUploadListener.java
The same way the servlet accepts
maxFileSize
parameter, but its abuse will only prevent from uploading files; the server won't suffer.The text was updated successfully, but these errors were encountered: