summaryrefslogtreecommitdiffstats
path: root/ui/vnc-ws.c
Commit message (Collapse)AuthorAgeFilesLines
* Change qemu_set_fd_handler2(..., NULL, ...) to qemu_set_fd_handlerFam Zheng2015-06-121-3/+3
| | | | | | | | | | | | | | | Done with following Coccinelle semantic patch, plus manual cosmetic changes in net/*.c. @@ expression E1, E2, E3, E4; @@ - qemu_set_fd_handler2(E1, NULL, E2, E3, E4); + qemu_set_fd_handler(E1, E2, E3, E4); Signed-off-by: Fam Zheng <famz@redhat.com> Message-id: 1433400324-7358-8-git-send-email-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* ui/vnc : remove 'struct' of 'typedef struct'Chih-Min Chao2015-04-301-2/+2
| | | | | | Signed-off-by: Chih-Min Chao <cmchao@gmail.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* CVE-2015-1779: limit size of HTTP headers from websockets clientsDaniel P. Berrange2015-04-011-2/+8
| | | | | | | | | | | | | | | | | | | | 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 <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* CVE-2015-1779: incrementally decode websocket framesDaniel P. Berrange2015-04-011-34/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <berrange@redhat.com> [ 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 <kraxel@redhat.com>
* ui: ensure VNC websockets server checks the ACL if requestedDaniel P. Berrange2015-03-181-0/+10
| | | | | | | | | If the x509verify option is requested, the VNC websockets server was failing to validate that the websockets client provided an x509 certificate matching the ACL rules. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: remove separate gnutls_session for websockets serverDaniel P. Berrange2015-03-181-2/+2
| | | | | | | | | The previous change to the auth scheme handling guarantees we can never have nested TLS sessions in the VNC websockets server. Thus we can remove the separate gnutls_session instance. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: enforce TLS when using websockets serverDaniel P. Berrange2015-03-181-24/+7
| | | | | | | | | | | | | | | | | When TLS is required, the primary VNC server considers it to be mandatory. ie the server admin decides whether or not TLS is used, and the client has to comply with this decision. The websockets server, however, treated it as optional, allowing non-TLS clients to connect to a server which had setup TLS. Thus enabling websockets lowers the security of the VNC server leaving the admin no way to enforce use of TLS. This removes the code that allows non-TLS fallback in the websockets server, so that if TLS is requested for VNC it is now mandatory for both the primary VNC server and the websockets VNC server. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* ui: remove unused 'wiremode' variable in VncState structDaniel P. Berrange2015-03-181-1/+0
| | | | | Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* Fix crash when connecting to VNC through websocketJorge Acereda MaciƔ2015-03-101-2/+1
| | | | | | | | | Connecting to VNC through websocket crashes in vnc_flush() when trying to acquire a mutex that hasn't been initialized (vnc_init_state(vs) hasn't been called at this point). Signed-off-by: Jorge Acereda Macia <jacereda@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* aio / timers: Untangle include filesAlex Bligh2013-08-221-0/+1
| | | | | | | | | | include/qemu/timer.h has no need to include main-loop.h and doing so causes an issue for the next patch. Unfortunately various files assume including timers.h will pull in main-loop.h. Untangle this mess. Signed-off-by: Alex Bligh <alex@alex.org.uk> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* TLS support for VNC WebsocketsTim Hardeck2013-05-031-0/+63
| | | | | | | | | | | | | | | | | | | | | | | Added TLS support to the VNC QEMU Websockets implementation. VNC-TLS needs to be enabled for this feature to be used. The required certificates are specified as in case of VNC-TLS with the VNC parameter "x509=<path>". If the server certificate isn't signed by a rooth authority it needs to be manually imported in the browser because at least in case of Firefox and Chrome there is no user dialog, the connection just gets canceled. As a side note VEncrypt over Websocket doesn't work atm because TLS can't be stacked in the current implementation. (It also didn't work before) Nevertheless to my knowledge there is no HTML 5 VNC client which supports it and the Websocket connection can be encrypted with regular TLS now so it should be fine for most use cases. Signed-off-by: Tim Hardeck <thardeck@suse.de> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Message-id: 1366727581-5772-1-git-send-email-thardeck@suse.de Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* vnc: Clean up vncws_send_handshake_response()Markus Armbruster2013-01-301-5/+6
| | | | | | | | | Use appropriate types, drop superfluous casts, use sizeof, don't exploit that this particular call of gnutls_fingerprint() doesn't change its last argument. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* vnc: added initial websocket protocol supportTim Hardeck2013-01-211-0/+284
This patch adds basic Websocket Protocol version 13 - RFC 6455 - support to QEMU VNC. Binary encoding support on the client side is mandatory. Because of the GnuTLS requirement the Websockets implementation is optional (--enable-vnc-ws). To activate Websocket support the VNC option "websocket"is used, for example "-vnc :0,websocket". The listen port for Websocket connections is (5700 + display) so if QEMU VNC is started with :0 the Websocket port would be 5700. As an alternative the Websocket port could be manually specified by using ",websocket=<port>" instead. Parts of the implementation base on Anthony Liguori's QEMU Websocket patch from 2010 and on Joel Martin's LibVNC Websocket implementation. Signed-off-by: Tim Hardeck <thardeck@suse.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
OpenPOWER on IntegriCloud