Re: [hybi] Masking only Payload/Extension Data

[Adam Barth <[e-mail]>]

Thanks for having an open mind Joel.  Let's start with some basic assumptions:

1) Attacks only get better over time.  Over the (hopefully) many years
folks will be using this protocol, the attacks we know about today
will continue to exist, and security researchers will continue to
learn more techniques and improve their attacks.  That means we should
design protocols with a margin of safety rather than pushing up
against the razor edge of what we can reliably exploit today.
Admitted, this aspect of security is somewhat of an art, and at some
point we'll need to defer to the judgement of security experts as to
how much of a margin we need for safety.

2) If an attacker can choose a moderately long sequence of bytes of
the wire, we lose.  More specifically, we can construct attacks today
that abuse certain configurations of proxies using a moderate length
of chosen bytes.  Because of (1), we should expect the length of these
sequences and the amount of damage attacker can cause with them to
increase over time.  The story would be different if we had some solid
reasoning about lower bounds on length or upper bounds on damage, but
we don't.

For simplicity, let's consider the base framing protocol:

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#section-4.3

Let's assume we're only going to mask the extension data and the
application data.  That leds approximately 10 bytes at the beginning
of the frame that's unmasked.  Are these bytes under the control of
the attacker?  In large part, they are.  For example, the attacker is
relatively free to select the payload length.  The attacker is also
likely to have a large amount of control over the opcode (recall that
the attacker can drive the protocol state machine into relatively
arbitrary states).  As for the various reserved bits, we don't know
very much about how these bits will be used, but if they're likely to
be at least partially under the influence of the attacker.

Worse, consider the case where the attacker sends a sequence of very
short (e.g., zero or one byte) messages.  Now the attacker can control
(or can strongly influence) an appreciable fraction of the bytes on
the wire.  Additionally, the attacker gets feedback (i.e., by seeing
the bytes that arrive at the server) and can dynamically adjust
subsequent messages based on this feedback.

So, does the above add up to an attack I can demonstrate today?  No.
Is there reasonable evidence that attackers will be able to stich
together the above weaknesses to construct an attack in the future?
Yes.  Given what we know today, my view is that not masking the entire
frame is an unacceptable level of risk.

Adam


On Thu, Mar 10, 2011 at 3:05 AM, Joel Martin <[e-mail]> wrote:
> I've been following this discussion pretty closely and I'm willing to change
> my mind if Adam (or somebody else) can clearly lay out a threat model that
> isn't easily addressed by minor tweaking. I really am interested in what
> real threat may exist and not just being stubborn. Please enlighten me.
> As somebody else has proposed, the allowable range of values in the length
> field can always be reduced in the future by fragmenting to avoid _specific_
> known vulnerable intermediaries (in the implementations without even
> changing the protocol). I.e. if "GET\n" is a problem, then client
> implementations can just never send that value.
> I suspect most would agree that masking of everything is better than
> stalling the protocol any longer, but if Adam is the only objector and the
> browser folks are okay with masking only payload then perhaps we should move
> forward with it.
> Joel Martin (kanaka)
> On Thu, Mar 10, 2011 at 1:39 PM, Willy Tarreau <[e-mail]> wrote:
>>
>> On Thu, Mar 10, 2011 at 02:25:28AM -0800, Brian wrote:
>> > By my count, we have six voices in favor so far, including myself:
>> > Andy Green
>> > Ytaka Takeda
>> > Greg Wilkins
>> > Willy Tarreau
>> > Joel Martin
>> > Brian McKelvey
>> >
>> > One on record as not having a strong opinion one way or the other:
>> > Ian Fette
>> >
>> > And one opposed:
>> > Adam Barth
>> >
>> >
>> > Adam's curt and patronizing reply is once again unenlightening as to
>> > any viable reason why we need to mask the frame header as well as the
>> > payload, beyond just his gut feeling on the matter.  I'd like to
>> > re-assert that since the only field under a potential hacker's control
>> > is the length (and potentially rsv bits via undefined extensions in
>> > the future) that the practical possibility of the frame header being
>> > used for an attack that actually accomplishes anything is so remote
>> > it's utterly laughable.
>>
>> I'd like to add that it's important to remember that this controllable
>> length is not even at the beginning of the frame, and that there are
>> uncontrollable bytes before.
>>
>> Regards,
>> Willy
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>