Re: Design Issue: Overlong Frames

James M Snell <> Fri, 10 May 2013 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD05521F9347 for <>; Fri, 10 May 2013 14:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.546
X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O0qy-xSugdYZ for <>; Fri, 10 May 2013 14:38:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8CB4921F9343 for <>; Fri, 10 May 2013 14:38:09 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Uav0N-0002gL-7k for; Fri, 10 May 2013 21:37:31 +0000
Resent-Date: Fri, 10 May 2013 21:37:31 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uav0B-0002fX-Ol for; Fri, 10 May 2013 21:37:19 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Uav0B-0002fN-3C for; Fri, 10 May 2013 21:37:19 +0000
Received: by with SMTP id n12so5543098oag.17 for <>; Fri, 10 May 2013 14:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=DaNVM1YM9iLpha7J5HjqtCkiziDAZ4bDEcggXSM46+g=; b=Jm//TeSyiPBHR+qslb0qK/9IO5IP/ZqM/CVMoIE+dyNfQDkSxlq6es96P/bkR2Ddvd 3tzzOUCcjyMAK+/yG3/t7rPI/Qc27NGQdiJEkiP21t4zm3ERFMqTbWEfHcVrty6IjkF6 RvjSgNegOvedi1MNcgPzpeC1nPCx+8jHPdq3HvVDnjjlzITI7AePVm9BsJYCJBl3yk+7 uK6tEm/87vq72R8ZL6qmCeR9FCo4wTd6FkwecJIrNBoKJWjByjgkHZ8qek+5KqV6nAR4 MmKzMMQ+z9EYjR+YJv1I2fgu1DFQINqZHae6EfbxsxZ1pPYV59kbsAh4AxyJnwNhRKOG y6Pg==
X-Received: by with SMTP id sa5mr207419obc.96.1368221813095; Fri, 10 May 2013 14:36:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 10 May 2013 14:36:33 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: James M Snell <>
Date: Fri, 10 May 2013 14:36:33 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: "" <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.680, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Uav0B-0002fN-3C 0cc8123fb03ccd0317e87d2fa897edf9
Subject: Re: Design Issue: Overlong Frames
Archived-At: <>
X-Mailing-List: <> archive/latest/17940
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

FWIW, one possible attack vector this would help mitigate is "frame smuggling"..

For example, suppose an attacker is sending a request through a proxy
that is designed to filter out certain kinds of bad requests. The
attacker determines that while the proxy properly examines both the
size and type of a frame, it ignores extraneous bytes in known frame
types and simply passes those thru. The origin server, on the other
hand, only looks at the frame type and does not properly deal with
frame length. So, to get its bad message through the proxy that would
normally filter it out ...

1. The attacker first sends an apparently innocent initial HEADERS
frame to initialize a stream...
2. Then sends a manipulated RST_STREAM frame that includes the error
code and the complete smuggled frame as additional payload.
3. The proxy sees the RST_STREAM, checks the error code and just
passes that through, ignoring the smuggled frame as "extraneous"
4. The origin receives the RST_STREAM and parses out only the error
code bits without paying proper attention to the frame size (that is,
it stops reading the frame once it parses the error code, mistakenly
thinking that that's all there is)
5. The origin then moves on to receive the next frame which ends up
being the smuggled bad frame that the proxy allowed through.

The solution is simple: require endpoints to always process the full
reported frame size when processing frames, and for those frames that
we know absolutely shouldn't contain extra bytes, disallow them from
doing so.

On Fri, May 10, 2013 at 10:36 AM, Martin Thomson
<> wrote:
> On 9 May 2013 10:26, James M Snell <> wrote:
>> Recommendation: Adding a short statement that a PROTOCOL_ERROR MUST be
>> returned if a frame contains more bytes than what is expressly
>> specified in the frame definition.
> That would prevent extension unnecessarily.  And it doesn't do
> anything to improve security.
> When you want to harden security, you need to consider what equivalent
> options are available to an attacker.  If I wanted to send you more
> data, then I will use DATA frames.  Unless you can find a way to
> curtail DATA I see no reason to clamp down here.