Bug#847196: monit segfault on stop and start
Hello,
the problem is in debian patch (5.4-2+deb7u2):
--- a/src/collector.c
+++ b/src/collector.c
@@ -64,10 +64,13 @@
*/
static int data_send(Socket_T socket, Mmonit_T C, const char *D) {
char *auth = Util_getBasicAuthHeader(C->url->user, C->url->password);
+MD_T token;
+ Util_getToken(token);
int rv = socket_print(socket,
"POST %s HTTP/1.1\r\n"
"Host: %s:%d\r\n"
"Content-Type: text/xml\r\n"
+ "Cookie: securitytoken=%s\r\n"
"Content-Length: %d\r\n"
"Pragma: no-cache\r\n"
"Accept: */*\r\n"
@@ -79,6 +82,7 @@ static int data_send(Socket_T socket, Mm
C->url->path,
C->url->hostname, C->url->port,
strlen(D),
+ token,
prog, VERSION,
auth?auth:"",
D);
the format string contains "Cookie: securitytoken=%s\r\n" before
"Content-Length: %d\r\n", but the token argument comes before strlen(D) in the
position for Content-Length argument - the program then reads from this integer
value as if it would be pointer.
The securitytoken in collector is not needed at all - the CSRF protection is
related to Monit's own HTTP API (the securitytoken cookie is not present in
upstream). To fix the problem, just drop the collector.c part of the patch.
Best regards,
Martin
> On 12 Dec 2016, at 13:22, Sergey B Kirpichev wrote:
>
> On Mon, Dec 12, 2016 at 01:11:38PM +0100, Arthur Hoffmann wrote:
>> Ok, now I have checked my config files and found out that it
>> works with the latest package if I remove the following line:
>>
>> set mmonit https://USER:PASSWORD@URL:PORT/collector
>
> Ok, I see. I don't use closed-source software, so I can't help.
>
> Perhaps, other maintainers can.
>
>> I'm using Monit with the latest M/Monit v3.6.2.
>
> There is 5.20.0 in backports (that fixes CVE). Could you test
> this version too, as it could be that your problem is relevant
> to upstream package?
>
Bug#847196: monit segfault on stop and start
Sorry for typo in the explanation ... the "token" comes *after* "strlen(D)" in
the patch - in short:
integer "strlen(D)" is used as string argument for "Cookie:
securitytoken=%s\r\n" => CRASH
string "token" is used as integer argument for "Content-Length:
%d\r\n" ... harmless, but will give wrong content length, so the POST request
will fail
Best regards,
Martin
> On 12 Dec 2016, at 14:06, Martin Pala wrote:
>
> Hello,
>
> the problem is in debian patch (5.4-2+deb7u2):
>
> --- a/src/collector.c
> +++ b/src/collector.c
> @@ -64,10 +64,13 @@
> */
> static int data_send(Socket_T socket, Mmonit_T C, const char *D) {
> char *auth = Util_getBasicAuthHeader(C->url->user, C->url->password);
> +MD_T token;
> + Util_getToken(token);
> int rv = socket_print(socket,
> "POST %s HTTP/1.1\r\n"
> "Host: %s:%d\r\n"
> "Content-Type: text/xml\r\n"
> + "Cookie: securitytoken=%s\r\n"
> "Content-Length: %d\r\n"
> "Pragma: no-cache\r\n"
> "Accept: */*\r\n"
> @@ -79,6 +82,7 @@ static int data_send(Socket_T socket, Mm
> C->url->path,
> C->url->hostname, C->url->port,
> strlen(D),
> + token,
> prog, VERSION,
> auth?auth:"",
> D);
>
>
>
> the format string contains "Cookie: securitytoken=%s\r\n" before
> "Content-Length: %d\r\n", but the token argument comes before strlen(D) in
> the position for Content-Length argument - the program then reads from this
> integer value as if it would be pointer.
>
> The securitytoken in collector is not needed at all - the CSRF protection is
> related to Monit's own HTTP API (the securitytoken cookie is not present in
> upstream). To fix the problem, just drop the collector.c part of the patch.
>
> Best regards,
> Martin
>
>
>
>> On 12 Dec 2016, at 13:22, Sergey B Kirpichev wrote:
>>
>> On Mon, Dec 12, 2016 at 01:11:38PM +0100, Arthur Hoffmann wrote:
>>> Ok, now I have checked my config files and found out that it
>>> works with the latest package if I remove the following line:
>>>
>>> set mmonit https://USER:PASSWORD@URL:PORT/collector
>>
>> Ok, I see. I don't use closed-source software, so I can't help.
>>
>> Perhaps, other maintainers can.
>>
>>> I'm using Monit with the latest M/Monit v3.6.2.
>>
>> There is 5.20.0 in backports (that fixes CVE). Could you test
>> this version too, as it could be that your problem is relevant
>> to upstream package?
>>
>
Bug#643019: monit: FTBFS: configure: error: Architecture not supported: `uname`.
Hi, we we have added support for GNU/kFreeBSD to Monit … it will be part of next release (monit 5.4). It is necessary to install the libkvm-dev package to compile Monit on kFreeBSD. Regards, Martin On Sep 26, 2011, at 6:06 PM, Christoph Egger wrote: > Package: src:monit > Version: 1:5.3-1 > Severity: serious > Tags: sid wheezy > Justification: fails to build from source (but built successfully in the past) > > Hi! > > Your package failed to build on the kfreebsd-* buildds: > > checking for sys/filio.h... yes > configure: error: Architecture not supported: `uname`. > configure: error: ./configure failed for libmonit > > Full build log at > https://buildd.debian.org/status/fetch.php?pkg=monit&arch=kfreebsd-amd64&ver=1%3A5.3-1&stamp=1316043872 > > Regards > >Christoph > > If you have further questions please mail debian-...@lists.debian.org > > -- > 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 > Debian Developer | Lisp Hacker | CaCert Assurer > > > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#621047: monit: FTBFS with ssv2 removal: ssl.c:645: undefined reference to `SSLv2_client_method'
Hello, the patch is attached Best regards, Martin ssl.patch Description: Binary data On Apr 6, 2011, at 6:10 AM, Cyril Brulebois wrote: > Source: monit > Version: 1:5.2.5-1 > Severity: serious > Justification: FTBFS > > Hi, > > your package FTBFS with: > | gcc -rdynamic alert.o collector.o control.o daemonize.o env.o event.o > file.o gc.o http.o log.o md5.o monitor.o net.o process.o sendmail.o sha.o > signal.o socket.o spawn.o ssl.o state.o status.o util.o validate.o xmalloc.o > xml.o device/device_common.o http/base64.o http/cervlet.o http/engine.o > http/processor.o process/process_common.o protocols/apache_status.o > protocols/clamav.o protocols/default.o protocols/dns.o protocols/dwp.o > protocols/ftp.o protocols/generic.o protocols/gps.o protocols/http.o > protocols/imap.o protocols/ldap2.o protocols/ldap3.o protocols/lmtp.o > protocols/memcache.o protocols/mysql.o protocols/nntp.o protocols/ntp3.o > protocols/pgsql.o protocols/pop.o protocols/postfix_policy.o > protocols/protocol.o protocols/radius.o protocols/rdate.o protocols/rsync.o > protocols/sip.o protocols/smtp.o protocols/ssh.o protocols/tns.o > device/sysdep_LINUX.o process/sysdep_LINUX.o y.tab.o lex.yy.o -lfl -lpam > -lpthread -lcrypt -lresolv -lnsl -L/usr/lib -lssl -lcrypto -o monit > | ssl.o: In function `new_ssl_connection': > | /build/buildd-monit_5.2.5-1-i386-RcVJYW/monit-5.2.5/ssl.c:645: undefined > reference to `SSLv2_client_method' > | collect2: ld returned 1 exit status > | make[1]: *** [monit] Error 1 > > Full build logs: > https://buildd.debian.org/status/package.php?p=monit > > KiBi. > > >
Bug#503311: monit: Client Certificate authentication fails with openssl-engine error
Georges Toth wrote: Quoting Martin Pala <[EMAIL PROTECTED]>: Please can you provide your monit configuration? (the "set httpd ..." part is sufficient). set httpd port 28000 and use address 123.123.123.123 ssl enable pemfile /etc/ssl/ca_priv_pub.pem clientpemfile /etc/monit/client_certificates.pem ALLOWSELFCERTIFICATION Is the certificate self-signed or using public CA? It's a self-signed certificate. Besides the version, nothing changed on the server. Firefox (32bit binary, 3.x, gentoo) seems to be the problem here. Certificate is correctly installed, including root (with correct cert-permissions set in firefox). Firefox doesn't even ask for me to choose a certificate. On other website it on the other hand does. Really strange... I tried to replicate ... using self-compiled monit-5.0_beta4 with libssl-0.9.8g-13 on Debian-unstable with Iceweasel-3.0.3-2 works fine. Configuration: --8<-- set httpd port 2812 and use address 127.0.0.1 ssl enable pemfile /var/certs/monit.pem clientpemfile /var/certs/monit_client.pem allowselfcertification allow localhost --8<-- I can see the same error logged which you saw as well: --8<-- monit: Openssl engine error: error:140D9115:SSL routines:func(217):reason(277) --8<-- ... but the authentication works, and i don't see the error which you mentioned and which is root cause of the problem: --8<-- monit[2067]: monit: The client did not supply a required client certificate! --8<-- When i switched the Iceweasel's certificate setting: Edit->Preferences->Advanced->Encryption->"When a server requests my personal certificate" to "Ask me every time" i get the dialog which reports that Monit asked for certificate and allows to select the certificate. Summary: it's quite strange problem - in Monit there were no changes in SSL related code between 4.10.1 and 5.0_beta4 so they should work the same. It's possible that it's browser problem (on your side, konqueror worked and i have tested with Iceweasel alias Firefox without problem). Thanks, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503311: monit: Client Certificate authentication fails with openssl-engine error
Please can you provide your monit configuration? (the "set httpd ..." part is sufficient). Is the certificate self-signed or using public CA? Thanks, Martin Georges Toth wrote: Package: monit Version: 1:4.10.1-4 Severity: grave Justification: renders package unusable After having upgraded to lenny, the monit webinterface no longer works with client certificate authentication. While using Debian Etch, with the exact same configuration it worked fine. Here is the error logged by monit when trying to connect: monit[2067]: monit: The client did not supply a required client certificate! monit[2067]: monit: Openssl engine error: error:140D9115:SSL routines:func(217):reason(277) monit[2067]: monit: The client did not supply a required client certificate! -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (650, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26.7 (SMP w/8 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 monit depends on: ii libc6 2.7-14 GNU C Library: Shared libraries ii libssl0.9.8 0.9.8g-13 SSL shared libraries monit recommends no packages. monit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395164: Monit fails if log file is too large
I think it should be possible ... i've just resent the original patch which implemented the large files support (contributed by Will Bryant). We did some modifications for portability reasons during the integration, but it should work as is for linux. Cheers, Martin Stefan Alfredsson wrote: Hi, Martin Pala wrote: there is support for large files (>2GB) in monit cvs already and it will be part of next monit version. Would this be easy to backport to 4.8.1 or are there major changes involved? As we are nearing the next official debian release, I'm hesitant to include the cvs version, or a newly released version, given the "package duration"/"bug found" ratio of 4.8.1 :-), but a simple backport would be OK. Regards, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395164: Monit fails if log file is too large
Hi, there is support for large files (>2GB) in monit cvs already and it will be part of next monit version. Another solution which works even with current monit versions is to compile it with 64-bit support on platforms which supports it (the large files then aren't problem). Martin Thom May wrote: Package: monit Version: 1:4.8.1-2 Severity: grave Justification: renders package unusable When a file grows larger than 2GB, monit claims it no longer exists. This causes service failure actions to be executed, resulting in potential downtime or unecessary notification of downtime. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367341: [Fwd: Re: Bug#367341: monit failed to restart after upgrade]
Hi, monit-4.8.1 was released yesterday ... Martin Stefan Alfredsson wrote: (forwarding for reference. In summary - monit needs to be compiled on amd64 for the patch to be effective. It fails when started from initscripts but works with manual start -- I'll await 4.8.1 before doing further investigations) //Stefan Original Message Subject: Re: Bug#367341: monit failed to restart after upgrade From:"ngb" <[EMAIL PROTECTED]> Date:Wed, May 17, 2006 10:12 To: "Stefan Alfredsson" <[EMAIL PROTECTED]> -- Stefan, thanks for that. I have build the source without any trouble (although it did ask me to install byacc and cdbs which monit didn't need before). However when installing it I got the following: ruby:/home/ngb/monit# dpkg -i monit_4.8-2_amd64.deb (Reading database ... 163511 files and directories currently installed.) Preparing to replace monit 1:4.7-1 (using monit_4.8-2_amd64.deb) ... Stopping daemon monitor: monit. Unpacking replacement monit ... Setting up monit (4.8-2) ... Starting daemon monitor: monitinvoke-rc.d: initscript monit, action "start" failed. dpkg: error processing monit (--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: monit However running "monit -d 240" from the command line started it with no problems. ruby:/home/ngb/monit# monit -d 240 Starting monit daemon with http interface at [*:2812] and I can log onto the web page and see that everything is working. thanks again for your help. cheers, Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367341: monit failed to restart after upgrade
Hi, this is AMD64 only related bug which is addressed by this patch for monit-4.8: http://www.tildeslash.com/monit/dist/monit-4.8-patch01 We will release monit-4.8.1 soon which will contain the fix. Martin Neil Broderick wrote: Package: monit Version: 1:4.8-1 Severity: grave Justification: renders package unusable Hi, I upgraded to the latest version of monit on the weekend with the following result: 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Do you want to continue [Y/n]? y Setting up monit (4.8-1) ... Starting daemon monitor: monit/etc/init.d/monit: line 83: 13082 Segmentation fault start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid --exec $DAEMON -- $ARGS >/dev/null 2>&1 invoke-rc.d: initscript monit, action "start" failed. dpkg: error processing monit (--configure): subprocess post-installation script returned error exit status 139 Errors were encountered while processing: monit E: Sub-process /usr/bin/dpkg returned an error code (1) Also trying to start monit manually results in: ruby:/home/ngb# monit Starting monit daemon with http interface at [*:2812] Segmentation fault or ruby:/home/ngb# /etc/init.d/monit start Starting daemon monitor: monit/etc/init.d/monit: line 83: 13088 Segmentation fault start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid --exec $DAEMON -- $ARGS >/dev/null 2>&1 thanks, Neil -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-11-amd64-k8-smp Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages monit depends on: ii libc6 2.3.6-5GNU C Library: Shared libraries an ii libssl0.9.8 0.9.8a-8 SSL shared libraries monit recommends no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
