From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 68FA61F4B4; Wed, 6 Jan 2021 17:53:38 +0000 (UTC) Date: Wed, 6 Jan 2021 17:53:38 +0000 From: Eric Wong To: Sam Sanoop Cc: unicorn-public@yhbt.net Subject: Re: [RFC] http_response: ignore invalid header response characters Message-ID: <20210106175338.GA10985@dcvr> References: <20201126115902.GA8883@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201126115902.GA8883@dcvr> List-Id: Sam Sanoop wrote: > Hi Eric, cf. https://yhbt.net/unicorn-public/20201126115902.GA8883@dcvr/ (private followup ) 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 wrote: > > > > > > Sam Sanoop 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 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.