Re: [Qemu-devel] [PULL for-2.3 0/2] vnc: fix websocket security issues (cve-2015-1779).

[Peter Maydell]

On 1 April 2015 at 15:11, Gerd Hoffmann <address@hidden> wrote:
>   Hi,
>
> $subject says all, here are the cve-2015-1779 fixes for vnc websockets
> from Daniel P. Berrange for 2.3-rc2.
>
> please pull,
>   Gerd
>
> The following changes since commit 054903a832b865eb5432d79b5c9d1e1ff31b58d7:
>
>   Update version for v2.3.0-rc1 release (2015-03-24 16:34:16 +0000)
>
> are available in the git repository at:
>
>   git://git.kraxel.org/qemu tags/pull-cve-2015-1779-20150401-1
>
> for you to fetch changes up to 9cf222fd4fd3f4d1f959685c061279d0673726cd:
>
>   CVE-2015-1779: limit size of HTTP headers from websockets clients 
> (2015-04-01 15:48:52 +0200)
>
> ----------------------------------------------------------------
> vnc: fix websocket security issues (cve-2015-1779).
>
> ----------------------------------------------------------------
> Daniel P. Berrange (2):
>       CVE-2015-1779: incrementally decode websocket frames
>       CVE-2015-1779: limit size of HTTP headers from websockets clients

Oops, this doesn't build on 32 bit:

/root/qemu/ui/vnc-ws.c: In function ‘vnc_client_read_ws’:
/root/qemu/ui/vnc-ws.c:133:45: error: passing argument 3 of
‘vncws_decode_frame_header’ from incompatible pointer type [-Werror]
In file included from /root/qemu/ui/vnc.h:112:0,
                 from /root/qemu/ui/vnc-ws.c:21:
/root/qemu/ui/vnc-ws.h:86:5: note: expected ‘size_t *’ but argument is
of type ‘uint64_t *’
/root/qemu/ui/vnc-ws.c:145:46: error: passing argument 2 of
‘vncws_decode_frame_payload’ from incompatible pointer type [-Werror]
In file included from /root/qemu/ui/vnc.h:112:0,
                 from /root/qemu/ui/vnc-ws.c:21:
/root/qemu/ui/vnc-ws.h:90:5: note: expected ‘size_t *’ but argument is
of type ‘uint64_t *’
cc1: all warnings being treated as errors

Making the payload_remain arguments to the two functions
be uint64_t rather than size_t seems to fix this.
The other approach is to change the VncState::ws_payload_remain
field from uint64_t to size_t. I haven't looked through the
ramifications of this enough to recommend one over the other.

Since we need to respin anyway, can you add the effects of
not having the fixes (ie "frequent spurious disconnects",
"fails to build on 32-bit systems") to the commit message
too?

thanks
-- PMM