Re: Design Issue: Overlong Frames

[James M Snell <[e-mail]>]

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
<[e-mail]> wrote:
> On 9 May 2013 10:26, James M Snell <[e-mail]> 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.