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 <skirpic...@gmail.com> 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?
>
