-
-
Notifications
You must be signed in to change notification settings - Fork 673
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
Consideration of Pixel Flood Attack Vulnerability in File Upload Functionality #1740
Comments
Good one, I think there are other ways to achieve it also, like pbm images. Now the good question is, should we have separate requirement for images to "check the dimensions to be in expected range" or use some other requirement to cover it. We have close requirement for this.
As separate requirement it should belong to 12.1, as there are some archive content validation requirements, so validating something image specific fits there as well.
|
I agree this should be in a general file checking requirement. @ImanSharaf can you suggest where to add it? |
Verify that when the application is accepting a file, it checks that the file extension of the file matches an expected file extension and that it validates that the contents of the file match the type represented by that extension, including but not limited to checking the initial "magic bytes". To point out more clearly: ... including but not limited to checking the initial "magic bytes". So, if I find this vulnerability, requirement 12.2.1 is something to use for reporting. The question is - should be put some special hilight on the attack vector in the 12.2.1 or in some new separate requirement. |
So I don't think 12.2.1 applies in this case because @ImanSharaf is talking about a situation where the filetype is as expected but it effectively contains a denial of service payload. As such, @ImanSharaf it would be good to get your perspective on the specific requirement to be added and where? |
If it will be separate requirement, we can look current 12.1.2 as a direction.
One more question to answer - should we watch as malicious content in general and handle them like viruses, or should we have requirement only to protect an application - if you going to create thumbnails and load image to the memory based on dimensions described by user, then validate the maximum allowed dimensions. |
I think there is a theoretical risk in trying to cover all the possible bad things that can happen in an uploaded file, it may be there is no limit to the possibilities. On the otherhand, in the same way as we specifically talk about zipped files, images are also highly common with some common risks. As such, I think we should have a separate requirement, similar to 12.1.2 about this issue.
We already have 12.4.2 to cover this:
|
Yes I know we have separate requirement for viruses, my question was - should we watch the pixel flooded image as virus as well? It's clearly malicious content. And the zip bomb (12.1.2)? And symlinked zip (12.1.4)? It makes sense to put them to one subcategory? |
Same category, maybe. Some requirement, no |
Clarification:
|
I would suggest:
Maybe CWE 400? L1
Opened #1769 |
What means "enforces" in this context? |
enforces = uses input validation on images with a pixel size larger than the maximum allowed to either reject them or reduce the pixel size down to the maximum |
but pixel flood attack is addressing exactly this functionality, no? Maybe we should watch this potential pixel flood image as zip bomb or virus content - clearly malicious, do not proceed? |
An antivirus doesn't detect that as a malicious file! |
I am good with this. |
I wrote: Maybe we should watch ... |
Following discussion with @elarlang,
|
@ImanSharaf are you ok with that as well |
So, I took:
and created PR: #1803 If @ImanSharaf has some improvement ideas, we can reopen the issue. Category and section may be changed in the future - #1769 |
I would like to bring to attention a potential vulnerability related to file upload functionality, specifically concerning the handling of image files. A simple yet impactful attack vector, known as the Pixel Flood Attack, can be executed whenever there is a file upload functionality that accepts images. In a Pixel Flood Attack, an attacker attempts to upload an image file with an exceedingly large pixel size, which could result in significant server resource consumption. This, in turn, may lead the application to crash, creating a scenario akin to an application-level denial of service (DoS).
Modern applications frequently leverage third-party libraries to process large images and convert them into smaller, more manageable sizes, thus conserving storage and processing power. However, some of these libraries might be susceptible to the Pixel Flood Attack, potentially leading to resource exhaustion or an Application-Level DoS attack.
This vulnerability could be of particular concern in scenarios where applications have not implemented adequate checks on the dimensions of the uploaded image files. Given the rise in the utilization of third-party image processing libraries, it's imperative to ensure that they are resilient against such attack vectors.
The text was updated successfully, but these errors were encountered: