* Re: Potential Unicorn vulnerability
@ 2021-03-12 12:24 14% ` Dirkjan Bussink
0 siblings, 0 replies; 1+ results
From: Dirkjan Bussink @ 2021-03-12 12:24 UTC (permalink / raw)
To: Eric Wong; +Cc: John Crepezzi, Kevin Sawicki, unicorn-public
[-- 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
^ permalink raw reply related [relevance 14%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[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 ` Potential Unicorn vulnerability Eric Wong
2021-03-12 11:14 ` Dirkjan Bussink
2021-03-12 12:00 ` Eric Wong
2021-03-12 12:24 14% ` Dirkjan Bussink
Code repositories for project(s) associated with this public inbox
https://yhbt.net/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).