unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
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


  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).