Package: ssvnc
Version: 1.0.29-2+b1
Severity: important
Dear Maintainer,
we experience crashes of the vncviewer (which make it unusable for our
application).
Test scenario:
* Debian jessie installation
* Two X displays (:0, :1)
* Run viewer: DISPLAY=:1 ssvncviewer -viewonly -listen 0
* Connect server: x11vnc -connect localhost
ssvncviewer forks to serve the connection, but the forked process crashes:
AcceptTcpConnection6: ipv6 connection from: '::1'
(LISTEN) Reverse VNC connection from IP: ::1 2015/01/05 12:54:52
Hostname: localhost
ssvncviewer -listen: Listening on port 5500
ssvncviewer -listen: Cmdline errors are not reported until a connection comes
in.
2015/01/05 12:54:52 select() start ...
Proto: RFB 003.008
Connected to RFB server, using protocol version 3.8
SelectSecurityType:
sec-type[0] 1 (rfbSecTypeNone)
Security-Type: 1 (rfbSecTypeNone) Latency: 0.13 ms
No VNC authentication needed
VNC authentication succeeded (0) for rfbSecTypeNone (RFB 3.8)
Desktop name "xxx:0"
VNC server default format:
32 bits per pixel. Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel. Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
geometry: 1596x876+0+0 ycrop: 0
create_image()
try_create_image: shm image create fail: image == NULL
try_create_image: created *non-shm* image: 1600x900
try_create_image: image->bytes_per_line: 6400
*** stack smashing detected ***: /usr/bin/ssvncviewer terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7303f)[0x7ffff63b103f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7ffff6434147]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7ffff6434110]
/usr/bin/ssvncviewer[0x42eb98]
/usr/bin/ssvncviewer[0x41faee]
/usr/bin/ssvncviewer[0x4089fb]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7ffff635fb45]
/usr/bin/ssvncviewer[0x408e2f]
I debugged vncviewer and found the cause of the stack smashing in
source file vnc_unixsrc/vncviewer/sockets.c, function SameMaching.
According to http://man7.org/linux/man-pages/man2/getpeername.2.html,
getpeername can increase the value of the supplied addrlen. This new
value is then passed to getsockname which now assumes that myaddr is
larger than it is in reality.
Here is a fixed version of the buggy function:
Bool
SameMachine(int sock)
{
struct sockaddr_in peeraddr, myaddr;
int addrlen;
addrlen = sizeof(struct sockaddr_in);
getpeername(sock, (struct sockaddr *)&peeraddr, &addrlen);
addrlen = sizeof(struct sockaddr_in);
getsockname(sock, (struct sockaddr *)&myaddr, &addrlen);
return (peeraddr.sin_addr.s_addr == myaddr.sin_addr.s_addr);
}
Cheers
Stefan
-- System Information:
Debian Release: 8.0
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'stable-updates'), (500,
'proposed-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ssvnc depends on:
ii bind9-host [host] 1:9.9.5.dfsg-7
ii libc6 2.19-13
ii libice6 2:1.0.9-1+b1
ii libjpeg62-turbo 1:1.3.1-11
ii libsm6 2:1.2.2-1+b1
ii libssl1.0.0 1.0.1j-1
ii libx11-6 2:1.6.2-3
ii libxaw7 2:1.0.12-2+b1
ii libxext6 2:1.3.3-1
ii libxmu6 2:1.1.2-1
ii libxpm4 1:3.5.11-1+b1
ii libxt6 1:1.1.4-1+b1
ii openssh-client 1:6.7p1-3
ii openssl 1.0.1j-1
ii procps 2:3.3.9-8
ii psmisc 22.21-2
ii stunnel4 3:5.06-2
ii tk 8.6.0+8
ii xterm 312-1
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages ssvnc recommends:
ii default-jre [java5-runtime] 2:1.7-52
ii openjdk-7-jre [java5-runtime] 7u71-2.5.3-2
ssvnc suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
