Bug#316590: woody backport now available for all cacti security issues
Sean Finney wrote: this is done now. Thanks a lot. I have reviewed it and will use it for the advisory. Regards, Joey -- Reading is a lost art nowadays. -- Michael Weber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316590: woody backport now available for all cacti security issues
Sean Finney wrote: hi, On Mon, Jul 18, 2005 at 07:21:29PM +0200, Martin Schulze wrote: i'll try and set some time aside tonight or tomorrow to test, but it looks good from an initial glance. Any outcome? In other words, any reason not to issue the advisory and update now? i haven't had a chance to look at it yet, i've been busy packing up my personal life into boxes the past few days. i'm flying out to california today, and will have ample airport/airplane time with my laptop, so i should have something for you in the next 24 hours. i'll not only verify the patch works, but also see if there are any other variables that we missed which need to be dug up for sanity checking. Ok, I'll wait. Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315703: Bug#316590: woody backport now available for all cacti security issues
On Tue, Jul 19, 2005 at 07:54:31AM +0200, Martin Schulze wrote: Ok, I'll wait. so, a 6 hour plane flight later, i've learned 3 things: 1 - there are a number of other variables that also need to be included. 2 - there are a number of calls where variables are indirectly passed to mysql_foo functions via other functions (which causes a problem for the current sanity checking method) 3 - there is another, ridiculously obvious security vulnerability in the woody version. 1 is easy to fix, we can just add on the extra variables to the file. of the 900 or so calls to mysql_foo functions, i had about 170 left to look at when my battery crapped out. 2 is trickier. we could either repeat the process i'm about finished with wrt mysql_foo for all the functions that pass variables to mysql_foo, or we could do the sanity checking in the function. as the former sounds ugly and even more time consuming i'm going to side with thte latter. what i think i'm going to do is split sanitize.php into sanitize and sanitize-functions. sanitize will include_once sanitize-functions, so then sanitize can be included multiple times (otherwise i believe that php will bitch about functions being redefined), and i'll just slip in a line in each mysql-calling function to include sanitize, and add the variables in said functions to sanitize.php. as for 3, well... there's a variable, which is stored in a cookie. the cookie name is cactilogin, and the value is an integer. want to guess what it does? a fix for this shouldn't be too hard, this kind of info should be stored in the session and not in the cookie. anyway, i'll have a fair amount of free time tomorrow, but will need a little sleep first :) sean -- signature.asc Description: Digital signature
Bug#315703: Bug#316590: woody backport now available for all cacti security issues
Sean Finney wrote:
On Tue, Jul 19, 2005 at 07:54:31AM +0200, Martin Schulze wrote:
Ok, I'll wait.
so, a 6 hour plane flight later, i've learned 3 things:
1 - there are a number of other variables that also need to be included.
2 - there are a number of calls where variables are indirectly passed
to mysql_foo functions via other functions (which causes a problem
for the current sanity checking method)
3 - there is another, ridiculously obvious security vulnerability in
the woody version.
Thanks a lot for your investigation!
1 is easy to fix, we can just add on the extra variables to the file.
of the 900 or so calls to mysql_foo functions, i had about 170 left
to look at when my battery crapped out.
2 is trickier. we could either repeat the process i'm about finished
with wrt mysql_foo for all the functions that pass variables to
mysql_foo, or we could do the sanity checking in the function. as
the former sounds ugly and even more time consuming i'm going to
side with thte latter.
The less work and the less intrusive the patch the better.
what i think i'm going to do is split sanitize.php into sanitize and
sanitize-functions. sanitize will include_once sanitize-functions,
so then sanitize can be included multiple times (otherwise i believe
that php will bitch about functions being redefined), and i'll just
slip in a line in each mysql-calling function to include sanitize,
and add the variables in said functions to sanitize.php.
Sounds good.
as for 3, well... there's a variable, which is stored in a cookie.
the cookie name is cactilogin, and the value is an integer. want to
guess what it does? a fix for this shouldn't be too hard, this kind
of info should be stored in the session and not in the cookie.
Hmm, having the user id stored in a cookie is common practice.
The variable obviously needs to be sanitised as well.
anyway, i'll have a fair amount of free time tomorrow, but will need
a little sleep first :)
Ok. For reference I'm attaching the interdiff between the woody
version and the current updated version on security.debian.org (in
the private queue).
Regards,
Joey
--
Whenever you meet yourself you're in a time loop or in front of a mirror.
Please always Cc to me when replying to me on the lists.
diff -u cacti-0.6.7/include/config.php cacti-0.6.7/include/config.php
--- cacti-0.6.7/include/config.php
+++ cacti-0.6.7/include/config.php
@@ -23,6 +23,21 @@
*/?
?
+/* whether or not we pull from a db, we need re-initilize */
+global $config;
+
+/* test for suspicious user-supplied variables that would otherwise
+ affect program execution, and if so zero out config for safety */
+if(isset($_GET[do_not_read_config]) || isset($_POST[do_not_read_config])
+ || isset($_GET[config]) || isset($_POST[config])){
+$config = array();
+}
+$colors = array();
+
+## debian security backport ##
+require_once(sanitize.php);
+## debian security backport ##
+
## Debian packaging ##
include(/etc/cacti/config.php);
## Debian packaging ##
@@ -30,9 +45,6 @@
/* make sure this variable reflects your operating system type: 'unix' or
'win32' */
$cacti_server_os = unix;
-/* whether or not we pull from a db, we need re-initilize */
-global $config;
-
if ($do_not_read_config != true) {
if (isset($config) == false) {
/* make a connection to the database */
diff -u cacti-0.6.7/debian/changelog cacti-0.6.7/debian/changelog
--- cacti-0.6.7/debian/changelog
+++ cacti-0.6.7/debian/changelog
@@ -1,3 +1,25 @@
+cacti (0.6.7-2.4) oldstable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Switched to using $_REQUEST instead of $_GET and $_POST since this
+version only uses $foo which is similar to $_REQUEST[foo]
+ * Reduced the number of tested variables to those actually used.
+
+ -- Martin Schulze [EMAIL PROTECTED] Fri, 15 Jul 2005 16:06:58 +0200
+
+cacti (0.6.7-2.3) oldstable-security; urgency=high
+
+ * update prepared for the security team by new maintainer.
+ * include backported updates against the two latest cacti security
+releases. this includes the following CAN id's:
+- CAN-2005-1524 (idefense remote file inclusion)
+- CAN-2005-1525 (idefense SQL injection)
+- CAN-2005-1526 (idefense remote code execution)
+- CAN-2005-2148 (hardened-php advisories 032005 and 042005)
+- CAN-2005-2149 (hardened-php advisory 052005)
+
+ -- sean finney [EMAIL PROTECTED] Mon, 11 Jul 2005 20:35:12 -0400
+
cacti (0.6.7-2.2) stable-security; urgency=medium
* Non-maintainer upload by Stable Release Manager
only in patch2:
unchanged:
--- cacti-0.6.7.orig/include/sanitize.php
+++ cacti-0.6.7/include/sanitize.php
@@ -0,0 +1,123 @@
+?php
+
+/*
+ * backported security-related changes from cacti
+ * by sean finney [EMAIL PROTECTED]
+ *
+ * to preserve my own sanity, all sanity checks are done in here, which
+ * is included by the main configuration, which is included by
Bug#315703: Bug#316590: woody backport now available for all cacti security issues
and (hopefully,) a final update...
On Tue, Jul 19, 2005 at 10:52:43AM +0200, Martin Schulze wrote:
2 is trickier. we could either repeat the process i'm about finished
with wrt mysql_foo for all the functions that pass variables to
mysql_foo, or we could do the sanity checking in the function. as
the former sounds ugly and even more time consuming i'm going to
side with thte latter.
The less work and the less intrusive the patch the better.
this is done now. turns out all the db-querying functions included
a database.php file at the beginning of the function, which then
included config.php, which then included sanitize.php.
what i think i'm going to do is split sanitize.php into sanitize and
sanitize-functions. sanitize will include_once sanitize-functions,
so then sanitize can be included multiple times (otherwise i believe
that php will bitch about functions being redefined), and i'll just
slip in a line in each mysql-calling function to include sanitize,
and add the variables in said functions to sanitize.php.
Sounds good.
this is done now.
as for 3, well... there's a variable, which is stored in a cookie.
the cookie name is cactilogin, and the value is an integer. want to
guess what it does? a fix for this shouldn't be too hard, this kind
of info should be stored in the session and not in the cookie.
Hmm, having the user id stored in a cookie is common practice.
The variable obviously needs to be sanitised as well.
the sanitizing functions now check all of get/post/cookie (and global
scoped variables for one of them too because it changes their value),
which after thinking about it seemed safer since there's no penalty for
unset variables other than a few wasted cycles.
as for the id thing, what i'm suspecting is that most/all pages are
accepting the value of that cookie as the logged in userid without making
sure the user is authenticated. but, i'm willing to keep my head in the
sand and not dig deep enough to find out whether or not this really is
a problem, because i'm just so fucking tired of dealing with this.
anyway, all the goodies are at
http://people.debian.org/~seanius/cacti/woody
and attached is the interdiff between oldstable and my patch (i believe
it also includes the latest changelog changes from you too, might want
to doublecheck that).
sean
--
diff -u cacti-0.6.7/include/config.php cacti-0.6.7/include/config.php
--- cacti-0.6.7/include/config.php
+++ cacti-0.6.7/include/config.php
@@ -23,6 +23,21 @@
*/?
?
+/* whether or not we pull from a db, we need re-initilize */
+global $config;
+
+/* test for suspicious user-supplied variables that would otherwise
+ affect program execution, and if so zero out config for safety */
+if(isset($_GET[do_not_read_config]) || isset($_POST[do_not_read_config])
+ || isset($_GET[config]) || isset($_POST[config])){
+$config = array();
+}
+$colors = array();
+
+## debian security backport ##
+require_once(sanitize.php);
+## debian security backport ##
+
## Debian packaging ##
include(/etc/cacti/config.php);
## Debian packaging ##
@@ -30,9 +45,6 @@
/* make sure this variable reflects your operating system type: 'unix' or
'win32' */
$cacti_server_os = unix;
-/* whether or not we pull from a db, we need re-initilize */
-global $config;
-
if ($do_not_read_config != true) {
if (isset($config) == false) {
/* make a connection to the database */
diff -u cacti-0.6.7/debian/changelog cacti-0.6.7/debian/changelog
--- cacti-0.6.7/debian/changelog
+++ cacti-0.6.7/debian/changelog
@@ -1,3 +1,34 @@
+cacti (0.6.7-2.5) oldstable-security; urgency=high
+
+ * retooled version of the sanity checking patch, including a much
+more comprehensive list of variable names to check. the patch also
+checks for discrepencies in any of the three G/P/C variables, and
+should address variables indirectly passed to sql queries.
+
+ -- sean finney [EMAIL PROTECTED] Tue, 19 Jul 2005 20:41:10 -0400
+
+cacti (0.6.7-2.4) oldstable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Switched to using $_REQUEST instead of $_GET and $_POST since this
+version only uses $foo which is similar to $_REQUEST[foo]
+ * Reduced the number of tested variables to those actually used.
+
+ -- Martin Schulze [EMAIL PROTECTED] Fri, 15 Jul 2005 16:06:58 +0200
+
+cacti (0.6.7-2.3) oldstable-security; urgency=high
+
+ * update prepared for the security team by new maintainer.
+ * include backported updates against the two latest cacti security
+releases. this includes the following CAN id's:
+- CAN-2005-1524 (idefense remote file inclusion)
+- CAN-2005-1525 (idefense SQL injection)
+- CAN-2005-1526 (idefense remote code execution)
+- CAN-2005-2148 (hardened-php advisories 032005 and 042005)
+- CAN-2005-2149 (hardened-php advisory 052005)
+
+ -- sean finney [EMAIL PROTECTED] Mon, 11 Jul 2005 20:35:12 -0400
+
cacti
Bug#316590: woody backport now available for all cacti security issues
hi, On Mon, Jul 18, 2005 at 07:21:29PM +0200, Martin Schulze wrote: i'll try and set some time aside tonight or tomorrow to test, but it looks good from an initial glance. Any outcome? In other words, any reason not to issue the advisory and update now? i haven't had a chance to look at it yet, i've been busy packing up my personal life into boxes the past few days. i'm flying out to california today, and will have ample airport/airplane time with my laptop, so i should have something for you in the next 24 hours. i'll not only verify the patch works, but also see if there are any other variables that we missed which need to be dug up for sanity checking. sean -- signature.asc Description: Digital signature
Bug#316590: woody backport now available for all cacti security issues
sean finney wrote: On Fri, Jul 15, 2005 at 04:15:22PM +0200, Martin Schulze wrote: However, as I don't like the next week part too much, I'll try to work on the update on my own and send you the diff for comments. Should reduce the time you need to spend on the issue as well. Ok, here is an update. i'll try and set some time aside tonight or tomorrow to test, but it looks good from an initial glance. Any outcome? In other words, any reason not to issue the advisory and update now? Regards, Joey -- Linux - the choice of a GNU generation. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315703: Bug#316590: woody backport now available for all cacti security issues
On Thu, Jul 14, 2005 at 07:10:30PM +0200, Martin Schulze wrote: Sean Finney wrote: i guess i didn't in the email updating this, but did so in sanitize.php itself: Yes, I saw that later. I hope, my tone wasn't too harsh. my skin is fairly thick :) Yes, but the woody version does not use $_GET *anywhere* except in the alleged sanitising code you included. It uses $foo instead of $_GET[foo] all the time, which means for me - if I'm not mistaken - that we should use either $foo or $_REQUEST[foo] in the sanitising code. yes. we could either pass the variable names as strings and dereference them (like $$name), or use $_REQUEST, which i'm fairly sure will have the same effect. if any of them have bad values. that would make the patch even simpler. It seems to me that running them on $_REQUEST only is sufficient. Or do you know of a possibility that $foo can include something which is not in $_REQUEST when inserted via GET/POST/cookie/$whatever? if the supposition is true that $_REQUEST is set in the same order as variables set via register_globals, then no further checks would be necessary. i'm fairly certain this is the case. how does that sound? Good. However, as I don't like the next week part too much, I'll try to work on the update on my own and send you the diff for comments. Should reduce the time you need to spend on the issue as well. okay, that would be appreciated. i'm really busy in the next 4-5 days as i'm trying to get my wordly possessions sorted and packed in preparation for moving out of the country... On Fri, Jul 15, 2005 at 04:15:22PM +0200, Martin Schulze wrote: However, as I don't like the next week part too much, I'll try to work on the update on my own and send you the diff for comments. Should reduce the time you need to spend on the issue as well. Ok, here is an update. i'll try and set some time aside tonight or tomorrow to test, but it looks good from an initial glance. sean -- signature.asc Description: Digital signature
Bug#316590: woody backport now available for all cacti security issues
another update, the security release for cacti has been delayed due to complications backporting the security fix into the version in woody, which is a major release (and rewrite) behind the versions in sarge and sid. joey from the security team provided an initial attempt at backporting the backport to woody, but unfortunately it was not sufficient to completely address the vulnerability. it also did not include fixes for the second set of vulnerabilities released by the hardened-php project. having spent more time hacking on it than i'd have liked, i've now produced a new version of the backport, which i believe should address all of the relevant security issues. it can be found at the following uris: deb http://people.debian.org/~seanius/cacti/woody ./ deb-src http://people.debian.org/~seanius/cacti/woody ./ all this said, i think it should be strongly emphasized that upstream is no longer supporting the woody version of cacti and does not provide updates for it, and users should be advised to upgrade to at least the version in sarge ASAP. i'm also not convinced that there aren't other security issues in the woody version, but can at least feel reasonably comfortable that of the recently published vulnerabilities woody's cacti should be okay with this new revision. joey, mike, et al: is there anything else you need from me? thanks, sean -- signature.asc Description: Digital signature
