From lm at mathias-kettner.de  Tue Jun 30 09:32:18 2015
From: lm at mathias-kettner.de (Lars Michelsen)
Date: Tue, 30 Jun 2015 09:32:18 +0200 (CEST)
Subject: Check_MK Werk 2384: Prevent user passwords from being visible in
 webserver log on user creation
Message-ID: <20150630073218.E7BA081FF5@mail.mathias-kettner.de>

ID:          2384
Title:       Prevent user passwords from being visible in webserver log on user creation
Component:   WATO
Level:       1
Class:       Security Fix
Version:     1.2.7i3

When a user is created using WATO, the set values of the form fields were logged
directly into the webserver access log, because the form of this page used the
GET request method. Users which have access to the log files would be able to
see the initial passwords. If you use an older version of Check_MK it is a good
idea to set the "Change password at next login or access" to force the user
to change his password on first login.

We changed this form to perform a POST request now to prevent these information
being written to the logs.


From lm at mathias-kettner.de  Tue Jun 30 09:50:02 2015
From: lm at mathias-kettner.de (Lars Michelsen)
Date: Tue, 30 Jun 2015 09:50:02 +0200 (CEST)
Subject: Check_MK Werk 2385: Fixed possible reflected XSS on all GUI pages
 where users can produce unhandled exceptions
Message-ID: <20150630075002.691E58060F@mail.mathias-kettner.de>

ID:          2385
Title:       Fixed possible reflected XSS on all GUI pages where users can produce unhandled exceptions
Component:   Multisite
Level:       1
Class:       Security Fix
Version:     1.2.7i3

On pages where an authenticated user can trigger an exception which is then displayed
to the user as "Internal error" dialog with details about the exception, it was possible
for the user to inject javascript code which was executed in the context of the authenticated
user.

This has been fixed that javascript/html code which is injected is being escaped correctly.


From lm at mathias-kettner.de  Tue Jun 30 10:02:44 2015
From: lm at mathias-kettner.de (Lars Michelsen)
Date: Tue, 30 Jun 2015 10:02:44 +0200 (CEST)
Subject: Check_MK Werk 2386: Fixed possible XSS on WATO rule edit page
Message-ID: <20150630080244.104928146A@mail.mathias-kettner.de>

ID:          2386
Title:       Fixed possible XSS on WATO rule edit page
Component:   WATO
Level:       1
Class:       Security Fix
Version:     1.2.7i3

A possible XSS injection has been fixed on the rule edit page of WATO. It was possible
to inject javascript code using the HTTP parameters the page is processing.


From lm at mathias-kettner.de  Tue Jun 30 10:20:31 2015
From: lm at mathias-kettner.de (Lars Michelsen)
Date: Tue, 30 Jun 2015 10:20:31 +0200 (CEST)
Subject: Check_MK Werk 2387: Fixed XSS problem on all pages using confirm
 dialogs outputting user provided parameters
Message-ID: <20150630082031.BD90E806EF@mail.mathias-kettner.de>

ID:          2387
Title:       Fixed XSS problem on all pages using confirm dialogs outputting user provided parameters
Component:   Multisite
Level:       1
Class:       Security Fix
Version:     1.2.7i3

On some pages, like for example the host group management page of WATO, it was possible
to inject user provided HTML/Javascript code into the confirm messages. An attacker could
use this to let an authenticated user open a prepared URL for privilege escalation.


From lm at mathias-kettner.de  Tue Jun 30 10:33:18 2015
From: lm at mathias-kettner.de (Lars Michelsen)
Date: Tue, 30 Jun 2015 10:33:18 +0200 (CEST)
Subject: Check_MK Werk 2388: Fixed reflected XSS on the index page using the
 start_url parameter
Message-ID: <20150630083318.4C9E582370@mail.mathias-kettner.de>

ID:          2388
Title:       Fixed reflected XSS on the index page using the start_url parameter
Component:   Multisite
Level:       1
Class:       Security Fix
Version:     1.2.7i3



From lm at mathias-kettner.de  Tue Jun 30 10:43:01 2015
From: lm at mathias-kettner.de (Lars Michelsen)
Date: Tue, 30 Jun 2015 10:43:01 +0200 (CEST)
Subject: Check_MK Werk 2389: Fixed XSS using the _body_class parameter of views
Message-ID: <20150630084301.90E238019D@mail.mathias-kettner.de>

ID:          2389
Title:       Fixed XSS using the _body_class parameter of views
Component:   Multisite
Level:       1
Class:       Security Fix
Version:     1.2.7i3

It was possible to use the _body_class parameter of the status GUI views
to inject HTML/Javascript code into the pages.

The _body_class parameter, which was only used for internal purposes, has
totally been removed now.


From lm at mathias-kettner.de  Tue Jun 30 10:49:17 2015
From: lm at mathias-kettner.de (Lars Michelsen)
Date: Tue, 30 Jun 2015 10:49:17 +0200 (CEST)
Subject: Check_MK Werk 2390: Fixed possible XSS issue on views
Message-ID: <20150630084917.5CBDA8063B@mail.mathias-kettner.de>

ID:          2390
Title:       Fixed possible XSS issue on views
Component:   Multisite
Level:       1
Class:       Security Fix
Version:     1.2.7i3

It was possible to use the view_name variable to inject HTML/Javascript
code into the status GUI views.


From lm at mathias-kettner.de  Tue Jun 30 13:19:17 2015
From: lm at mathias-kettner.de (Lars Michelsen)
Date: Tue, 30 Jun 2015 13:19:17 +0200 (CEST)
Subject: Check_MK Werk 2391: Auth cookie is using "secure" flag when HTTPS
 request detected
Message-ID: <20150630111917.AF87780622@mail.mathias-kettner.de>

ID:          2391
Title:       Auth cookie is using "secure" flag when HTTPS request detected
Component:   Multisite
Level:       1
Class:       Security Fix
Version:     1.2.7i3

In previous versions the authentication cookie, which identifies an
authenticated user with the GUI, was never using the "secure" flag.
This means the cookie was sent to the webserver when doing HTTP and
HTTPS requests. In such a situation a user which authenticated using
HTTPS could access the GUI using HTTP and was still authenticated
becaus the browser sends the HTTPS related cookie via HTTP. This is
some kind of security risk since the information which should only
be transported using the encrypted HTTPS requests could be transported
in clear text over the network using HTTP.

The GUI tries now to detect the HTTPS requests. In case a HTTPS
request is detected, the cookies are set with the "secure" flag
which makes the cookies only used via HTTPS.

The HTTPS detection currently checks wether or not the HTTP request
header <tt>X-Forwarded-Proto</tt> is set to <tt>https</tt>.


From lm at mathias-kettner.de  Tue Jun 30 13:46:52 2015
From: lm at mathias-kettner.de (Lars Michelsen)
Date: Tue, 30 Jun 2015 13:46:52 +0200 (CEST)
Subject: Check_MK Werk 2392: Auth cookie is always using "httponly" flag
Message-ID: <20150630114652.626AC81A22@mail.mathias-kettner.de>

ID:          2392
Title:       Auth cookie is always using "httponly" flag
Component:   Multisite
Level:       1
Class:       Security Fix
Version:     1.2.7i3

All newly issued authentication cookies have the flag "httponly"
set now. This makes the cookie values inaccessible from scripts
executed in the browser, e.g. from Javascript. This secures the
cookie against some sorts of cookie stealing attempts.

See https://www.owasp.org/index.php/HttpOnly for details.