qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] a2bebf: CVE-2015-1779: incrementally decode w


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] a2bebf: CVE-2015-1779: incrementally decode websocket fram...
Date: Wed, 01 Apr 2015 10:30:07 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: a2bebfd6e09d285aa793cae3fb0fc3a39a9fee6e
      
https://github.com/qemu/qemu/commit/a2bebfd6e09d285aa793cae3fb0fc3a39a9fee6e
  Author: Daniel P. Berrange <address@hidden>
  Date:   2015-04-01 (Wed, 01 Apr 2015)

  Changed paths:
    M ui/vnc-ws.c
    M ui/vnc-ws.h
    M ui/vnc.h

  Log Message:
  -----------
  CVE-2015-1779: incrementally decode websocket frames

The logic for decoding websocket frames wants to fully
decode the frame header and payload, before allowing the
VNC server to see any of the payload data. There is no
size limit on websocket payloads, so this allows a
malicious network client to consume 2^64 bytes in memory
in QEMU. It can trigger this denial of service before
the VNC server even performs any authentication.

The fix is to decode the header, and then incrementally
decode the payload data as it is needed. With this fix
the websocket decoder will allow at most 4k of data to
be buffered before decoding and processing payload.

Signed-off-by: Daniel P. Berrange <address@hidden>

[ kraxel: fix frequent spurious disconnects, suggested by Peter Maydell ]

  @@ -361,7 +361,7 @@ int vncws_decode_frame_payload(Buffer *input,
  -        *payload_size = input->offset;
  +        *payload_size = *payload_remain;

[ kraxel: fix 32bit build ]

  @@ -306,7 +306,7 @@ struct VncState
  -    uint64_t ws_payload_remain;
  +    size_t ws_payload_remain;

Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: 2cdb5e142fb93e875fa53c52864ef5eb8d5d8b41
      
https://github.com/qemu/qemu/commit/2cdb5e142fb93e875fa53c52864ef5eb8d5d8b41
  Author: Daniel P. Berrange <address@hidden>
  Date:   2015-04-01 (Wed, 01 Apr 2015)

  Changed paths:
    M ui/vnc-ws.c

  Log Message:
  -----------
  CVE-2015-1779: limit size of HTTP headers from websockets clients

The VNC server websockets decoder will read and buffer data from
websockets clients until it sees the end of the HTTP headers,
as indicated by \r\n\r\n. In theory this allows a malicious to
trick QEMU into consuming an arbitrary amount of RAM. In practice,
because QEMU runs g_strstr_len() across the buffered header data,
it will spend increasingly long burning CPU time searching for
the substring match and less & less time reading data. So while
this does cause arbitrary memory growth, the bigger problem is
that QEMU will be burning 100% of available CPU time.

A novnc websockets client typically sends headers of around
512 bytes in length. As such it is reasonable to place a 4096
byte limit on the amount of data buffered while searching for
the end of HTTP headers.

Signed-off-by: Daniel P. Berrange <address@hidden>
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: fde069f751a9aa7e597c9d297a9995eca418a403
      
https://github.com/qemu/qemu/commit/fde069f751a9aa7e597c9d297a9995eca418a403
  Author: Peter Maydell <address@hidden>
  Date:   2015-04-01 (Wed, 01 Apr 2015)

  Changed paths:
    M ui/vnc-ws.c
    M ui/vnc-ws.h
    M ui/vnc.h

  Log Message:
  -----------
  Merge remote-tracking branch 
'remotes/kraxel/tags/pull-cve-2015-1779-20150401-2' into staging

vnc: fix websocket security issues (cve-2015-1779).

# gpg: Signature made Wed Apr  1 16:14:34 2015 BST using RSA key ID D3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <address@hidden>"
# gpg:                 aka "Gerd Hoffmann <address@hidden>"
# gpg:                 aka "Gerd Hoffmann (private) <address@hidden>"

* remotes/kraxel/tags/pull-cve-2015-1779-20150401-2:
  CVE-2015-1779: limit size of HTTP headers from websockets clients
  CVE-2015-1779: incrementally decode websocket frames

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/b8a86c4ac4d0...fde069f751a9

reply via email to

[Prev in Thread] Current Thread [Next in Thread]