Skip to content
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

Denial of Service by Rendering Image that have very big pixel #357

Open
daffainfo opened this issue Sep 9, 2022 · 4 comments
Open

Denial of Service by Rendering Image that have very big pixel #357

daffainfo opened this issue Sep 9, 2022 · 4 comments

Comments

@daffainfo
Copy link

daffainfo commented Sep 9, 2022

Description

There is Denial of Service (DoS) because imageproxy didn't check the size of the pixel image

Affected version

Latest version (0.11.2)

CVSS Score

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - 6.5 MEDIUM

Steps to Reproduce

  1. Create an image with very large pixel or you can download the file in this link https://hackerone.com/reports/390
  2. Upload the image in your file, for example https://website.com/lottapixel.jpg
  3. Deploy the imageproxy
  4. Access the link like this http://vulnerable-imageproxy.com/9999999x999999,fit/https://website.com/lottapixel.jpg
  5. The website will down

Proof of Concept

image

Remediation

Check the pixel of the image first, if the image has a large pixel, drop the request.

Reference

@willnorris
Copy link
Owner

Yes, it's true that if you run an open proxy, an attacker could use it to load a malicious image. The proper protection for that is to use host allow lists and/or request signatures so that attackers can't proxy arbitrary URLs

@willnorris
Copy link
Owner

I got a report a few months ago about a similar issue, but I think it was more performance related. But in any event, there's certainly some optimization to be had by not immediately reading the fill remote image into memory here. We could pass an io.Reader to Transform, and probably read out the image dimensions before loading the full image, which would let us put some additional maximum dimension controls in place.

We can leave this open to track that work, but if anyone is actually concerned about the security aspects of this, they see the above comment about host allow lists and request signatures.

@a180285
Copy link

a180285 commented Jan 2, 2023

After local testing above jpg image using master branch. I got following output, no crash yet.

imageproxy listening on localhost:8080
2023/01/02 15:44:58 error transforming image http://127.0.0.1/lottapixel.jpg#200x200: invalid JPEG format: bad Huffman code
2023/01/02 15:45:17 error transforming image http://127.0.0.1/lottapixel.jpg#200x200: invalid JPEG format: bad Huffman code
2023/01/02 15:45:59 error transforming image http://127.0.0.1/lottapixel.jpg#9.999999e+06x999999,fit: invalid JPEG format: bad Huffman code

I have download the lottapixel.jpg (5 KB) from https://hackerone.com/reports/390

Maybe it's already fixed ?

@willnorris
Copy link
Owner

Maybe it's already fixed ?

It might have been fixed in the upstream image package? I haven't done anything specific in imageproxy for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants