From: Dirkjan Bussink <dbussink@github.com> To: Eric Wong <normalperson@yhbt.net> Cc: John Crepezzi <seejohnrun@github.com>, Kevin Sawicki <kevinsawicki@github.com>, unicorn-public@yhbt.net Subject: Re: Potential Unicorn vulnerability Date: Fri, 12 Mar 2021 13:24:36 +0100 [thread overview] Message-ID: <66A68DD8-83EF-4C7A-80E8-3F1F7AB31670@github.com> (raw) In-Reply-To: <20210312120007.GA24539@dcvr> [-- Attachment #1: Type: text/plain, Size: 1404 bytes --] Hi Eric, > On 12 Mar 2021, at 13:00, Eric Wong <normalperson@yhbt.net> wrote: > > I was going to say I didn't have a preference and the > current approach was fine... > > However, I just now realized now that clobbering+replacing all > of @request is required. > > That's because env['rack.input'] is (Stream|Tee)Input, > and that is lazily consumed and those objects keep state in > @request (as the historically-named @parser) > > If we're to make env safe to be shipped off to another thread, > then @request still needs to stick around to maintain state > of env['rack.input'] until it's all consumed. Ah yeah, that’s a good point. I don’t think this affects us right now so the existing patch still keeps us safe, but it would break this case then indeed. > It probably doesn't affect most apps out there that just decode > forms via HTTP POST; but the streamed rack.input is something > that's critical for projects that feed unicorn with PUTs via > "curl -T" Ah yeah. So do you think that on top of the current patch we’d need something like the attached patch (which moves the @request allocation), or would only the latter patch be needed then? In the latter case there’s still a bunch of logic for Rack hijack around then which might not be needed at that point, but I’m not entirely sure how that would look like. Cheers, Dirkjan [-- Attachment #2: 0001-Allocate-a-new-request-for-each-client.patch --] [-- Type: application/octet-stream, Size: 1579 bytes --] From 58c4c153ba6c007284771c0899798a14df28c7c3 Mon Sep 17 00:00:00 2001 From: Dirkjan Bussink <d.bussink@gmail.com> Date: Fri, 12 Mar 2021 13:22:25 +0100 Subject: [PATCH] Allocate a new request for each client This removes the reuse of the parser between requests. Reusing these is risky in the context of running any other threads within the unicorn process, also for threads that run background tasks. If any other thread accidentally grabs hold of the request it can modify things for the next request in flight. The downside here is that we allocate more for each request, but that is worth the trade off here and the security risk we otherwise would carry to leaking wrong and incorrect data. --- lib/unicorn/http_server.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/unicorn/http_server.rb b/lib/unicorn/http_server.rb index c0f14ba..22f067f 100644 --- a/lib/unicorn/http_server.rb +++ b/lib/unicorn/http_server.rb @@ -69,7 +69,6 @@ class Unicorn::HttpServer # incoming requests on the socket. def initialize(app, options = {}) @app = app - @request = Unicorn::HttpRequest.new @reexec_pid = 0 @default_middleware = true options = options.dup @@ -621,6 +620,7 @@ def e100_response_write(client, env) # once a client is accepted, it is processed in its entirety here # in 3 easy steps: read request, call app, write app response def process_client(client) + @request = Unicorn::HttpRequest.new env = @request.read(client) if early_hints -- 2.30.1
next prev parent reply other threads:[~2021-03-12 12:24 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <F6712BF3-A4DD-41EE-8252-B9799B35E618@github.com> [not found] ` <20210311030250.GA1266@dcvr> [not found] ` <7F6FD017-7802-4871-88A3-1E03D26D967C@github.com> 2021-03-12 9:41 ` Eric Wong 2021-03-12 11:14 ` Dirkjan Bussink 2021-03-12 12:00 ` Eric Wong 2021-03-12 12:24 ` Dirkjan Bussink [this message] 2021-03-13 2:26 ` Eric Wong 2021-03-13 2:31 ` [PATCH] http_request: drop unnecessary #clear call Eric Wong 2021-03-16 10:15 ` Potential Unicorn vulnerability Dirkjan Bussink 2021-03-16 10:31 ` Eric Wong 2021-03-17 8:03 ` Dirkjan Bussink 2021-03-17 8:47 ` Eric Wong 2021-03-19 13:55 ` Dirkjan Bussink
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://yhbt.net/unicorn/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=66A68DD8-83EF-4C7A-80E8-3F1F7AB31670@github.com \ --to=dbussink@github.com \ --cc=kevinsawicki@github.com \ --cc=normalperson@yhbt.net \ --cc=seejohnrun@github.com \ --cc=unicorn-public@yhbt.net \ --subject='Re: Potential Unicorn vulnerability' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: ../../unicorn.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).