Bug#907815: gosa: UI behaves strangely, some data not saved

[Mike Gabriel]

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.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1045_dont_use_filter_caching.patch
URL: <http://alioth-lists.debian.net/pipermail/debian-edu-pkg-team/attachments/20190419/c21f7464/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: Digitale PGP-Signatur
URL: <http://alioth-lists.debian.net/pipermail/debian-edu-pkg-team/attachments/20190419/c21f7464/attachment.sig>