Fixes (maybe amongst others) the following oCERT report ([oCERT-2014-008]):
LibVNCServer HandleRFBServerMessage rfbServerCutText malicious msg.sct.length
It looks like there may be a chance for potential memory corruption when a LibVNCServer client attempts to process a Server Cut Text message.
case rfbServerCutText:
{
char *buffer;
if (!ReadFromRFBServer(client, ((char *)&msg) + 1,
sz_rfbServerCutTextMsg - 1))
return FALSE;
msg.sct.length = rfbClientSwap32IfLE(msg.sct.length); << Retrieve malicious length
buffer = malloc(msg.sct.length+1); << Allocate buffer. Can return 0x0
if (!ReadFromRFBServer(client, buffer, msg.sct.length)) << Attempt to write to buffer
return FALSE;
buffer[msg.sct.length] = 0; << Attempt to write to buffer
if (client->GotXCutText)
client->GotXCutText(client, buffer, msg.sct.length); << Attempt to write to buffer
free(buffer);
break;
}
If a message is provided with an extremely large size it is possible to cause the malloc to fail, further leading to an attempt to write 0x0.
This is recommended practice as per
https://www.gnu.org/software/automake/manual/html_node/Local-Macros.html.
It fixes the problem that arose when one of the maintainers could not build LibVNCServer
after https://github.com/LibVNC/libvncserver/pull/38 was merged.
Symptoms included
checking whether make sets $(MAKE)... yes
./configure: line 2481: syntax error near unexpected token `rfb/rfbconfig.h'
./configure: line 2481: `AX_PREFIX_CONFIG_H(rfb/rfbconfig.h)'
until autoconf-archive was installed (which was a previously unmentioned
requirement for Pull Request #38) – this is not always an option, in particular
when the project needs to be built using a system-wide autoconf installation
that cannot be modified easily by the developer.
There was no reason to get rid of the convenient script. Most developers
who are not in love with autoconf fail to remember that autoreconf
invocation, therefore it is better to have something working in place.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was a possible buffer overflow in rfbFileTransferOffer message when
processing the FileTime.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`windows.h` is referring to `winsock.h` (unless the `WIN32_LEAN_AND_MEAN` is defined).
The structs used in this header are defined in `winsock2.h` or in `winsock.h`, but we are using Winsock2 of course!
So we have to include winsock2.h and refrain from including windows.h here
This topic branch provides compatibility for Windows, without the
MINGW32 dependency.
It is based on https://github.com/LibVNC/libvncserver/pull/22.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With Microsoft Visual C++, we cannot use pthreads (MinGW sports an
emulation library which is the reason we did not need Windows-specific
hacks earlier). Happily, it is very easy to provide Windows-specific
emulations for the pthread calls we use.
[JES: fixed commit message]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Microsoft Visual C++ does not allow pointer arithmetic on void pointers.
[JES: fixed commit message]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To support Microsoft Visual C++, we must not guard Windows-specific code
in MinGW-specific #ifdef guards.
Happily, even 64-bit MSVC defines the WIN32 constant, therefore we can use
that instead.
[JES: fixed commit message, reordered commit, split out unrelated changes]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>