From: Eric Wong <bofh@yhbt.net>
To: Sam Sanoop <sams@snyk.io>
Cc: unicorn-public@yhbt.net
Subject: Re: [RFC] http_response: ignore invalid header response characters
Date: Wed, 6 Jan 2021 17:53:38 +0000 [thread overview]
Message-ID: <20210106175338.GA10985@dcvr> (raw)
In-Reply-To: <20201126115902.GA8883@dcvr>
Sam Sanoop <sams@snyk.io> wrote:
> Hi Eric,
cf. https://yhbt.net/unicorn-public/20201126115902.GA8883@dcvr/
(private followup <CAEQPCYJJdriMQyDNXimCS_kBrc_=DxhxJ66YdJmCe7ZXr-Zbvg@mail.gmail.com>)
Hi Sam, I'm moving this to the public list. Please keep
unicorn-public@yhbt.net Cc-ed (no need to quote, archives are
public and mirrored to several places).
> I wanted to bring this up again. I spoke with the researcher
> (@ooooooo_q) who disclosed this issue to us. He released the full
> details including the HackerOne report pubclily which provided more
> clarity about this issue. That can be read here:
> https://hackerone.com/reports/904059#activity-8945588
Note: I can't read anything on hackerone due to the JavaScript
requirement. If somebody can copy the text here, that'd be
great.
> That report was initially disclosed to the Ruby on Rails maintainers.
> In certain conditions, he was also able to leverage Puma and Unicorn
> to exploit the issues mentioned on the report. The issues which
> related to Unicorn were:
>
> * Open Redirect to HTTP header injection - (including \r in the redirect URL)
> * A user interaction XSS - Which leverages
> \rjavascript:alert(location) as the redirect destination
Does this happen when unicorn is behind nginx?
unicorn was always designed to run behind nginx and falls over badly
without it (trivially DoS-ed via slowloris)
> Reading that advisory, I see this more of an issue now. He has
> leveraged Unicorn and Puma along with Rails to demonstrate some of the
> proof of concepts. Under the section Vulnerabilities and conditions of
> the report, he has specified different conditions and configurations
> which allow for this vector.
>
> I agree with Aaron Patterson's (Rails Staff) decision on that report,
> this should be fixed in Unicorn and Puma directly, and Puma has
> already fixed this and issued an advisory:
> https://github.com/puma/puma/security/advisories/GHSA-84j7-475p-hp8v.
>
> I believe there is enough of a risk to fix this issue. What do you think?
While we follow puma on some things (as in recent non-rack
features), I'm not sure if this affects unicorn the same way it
affects puma and other servers (that are supported without nginx).
Fwiw, I've been against client-side JavaScript for a decade, now.
Libre license or not; the complexity of JS gives us a never-ending
stream of vulnerabilities, wasted RAM, CPU cycles, and bandwidth
use from constant software updates needed to continue the game of
whack-a-mole.
rest of thread below (top-posting corrected):
> > On Sun, Jan 3, 2021 at 10:20 PM Eric Wong <bofh@yhbt.net> wrote:
> > >
> > > Sam Sanoop <sams@snyk.io> wrote:
> > > > Hey Eric,
> > > >
> > > > Happy New Year. I want to follow up on the [RFC] http_response: ignore
> > > > invalid header response character RFC for the CRLF injection we spoke
> > > > about previously. I wanted to know what would be the timeline for your
> > > > patch to get merged and what additional steps there are before that
> > > > can happen.
> > >
> > > Hi Sam, honestly I have no idea if it's even necessary...
> > > I've had no feedback since 2020-11-26:
> > > https://yhbt.net/unicorn-public/20201126115902.GA8883@dcvr/
> > >
> > > Meanwhile 5.8.0 was released 2020-12-24 with a feature somebody
> > > actually cared about.
> > >
> > > Again, unicorn falls over without nginx in front of it anyways,
> > > so maybe nginx already guards against this and extra code is
> > > unnecessary on my end.
>
> On Sun, Jan 3, 2021 at 11:03 PM Sam Sanoop <sams@snyk.io> wrote:
> >
> > Hey Eric,
> >
> > No problem, I understand. Since the injection here is happening within
> > the response, I am not convinced if this is exploitable as well. I
> > have let the reporter of this issue know what your stance is. I
> > mentioned if he can provide a better Proof of Concept where this is
> > exploitable in the context of a http request, and look into this a bit
> > further, we can open up discussion again, or else, this is not worth
> > fixing.
next prev parent reply other threads:[~2021-01-06 17:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-26 11:59 [RFC] http_response: ignore invalid header response characters Eric Wong
2021-01-06 17:53 ` Eric Wong [this message]
2021-01-13 23:20 ` Sam Sanoop
2021-01-14 4:37 ` Eric Wong
2021-01-28 17:29 ` Sam Sanoop
2021-01-28 22:39 ` Eric Wong
2021-02-17 21:46 ` Sam Sanoop
2021-02-26 11:15 ` Eric Wong
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=20210106175338.GA10985@dcvr \
--to=bofh@yhbt.net \
--cc=sams@snyk.io \
--cc=unicorn-public@yhbt.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).