Bug #2679
closedmod_secdownload md5 comparison vulnerable to timing attacks
Description
In mod_secure_download.c line 267, the following code is used for comparing the user-supplied MD5:
if (0 != strncasecmp(md5_str, p->md5->ptr, 32)) {
con->http_status = 403;
...
Since the strncasecmp(s1, s2, size) function performs a byte-by-byte comparison of the two input strings, it's subject to timing attacks. As soon as two bytes do not match, the function returns. Theoretically, this can be leveraged to determine a valid MD5 checksum. In term of exploitability, it's unlikely to exploit this bug over the Internet, but it may still be practical in a LAN environment (?). Previous research work have demonstrated that it's possible to isolate timing differences of ~100ns. Nevertheless, it's probably worth fixing.
A constant-time comparison must be used to prevent this attack. The following function is currently used by Redis to address a similar vulnerability: https://github.com/antirez/redis/blob/35a0c772b5ef407b700db051233144b6bac8fea3/src/server.c#L2520
Some good papers on timing attacks:- http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf
- http://rdist.root.org/2010/01/07/timing-independent-array-comparison/
- https://www.blackhat.com/docs/us-14/materials/us-14-Mayer-Time-Trial-Racing-Towards-Practical-Timing-Attacks.pdf
- https://www.blackhat.com/docs/us-15/materials/us-15-Morgan-Web-Timing-Attacks-Made-Practical.pdf
Updated by stbuehler about 9 years ago
- Target version set to 1.4.38
Given that we use md5 to generate the hash I'm not quite sure how secure the hash comparison has to be, but good catch anyway.
Updated by stbuehler about 9 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset r3048.
Also available in: Atom