Control: tags -1 patch Hi Nik,
On Fr 19 Apr 2019 13:01:24 CEST, Dominik George wrote:
Hi,> The bug also happens in a new Debian Edu install, both stretch and buster,> and can also be triggered by using any list views in some random order, e.g.> when editing roles and groups of a few users in a row. After some research and after looking at $_SESSION when the above described error occurs, I found this: https://stackoverflow.com/questions/1442177/storing-objects-in-php-session https://stackoverflow.com/questions/132194/php-storing-objects-inside-the-session I stumbled over this comment in the gosa code, then: https://github.com/gosa-project/gosa-plugins-systems/blob/cf34737977a97e0090e09390b209078dabdc77af/admin/systems/class_systemManagement.inc#L90 So, in fact, this strange behavious is a known issue and we have been lucky enough to not stumble over it earlier. The underlying cause of this is that the filter cache implementation stores PHP objects in $_SESSION (which one should not do when PHP is used for rendering a web page). I fact, this could lead to all sorts of troubles, because the object reference stored in $_SESSION while loading URL-1 will very likely not be the same reference when URL-2 gets loaded and the object is retrieved again from $_SESSION. In fact, the old reference could point to anywhere in the PHP sessions RAM area (and thus deliver all sorts of artefact / unpredictable behaviour).To anywhere in the session storage, as in, including data of other user sessions and their possibly secret data? So…
Not other user sessions, but if the $_SESSION changes between URL-1 and URL-2, the stored reference may be inaccurate. This is all within one http session of one user AFAICT.
I am not 100% sure, but I have a sense that this is actually worth a CVE. Thus, Cc:-ing the security-team for advice.…it is.I have tried to come up with some patches, but my sense is that the only good solution for now (buster release knocks at our door) is disabling the $_SESSION based filter cache and reload the "*-filter.xml files from the file system everytime a class_<what>Management based page is opened.This does not cost us anything except some performance, which GOSa lacks anyway ;). So I'd go with that, also for stable-security. -nik
Can you please test the attached patch and report back if the weird UI display phenomena are gone when the patch is applied?
Thanks, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
--- a/gosa-core/include/class_management.inc
+++ b/gosa-core/include/class_management.inc
@@ -131,7 +131,15 @@
$this->registerAction("cancelFilter","cancelFilter");
// To temporay disable the filter caching UNcomment this line.
- #session::global_un_set(get_class($this)."_filter");
+
+ /*
+ * As a work-around for flawed object storage in the PHP $_SESSION array
+ * the filter caching has been deactivated since gosa 2.7.4+reloaded3-8.
+ *
+ * See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907815#31 for
+ * details.
+ */
+ session::global_un_set(get_class($this)."_filter");
}
pgpemnPkzhQm4.pgp
Description: Digitale PGP-Signatur
