Re: [Qemu-devel] possible denial of service via VNC
On So, 2014-06-29 at 14:16 +0200, Peter Lieven wrote:
Hi,
while debugging a VNC issue I found this:
case VNC_MSG_CLIENT_CUT_TEXT:
if (len == 1)
return 8;
if (len == 8) {
uint32_t dlen = read_u32(data, 4);
if (dlen 0)
return 8 + dlen;
}
client_cut_text(vs, read_u32(data, 4), data + 8);
break;
in protocol_client_msg().
Is this really a good idea? This allows for letting the vs-input buffer to
grow
up to 2^32 + 8 byte which will possibly result in an out of memory condition.
Applying a limit there looks reasonable to me. Patches welcome.
As this is text only a megabyte should be more than enough for all
practical purposes. Question is what to do when the limit is exceeded?
Disconnect? Read throw away?
cheers,
Gerd
Re: [Qemu-devel] possible denial of service via VNC
On 30.06.2014 09:33, Gerd Hoffmann wrote:
On So, 2014-06-29 at 14:16 +0200, Peter Lieven wrote:
Hi,
while debugging a VNC issue I found this:
case VNC_MSG_CLIENT_CUT_TEXT:
if (len == 1)
return 8;
if (len == 8) {
uint32_t dlen = read_u32(data, 4);
if (dlen 0)
return 8 + dlen;
}
client_cut_text(vs, read_u32(data, 4), data + 8);
break;
in protocol_client_msg().
Is this really a good idea? This allows for letting the vs-input buffer to grow
up to 2^32 + 8 byte which will possibly result in an out of memory condition.
Applying a limit there looks reasonable to me. Patches welcome.
As this is text only a megabyte should be more than enough for all
practical purposes. Question is what to do when the limit is exceeded?
Disconnect? Read throw away?
I would also think something in the order of megabytes should be fine.
I would vote for disconnect as soon as the limit specified is too big. Otherwise
we had to rewrite the whole receive logic which could introduce additional
bugs.
Peter
--
Mit freundlichen Grüßen
Peter Lieven
...
KAMP Netzwerkdienste GmbH
Vestische Str. 89-91 | 46117 Oberhausen
Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
p...@kamp.de | http://www.kamp.de
Geschäftsführer: Heiner Lante | Michael Lante
Amtsgericht Duisburg | HRB Nr. 12154
USt-Id-Nr.: DE 120607556
...
Re: [Qemu-devel] possible denial of service via VNC
Hi, I would vote for disconnect as soon as the limit specified is too big. Otherwise we had to rewrite the whole receive logic which could introduce additional bugs. Sounds sensible. cheers, Gerd
Re: [Qemu-devel] possible denial of service via VNC
On 30.06.2014 09:46, Gerd Hoffmann wrote: Hi, I would vote for disconnect as soon as the limit specified is too big. Otherwise we had to rewrite the whole receive logic which could introduce additional bugs. Sounds sensible. Especially since client_cut_text is currently a NOP. Peter
[Qemu-devel] possible denial of service via VNC
Hi,
while debugging a VNC issue I found this:
case VNC_MSG_CLIENT_CUT_TEXT:
if (len == 1)
return 8;
if (len == 8) {
uint32_t dlen = read_u32(data, 4);
if (dlen 0)
return 8 + dlen;
}
client_cut_text(vs, read_u32(data, 4), data + 8);
break;
in protocol_client_msg().
Is this really a good idea? This allows for letting the vs-input buffer to grow
up to 2^32 + 8 byte which will possibly result in an out of memory condition.
Peter
Re: [Qemu-devel] possible denial of service via VNC
On Sun, Jun 29, 2014 at 5:16 AM, Peter Lieven p...@kamp.de wrote:
Hi,
while debugging a VNC issue I found this:
case VNC_MSG_CLIENT_CUT_TEXT:
if (len == 1)
return 8;
if (len == 8) {
uint32_t dlen = read_u32(data, 4);
if (dlen 0)
return 8 + dlen;
}
client_cut_text(vs, read_u32(data, 4), data + 8);
break;
in protocol_client_msg().
Is this really a good idea? This allows for letting the vs-input buffer to
grow
up to 2^32 + 8 byte which will possibly result in an out of memory condition.
The spec allows cut operations of this size. What would a reasonable limit be?
Regards,
Anthony Liguori
PeterY
