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

Mike Gabriel mike.gabriel at das-netzwerkteam.de
Fri Apr 19 10:31:53 BST 2019


Hi Dominik,

@security-team: I need feedback on the below. It might be worth a CVE.  
Thanks for feedback.

On  Fr 26 Okt 2018 22:38:31 CEST, Dominik George wrote:

> Control: severity -1 important
>
> Here are two errors I get when continuing to use GoSA after the error
> occurred:

I looked into this last night (yawn..., it got late).

> Fatal error: Uncaught ArgumentCountError: Too few arguments to function
> userManagement::filterLockLabel(), 0 passed in
> /usr/share/gosa/include/class_listing.inc on line 856 and exactly 1 expected
> in /usr/share/gosa/plugins/admin/users/class_userManagement.inc:856 Stack
> trace: #0 /usr/share/gosa/include/class_listing.inc(856):
> userManagement::filterLockLabel() #1
> /usr/share/gosa/include/class_listing.inc(980):
> listing->processElementFilter('%{filter:lockLa...', Array, 0) #2
> /usr/share/gosa/include/class_listing.inc(853):
> listing->filterActions('cn=nik,ou=group...', 0, Array) #3
> /usr/share/gosa/include/class_listing.inc(764):
> listing->processElementFilter('%{filter:action...', Array, 0) #4
> /usr/share/gosa/include/class_listing.inc(407):
> listing->renderCell('%{filter:action...', Array, 0) #5
> /usr/share/gosa/include/class_management.inc(225): listing->render() #6
> /usr/share/gosa/include/class_management.inc(214): management->renderList()
> #7 /usr/share/gosa/plugins/admin/users/main.inc(44): management->execute()
> #8 /usr/share/ in
> /usr/share/gosa/plugins/admin/users/class_userManagement.inc on line 856
>
> Fatal error: Uncaught Error: Call to undefined method aclResolver::update()
> in /usr/share/gosa/include/class_management.inc:167 Stack trace: #0
> /usr/share/gosa/plugins/admin/users/main.inc(44): management->execute() #1
> /usr/share/gosa/html/main.php(407): require('/usr/share/gosa...') #2 {main}
> thrown in /usr/share/gosa/include/class_management.inc on line 167

The error message itself is a red herring, but it shows that something  
is going very wrong with the GOsa² filter implementation when  
rendering (filtered) lists of LDAP objects.

> Seems like some random errors triggered by some corruption of I do not know
> what kind.

It seems like it, but it is in fact quite systematic.

> Going back to main.php, logging out and back in again returns GoSA to a
> usable state again, until it happens next time.

Yep. Confirmed. Logging out empties the PHP $_SESSION.

> 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).

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.

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.

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 --------------
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/7f04a505/attachment.sig>


More information about the Debian-edu-pkg-team mailing list