Potential memory leak and security vulnerability through CacheFilter and WebServerServlet

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 6.1.0 CE GA1, 6.1.10 EE GA1, 6.2.0 CE M2
• Fix Version/s: 6.1.1 CE GA2, 6.1.20 EE GA2, --Sprint 11/12, 6.2.0 CE M2
• Component/s: Core Infrastructure, Performance > Caching Infrastructure, Security
• Labels: None
• Branch Version/s:
  6.1.x
• Backported to Branch:
  Committed
• Similar Issues: Show 4 results ; ;

  LPS-23361	IE8 Potential Memory Leak
  LPS-1393	Potential memory leak in PortletSessionTracker
  LPS-49397	Memory leak in PortletSessionTracker in WebLogic
  LPS-10171	Potential memory leak in PortletSessionTracker

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).

[Michael Saechang]

Committed on:
Portal 6.1.x GIT ID: edc130a6ca419ec6aefb7a6fff6e34ff2864a987.
Portal 6.2.x GIT ID: fc10d81c69b3f564d67f43112b4fd7959fc6c25c.