EHC ❯ Potential log file CRLF injection
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Not a Bug
-
ehcache
-
-
cdennis
-
Reporter: djorm
-
April 29, 2011
-
0
-
Watchers: 3
-
July 27, 2012
-
May 25, 2011
Description
Ehcache 1.5.0 contains multiple potential vectors for CRLF log file injection. For example, net/sf/ehcache/store/DiskStore.java on line 463:
String message = name + “Cache: Could not remove disk store entry for key “ + key
- ”. Error was “ + exception.getMessage();
In this case, the element key is written to the log without sanitization. The element key could easily be a user-provided value in an application. In other examples, the cache name and request URL, also potentially user-provided values, are written to the log without sanitization.
The problem is clearly visible in ehcache 1.5.0, the version I am interested in because it is used by Hibernate Core 3.6.2. I have not checked more recent versions yet for this issue.
The CRLF injection vulnerability is described in CWE-93:
http://cwe.mitre.org/data/definitions/93.html
An example of a similar issue, showing the potential impact, is here:
https://www.redhat.com/security/data/cve/CVE-2008-1926.html
A secondary issue is the potential for escape sequences in log files, see:
http://www.evilaliv3.org/advisories/nginx/0.7.64/
This issue has a low/moderate security impact, but it is worth fixing. My recommendation is to add a log sanitization routine, stripping CRLF characters and encoding escape sequences from all values before they are written to the log.
Comments
Fiona OShea 2011-05-03
Chris Dennis 2011-05-25
It seems to me that log message sanitization at the Ehcache layer would be the wrong place to do this. Users who are concerned about such things should be sanitizing their logs at the java.util.logging.Handler layer (or the equivalent in their chosen logging framework) rather than relying on us sanitizing the logging messages at source (which might actually cause more problems for users who are not concerned about this issue).
I would go so far as to say that sanitization at the initial logging call is actually dangerous. This means users are relying on a third party to enforce required aspects of their security policy. By doing the filtering at a single common point (in the Handler that outputs to the log file) the user can ensure that *all* log messages are correctly filtered and not just those that we manage to catch and filter at the source.
Is this still true with later versions of Ehcache?