Fixed
Pinned fields
Click on the next to a field label to start pinning.
Details
Assignee
Brian ChanBrian ChanReporter
Minhchau DangMinhchau DangBranch Version/s
6.1.xBackported to Branch
CommittedAffects versions
Priority
Medium
Details
Details
Assignee
Brian Chan
Brian ChanReporter
Minhchau Dang
Minhchau DangBranch Version/s
6.1.x
Backported to Branch
Committed
Affects versions
Priority
Zendesk Support
Zendesk Support
Zendesk Support
Created April 9, 2012 at 5:17 PM
Updated June 24, 2023 at 3:53 PM
Resolved May 23, 2012 at 3:22 PM
Currently for search engine optimization (and possibly to be immune to those values changing), when there are four parts to the path in WebServerServlet the middle two sections are ignored and only the groupId and the uuid_ are used to return the image.
While this is not problematic in of itself, if a user uploads any file to the Documents and Media portlet and crafts 10,000 versions of the /image/groupId/gibberish/gibberish/uuid URL with different values of gibberish each time, they can fill up the CacheUtil cache (by default 10,000 elements) with items up to cache.content.threshold.size (default 512,000 bytes).
With default configuration settings for cache and max image size, a malicious user can fill up 5 GB of heap by requesting a 512,000 byte image 10,000 times with different values for the middle two components of the path each time. For most Liferay installations, this is sufficient to crash the server with an OutOfMemoryException for thirty minutes (the time it takes for the cache entries to expire).