-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
image/jpeg: excessive memory usage #10532
Comments
The image bounds are large. The fragment "ffc2000b08ff80fe95" means a Start-Of-Frame marker "ffc2" whose height and width are 0xff80 and 0xfe95. In other words, the image claims to be 65173 x 65408, or over 4 billion pixels. See also issue #5050. Closing as WAI. |
I am very sad that this issue is not taken seriously and closed as WAI. It is a real security threat and can easily be used for DoS attacks. For example, https://hackerone.com/reports/390 I understand that the API cannot distinguish between a legitimate or malicious image in this case. There should be an option to pass the max image dimensions or max memory size to prevent DoS attacks. As it stands now, we have no way of protecting our servers against malicious images. |
@roustem, yes you do: https://golang.org/pkg/image/jpeg/#DecodeConfig Read the header to calculate its dimensions first. Use a https://golang.org/pkg/io/#TeeReader to save the bytes read into a https://golang.org/pkg/bytes/#Buffer and then if you're happy with the dimensions, use https://golang.org/pkg/io/#MultiReader to stitch together the saved header buffer with the remaining jpeg io.Reader. It all takes a few lines and is the natural Go composable way. See Camlistore's codebase for an example. |
(Of course, that's only necessary if you can't rewind the stream. If it's just a file or something, you can seek back to the beginning) |
That will work. Thank you, @bradfitz ! |
The following program consumes 1.3GB of memory to produce:
decode failed: invalid JPEG format: bad Huffman code
Not sure whether it is OK or not, since the format is compressed probably the image bounds are large. But still it is suspicious for the tiny input file.
go version devel +87054c4 Wed Apr 22 02:50:48 2015 +0000 linux/amd64
The text was updated successfully, but these errors were encountered: