[Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

Richard Moore rich at kde.org
Thu Jan 30 16:27:21 CET 2014


On 30 January 2014 14:22, Koehne Kai <Kai.Koehne at digia.com> wrote:
>
>
>> -----Original Message-----
>> From: development-bounces+kai.koehne=digia.com at qt-project.org
>> [...]
>> Again, only 3rd party untrusted content matters here and for that you need a
>> sandbox.
>
> I'm not entirely sure '3rd party untrusted content' in the Qt process is needed for these sort of attacks.
>
> That's how I understood it so far:
> 1. the attack vector is web proxy poisoning. That is , all it takes is an attacker that
> a) can access a remote under his control through the same proxy as the target (or gets some user behin the proxy to access the remote)
> b) knows how the websocket request will look like
> c) Manages to poison the proxy to cache a poisonous answer for the request
>
> The hashing stuff etc tries to prevent b), but strong entropy is required so that the attacker can't just 'guess' future requests e.g. from monitoring previous requests.
>
> Correct me if I'm wrong, but that scheme will work independent of whether the user / app itself runs untrusted content etc.
>

Yes it would... except that if the attacker can execute arbitrary code
then he doesn't have to use this API - he can just do the attack. The
masking comes in useful when the attacker is sandboxed so can only
perform the attack using the subset of facilities exposed to him - in
this case the websockets api.

Cheers

Rich.



More information about the Development mailing list