Bug#606808: echoping crashes sometimes when used against HTTPS host
Package: echoping
Version: 6.0.2-3
Severity: grave
Tags: security patch
Justification: user security hole
I use Smokeping to monitor a number of external hosts. echoping is
called by EchoPingHttps Smokeping probe, and it crashes several times a
week, resulting in syslog error like:
Dec 11 00:13:27 bor kernel: [49668.766339] echoping[17510]: segfault at
767c858e ip 0804db39 sp bfea8710 error 4 in echoping[8048000+9000]
Hopefully, I found the source of this crash. I'm now running the patched
echoping binary to verify the fix, which is provided below. (Strictly
speaking, only the last change is required, but the former two improve
safety without causing any harm.)
--- echoping-6.0.2.orig/readline.c
+++ echoping-6.0.2/readline.c
@@ -139,7 +139,8 @@
if (ln) {
/* Empty buffer */
if (buf_end == 0) {
- rc = gnutls_record_recv(session, TLS_buffer, maxlen);
+ rc = gnutls_record_recv(session, TLS_buffer,
+ maxlen > MAXTOREAD ? MAXTOREAD
: maxlen);
if (rc == -1)
return rc;
buf_end = rc;
@@ -148,13 +149,14 @@
/* No more data in the buffer */
else if (buf_ptr == buf_end) {
buf_ptr = 0;
- rc = gnutls_record_recv(session, TLS_buffer, maxlen);
+ rc = gnutls_record_recv(session, TLS_buffer,
+ maxlen > MAXTOREAD ? MAXTOREAD
: maxlen);
if (rc == -1)
return rc;
buf_end = rc;
} else if (TLS_buffer[buf_end] != '\n') {
rc = gnutls_record_recv(session, TLS_buffer + buf_end,
- maxlen);
+ maxlen > MAXTOREAD - buf_end ?
MAXTOREAD - buf_end : maxlen);
if (rc == -1)
return rc;
buf_end = buf_end + rc;
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages echoping depends on:
ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib
ii libgnutls26 2.8.6-1the GNU TLS library - runtime libr
ii libidn11 1.15-2 GNU Libidn library, implementation
ii libldap-2.4-2 2.4.23-7 OpenLDAP libraries
ii libpopt0 1.16-1 lib for parsing cmdline parameters
echoping recommends no packages.
echoping suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606808: Acknowledgement (echoping crashes sometimes when used against HTTPS host)
Well, crashed again at the same place, ("if (TLS_buffer[i] == '\n')"
line). So, better patch is attached.
--
...Bye..Dmitry.
--- echoping-6.0.2.orig/readline.c
+++ echoping-6.0.2/readline.c
@@ -139,7 +139,8 @@
if (ln) {
/* Empty buffer */
if (buf_end == 0) {
- rc = gnutls_record_recv(session, TLS_buffer, maxlen);
+ rc = gnutls_record_recv(session, TLS_buffer,
+ maxlen > MAXTOREAD ? MAXTOREAD : maxlen);
if (rc == -1)
return rc;
buf_end = rc;
@@ -148,23 +149,24 @@
/* No more data in the buffer */
else if (buf_ptr == buf_end) {
buf_ptr = 0;
- rc = gnutls_record_recv(session, TLS_buffer, maxlen);
+ rc = gnutls_record_recv(session, TLS_buffer,
+ maxlen > MAXTOREAD ? MAXTOREAD : maxlen);
if (rc == -1)
return rc;
buf_end = rc;
} else if (TLS_buffer[buf_end] != '\n') {
rc = gnutls_record_recv(session, TLS_buffer + buf_end,
- maxlen);
+ maxlen > MAXTOREAD - buf_end ? MAXTOREAD - buf_end : maxlen);
if (rc == -1)
return rc;
buf_end = buf_end + rc;
}
for (oi = buf_ptr, i = buf_ptr;
-i <= buf_end && TLS_buffer[i] != '\n'; i++) {
+i < buf_end && TLS_buffer[i] != '\n'; i++) {
*ptr++ = TLS_buffer[i];
buf_ptr++;
}
- if (TLS_buffer[i] == '\n')
+ if (i < buf_end && TLS_buffer[i] == '\n')
buf_ptr++;
*ptr = '\0';
/* printf ("DEBUG: TLS_readline returns %d (%s)\n", i - oi,
Bug#606808: Security analysis
> I wonder why it was reported as a security risk. My concern is the third gnutls_record_recv() call. 'maxlen' argument of TLS_readline() was passed to the call as is, and TLS_readline() callers *always pass the full size* of TLS_buffer[] as 'maxlen', but pointer passed to the gnutls_record_recv() is (TLS_buffer + some offset). So, in theory, remote side could send specifically prepared data which could overwrite up to MAXTOREAD bytes past the buffer. As I'm not a security expert, I can't say for sure if it is really exploitable or not, but it does not look good at all. -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606808: echoping crashes sometimes when used against HTTPS host
> I've just committed your patch to echoping and it seems to work I also confirm that the patch fixed the crashes for me. I should note that the problem HTTPS server is rather unstable (15.25% failed requests over 10 days). Most likely the crash never happens with properly working servers. -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549515: Fails to start with 'cannot open /usr/share/games/jigzo/font/charmap.png' error
Package: jigzo Version: 0.6.1-3.1 Severity: grave Justification: renders package unusable The Subject says it all. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages jigzo depends on: ii libc62.9-25 GNU C Library: Shared libraries ii libgcc1 1:4.4.1-4 GCC support library ii libgl1-mesa-glx [libgl1] 7.5.1-1 A free implementation of the OpenG ii libjpeg626b-15 The Independent JPEG Group's JPEG ii libpng12-0 1.2.39-1PNG library - runtime ii libsdl-mixer1.2 1.2.8-6+b1 mixer library for Simple DirectMed ii libsdl1.2debian 1.2.13-4+b1 Simple DirectMedia Layer ii libstdc++6 4.4.1-4 The GNU Standard C++ Library v3 jigzo recommends no packages. jigzo suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578319: tinyproxy: Daily crashes caused by "reload" invocation in logrotate config
Package: tinyproxy
Version: 1.8.1-3
Severity: grave
Tags: patch
Justification: renders package unusable
--- tinyproxy-1.8.1/src/log.c 2010-02-19 18:38:00.0 +0300
+++ log.c 2010-04-19 00:56:36.0 +0400
@@ -211,6 +211,9 @@ void send_stored_logs (void)
size_t i;
+if (log_message_storage == NULL)
+return;
+
log_message(LOG_DEBUG, "sending stored logs");
for (i = 0; (ssize_t) i != vector_length (log_message_storage); ++i) {
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages tinyproxy depends on:
ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib
ii logrotate 3.7.8-5Log rotation utility
tinyproxy recommends no packages.
tinyproxy suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745137: linux-image-3.2.0-4-amd64: Crash when trying to enable RTL8188CE-based WiFi interface on Lenovo ThinkPad W520
Hello Ben, Thank you for uploading the fixed version. The following is mostly for you information. (I.e. I do not expect you to do any additional investigation. Neither am I going to spend more time on this.) On 20 April 2014 22:34, Dmitry Semyonov wrote: > On 20 April 2014 18:05, Ben Hutchings wrote: >> On Sun, 2014-04-20 at 11:41 +0400, Dmitry Semyonov wrote: > >>> Thanks! It fixes the crash but wlan0 has to be brought down, and up >>> again to make it work after initial bring up attempt: >> [...] >> >> I assume this is a regression, i.e. this problem did not exist in >> 3.2.54-2? > > This is correct. The interesting thing is that I do not see the regression in 3.2.57-3, although it uses the same rtl8192ce patch as I was testing with. So, I wonder if I missed some important step, or 3.2.57-3 contains a bit more changes than just the patch? (Note that I also removed 3.10 kernel-related packages from the system before installing 3.2.57-3, but this hardly could cause such change in behavior.) > I have double-checked 3.2.54-2: > > $ sudo ifup wlan0=h > > [ 93.537605] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin > [ 93.881450] ADDRCONF(NETDEV_UP): wlan0: link is not ready > [ 94.750415] wlan0: direct probe to b8:a3:86:aa:93:66 (try 1/3) > [ 94.752161] wlan0: direct probe responded And there are no "direct probe" messages in 3.2.57-3 log that were failing in 3.2.57-2 + rtl8192ce patch. P.S. Found one case with "direct probe" failures magically solved on a different hardware after rebooting to Windows - https://bbs.archlinux.org/viewtopic.php?pid=1044780#p1044780. -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#390335: xine-ui: xine works for me on non-KDE setup
Package: xine-ui Followup-For: Bug #390335 I installed Etch via netinst iso, and then added necessary packages via aptitude. Never installed KDE. xine and oxine start without problems. (I removed .xine aforehand. I don't have .kde in my home dir.) ~$ xine This is xine (X11 gui) - a free video player v0.99.5cvs. (c) 2000-2004 The xine Team. ~$ -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xine-ui depends on: ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libcomerr2 1.39-1 common error description library ii libcurl3-gnutls 7.15.5-1 Multi-protocol file transfer libra ii libfontconfig1 2.4.1-2 generic font configuration library ii libgnutls13 1.4.4-1 the GNU TLS library - runtime libr ii libice6 1:1.0.1-2X11 Inter-Client Exchange library ii libidn110.6.5-1 GNU libidn library, implementation ii libkrb531.4.4-1 MIT Kerberos runtime libraries ii libncurses5 5.5-3Shared libraries for terminal hand ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libreadline55.1-7GNU readline and history libraries ii libslang2 2.0.6-3 The S-Lang programming library - r ii libsm6 1:1.0.1-2X11 Session Management library ii libx11-62:1.0.0-9X11 client-side library ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxft2 2.1.8.2-8FreeType-based font drawing librar ii libxine11.1.2-3 the xine video/media player librar ii libxinerama11:1.0.1-4.1 X11 Xinerama extension library ii libxtst61:1.0.1-5X11 Testing -- Resource extension ii libxv1 1:1.0.1-5X11 Video extension library ii libxxf86vm1 1:1.0.0-4X11 XFree86 video mode extension l ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages xine-ui recommends: ii libaa11.4p5-30 ascii art library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381379: The bug is not applicable to Debian version of libmikmod
There is no GT2 support in current (testing) libmikmod2-3.1.11-a-6 Debian package. -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363513: DoS could be caused by ntpdate installation
Package: ntpdate Version: 1:4.2.0a+stable-2sarge1 Severity: critical Justification: breaks unrelated software ntpdate automatically and _unconditionally_ synchronizes time during the installation of the package. This obviously might break some software which hardly depends on timing. In particular, a proprietary fax server simply crashed after the time stepping. Besides that I could imagine SIP registrar software to process currently registered users incorrectly in case of crudely changed time. At least a user should be asked whether to synchronize time during the installation or not. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=KOI8-R) (ignored: LC_ALL set to ru_RU.KOI8-R) Versions of packages ntpdate depends on: ii libc6 2.3.6-7GNU C Library: Shared libraries ntpdate recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394214: fixed in eciadsl 0.11-3.1
eciadsl_0.11-3.1 is unusable on my PC, while eciadsl_0.11-3 works more or less fine. PPP connection can't be established by some reason in 0.11-3.1 version. It always times out. Also note that 0.11-* version does not work with 2.6.18.* kernels. Upstream developers are aware of the issue. So, I would just revert your patch, reopen the bug, and wait for updated upstream because it looks like eciadsl package is not ready for Etch (with 2.6.18 kernel) anyway. -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394214: fixed in eciadsl 0.11-3.1
On 1/14/07, Brice Goglin <[EMAIL PROTECTED]> wrote: Dmitry Semyonov wrote: >> On 1/14/07, Brice Goglin <[EMAIL PROTECTED]> wrote: >> > Brice Goglin wrote: >> > > >> > > Since you have the hardware to test, could add a printf where I set >> > > page_size and where I use it, so that we know whether page_size is >> > > initialized with the right value at the right time? >> > > >> > FYI, I built a package with such debug printf, it is available at >> > http://loulous.org/tmp/eciadsl/ > > Where was it supposed to print the info? I found no relevant messages > either on console or in various system logs... It is in the output of ./usr/sbin/eciadsl-firmware. It looks like it is run by /lib/udev/eciadsl. Maybe you can modify this file and redirect the output in /tmp/foo ? eciadsl-firmware is normally called only once, (or may be at every boot?). After that eciadsl-synch is the only utility which is used to restore failed connection. It looks to me that page_size is not initialized inside eciadsl-synch. When I hard code static unsigned long page_size = (1UL << 12); the software starts working again. Obviously, we need to find better place for initialising the variable via sysconf. -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394214: fixed in eciadsl 0.11-3.1
On 1/16/07, Brice Goglin <[EMAIL PROTECTED]> wrote: If it is confirmed that eciadsl does not work with 2.6.18 and there is no easy way to make it work (does upstream have a patch?), I don't think I will prepare a new NMU right now unless somebody wants me to do so. It is confirmed, and upstream doesn't have a patch so far: http://eciadsl.sourceforge.net/scripts/forum/viewtopic.php?t=3247 -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420668: mirrors: Main Russian mirror (http://ftp.ru.debian.org) is incomplete
Package: mirrors Severity: grave Justification: renders package unusable I contacted [EMAIL PROTECTED] about this issue, and received a reply on Apr, 16 that the mirror script can't connect on the first try, and then when it finally connects after some time the connection becomes broken. He was going to play with some parameters while trying to fix the issue, but the situation hasn't become better since that time. This continues for several weeks already. So, some recently released Etch packages (in particular wine) can't be installed as shown below. $ sudo aptitude update && sudo aptitude upgrade [...] The following packages will be upgraded: libwine libwine-gl libwine-print wine wine-utils 5 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 2268kB/11.0MB of archives. After unpacking 12.3kB will be used. Do you want to continue? [Y/n/?] Err http://ftp.ru.debian.org etch/main wine 0.9.25-2.1 404 Not Found [IP: 193.233.9.194 80] Err http://ftp.ru.debian.org etch/main wine-utils 0.9.25-2.1 404 Not Found [IP: 193.233.9.194 80] E: Failed to fetch http://ftp.ru.debian.org/debian/pool/main/w/wine/wine_0.9.25-2.1_i386.deb: 404 Not Found [IP: 193.233.9.194 80] $ cat /etc/apt/sources.list | grep -v '^#' deb http://ftp.ru.debian.org/debian etch main contrib non-free deb http://security.debian.org etch/updates main contrib non-free deb-src http://ftp.ru.debian.org/debian etch main contrib non-free deb-src http://security.debian.org etch/updates main contrib non-free -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420668: mirrors: Main Russian mirror (http://ftp.ru.debian.org) is incomplete
severity 420668 normal stop Looks like the problem was resolved recently. At least wine has just been installed successfully. On the other hand I use pretty minimal set of packages, so I can't be 100% sure. Therefore, I'm not closing the bug right now, but rather demoting the severity. I'll close it after some time passes or in case I receive confirmation from the webmaster. -- ...Bye..Dmitry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
