diff options
author | Daniel Black <grooverdan@users.sourceforge.net> | 2013-06-30 15:03:13 +1000 |
---|---|---|
committer | Daniel Black <grooverdan@users.sourceforge.net> | 2013-06-30 15:03:13 +1000 |
commit | c2696fe641c92002b1535bb5ea76d47d442547a3 (patch) | |
tree | a1168630751d671bac3b7b3150d4b80f175f47ab /DEVELOP | |
parent | ee786671aa5824d908275398ccdcd17cc0ad099d (diff) | |
download | fail2ban-c2696fe641c92002b1535bb5ea76d47d442547a3.tar.gz |
DOC: enhance development doc to show how CVE-2013-2178 was done
Diffstat (limited to 'DEVELOP')
-rw-r--r-- | DEVELOP | 45 |
1 files changed, 37 insertions, 8 deletions
@@ -56,13 +56,21 @@ Filter Security Poor filter regular expressions are suseptable to DoS attacks. When a remote user has the ability to introduce text that will match the -filter regex such that the inserted text matches the <HOST> part they have the +filter regex, such that the inserted text matches the <HOST> part, they have the ability to deny any host they choose. -So the <HOST> part must be anchored on text generated by the application and not -the user. Ideally this should anchor to the beginning and end of the log line -however as more applications log at the beginning than the end, achoring the -beginning is more important. +So the <HOST> part must be anchored on text generated by the application, and not +the user, to a sufficient extent that the user cannot insert the entire text. + +Filters are matched against the log line with their date removed. + +Ideally filter regex should anchor to the beginning and end of the log line +however as more applications log at the beginning than the end, achoring the +beginning is more important. If the log file used by the application is shared +with other applications, like system logs, ensure the other application that +use that log file do not log user generated text at the beginning of the line, +or, if they do, ensure the regexs of the filter are sufficient to mitigate the +risk of insertion. When creating a regex that extends back to the begining remember the date part has been removed within fail2ban so theres no need to match that. If the format @@ -99,7 +107,7 @@ The fix here is that the command can be anything so .* is approprate. Here the .* will match until the end of the string. Then realise it has more to match, i.e. "from <HOST>" and go back until it find this. Then it will ban -1.2.3.4 correctly. Since the <HOST> is always at the end, end the regex witha $ +1.2.3.4 correctly. Since the <HOST> is always at the end, end the regex with a $. ^Invalid command .* from <HOST>$ @@ -110,7 +118,28 @@ Note if we'd just had the expression: Then provided the user put a space in their command they would have never been banned. -2. Applicaiton generates two identical log messages with different meanings +2. Filter regex can match other user injected data + +From the apache vulnerability CVE-2013-2178 +( original ref: https://vndh.net/note:fail2ban-089-denial-service ). + +An example bad regex for apache: + + failregex = [[]client <HOST>[]] user .* not found + +Since the user can do a get request on: + + GET /[client%20192.168.0.1]%20user%20root%20not%20found HTTP/1.0 +Host: remote.site + +Now the log line will be: + + [Sat Jun 01 02:17:42 2013] [error] [client 192.168.33.1] File does not exist: /srv/http/site/[client 192.168.0.1] user root not found + +As this log line doesn't match other expressions hence it matches the above +regex and blocks 192.168.33.1 as a denial of service from the HTTP requester. + +3. Applicaiton generates two identical log messages with different meanings If the application generates the following two messages under different circmstances: @@ -119,7 +148,7 @@ circmstances: client <USER>: authentication failed -Then its obvious that a regex of "^client <HOST>: authentication +Then it's obvious that a regex of "^client <HOST>: authentication failed$" will still cause problems if the user can trigger the second log message with a <USER> of 123.1.1.1. |