Project

General

Profile

Bug #2679

mod_secdownload md5 comparison vulnerable to timing attacks

Added by ikki about 3 years ago. Updated about 3 years ago.

Status:
Fixed
Priority:
High
Assignee:
-
Category:
mod_secdownload
Target version:
Start date:
2015-10-25
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:

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:

Associated revisions

Revision 3048 (diff)
Added by stbuehler about 3 years ago

[mod_secdownload] use a hopefully constant time comparison to check hash (fixes #2679)

From: Stefan Bühler <>

Revision 39add447 (diff)
Added by stbuehler about 3 years ago

[mod_secdownload] use a hopefully constant time comparison to check hash (fixes #2679)

From: Stefan Bühler <>

git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@3048 152afb58-edef-0310-8abb-c4023f1b3aa9

History

#1

Updated by stbuehler about 3 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.

#2

Updated by stbuehler about 3 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset r3048.

Also available in: Atom