Bug 21331 - glpi new security issues fixed upstream in 9.1.5 and 9.1.6
Summary: glpi new security issues fixed upstream in 9.1.5 and 9.1.6
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard:
Keywords: feedback
Depends on:
Blocks:
 
Reported: 2017-07-23 21:51 CEST by David Walser
Modified: 2017-09-06 15:09 CEST (History)
4 users (show)

See Also:
Source RPM: glpi-9.1.1-2.mga6.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2017-07-23 21:51:55 CEST
Fedora has issued an advisory today (July 23):
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/LJ3F3MJ4KYXBL67QB5D7M4D52ZPORVWD/

Additionally, more security issues were also fixed in 9.1.6:
http://glpi-project.org/spip.php?page=annonce&id_breve=378&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=379&lang=en

Mageia 6 is also affected.  I'm not sure whether Mageia 5 is as well.
David Walser 2017-07-23 21:52:03 CEST

Whiteboard: (none) => MGA6TOO

Comment 1 David Walser 2017-07-25 04:07:00 CEST
glpi-9.1.6-1.mga7 uploaded for Cauldron by Guillaume.

Whiteboard: MGA6TOO => (none)
Version: Cauldron => 6

Comment 2 Nicolas Lécureuil 2017-07-27 01:48:09 CEST
9.1.6 pushed in mga6 updates_testing ( using guillaume cauldron's commit )
src.rpm:  glpi-9.1.6-1.mga6

CC: (none) => mageia
Assignee: guillomovitch => qa-bugs

Comment 3 David Walser 2017-07-27 02:09:54 CEST
Advisory:
========================

Updated glpi package fixes security vulnerabilities:

The glpi package has been updated to version 9.1.6, which fixes several
security issues and other bugs.  See the upstream release announcements for
details.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11183
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11184
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11329
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11474
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11475
http://glpi-project.org/spip.php?page=annonce&id_breve=370&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=373&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=376&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=378&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=379&lang=en
========================

Updated packages in core/updates_testing:
========================
glpi-9.1.6-1.mga6

from glpi-9.1.6-1.mga6.src.rpm
Comment 4 Herman Viaene 2017-08-01 12:01:16 CEST
MGA6-32 on Asus A6000VM MATE
No installation issues.
Found tutorial at http://www.supinfo.com/articles/single/95-tutoriel-installation-glpi
But I run into a mysql issue
# mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.1.25-MariaDB Mageia MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database dbbglpi character set utf8;
Query OK, 1 row affected (0.28 sec)

MariaDB [(none)]> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

I tried
MariaDB [(none)]> uninstall plugin validate_password;
ERROR 1305 (42000): PLUGIN validate_password does not exist
MariaDB [(none)]> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

No time anymore today to investgate this further. Come and see later.

CC: (none) => herman.viaene

Comment 5 Herman Viaene 2017-08-02 11:29:10 CEST
To get around the mysql validation problem I had to comment out the line
plugin-load-add=cracklib_password_check.so
in /etc/my.cnf.d/cracklib_password_check.cnf and the restart mysqld
Then pointing Firefox to localhost/glpi just draws a blank screen. I found an error in /var/log/httpd/error_log :
[Wed Aug 02 10:26:08.045403 2017] [:error] [pid 4043] [client ::1:48288] PHP Fatal error:  require_once(): Failed opening required '/usr/share/php/ezc/Base/autoloader.php' (include_path='.:/usr/lib/php/:/usr/share/pear/:/usr/share/php/') in /usr/share/php/ezc/Graph/autoloader.php on line 138
Checked and of course /usr/share/php/ezc/Base/autoloader.php does not exist, but there was a file base_autoload.php.
I took a chance and copied that file in /usr/share/php/ezc/Base/ and named it autoloader.php.
Then pointing Firefox to localhost/glpi brings me to http://localhost/glpi/install/install.php and gives me the glpi starting screen where to select the language. But after clicking "OK" I get "No connection" and var/log/glpi is empty.
Giving up on it. Maybe someone can shad some light onthis php issue.
Comment 6 David Walser 2017-08-04 22:15:08 CEST
Fedora has issued an advisory for glpi 9.1.6 on August 2:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/CL44XMRTDZRRPNINXWREOTMEJ3HERUD7/
Comment 7 Len Lawrence 2017-08-27 16:29:55 CEST
Congratulations on the detective work Herman and kudos for experimenting.

I am trying to get this working on mga6::x86_64 but have not got very far.
Managed to get past the password hurdle using your tip about commenting out the cracklib_password_check line.

I found the tutorial very confusing.  Could not figure out if everything had to be done as root.  Do you have to create this user www-data?  I guessed not and assigned ownership of /var/www/glpi/ to myself lcl:lcl.  Pointing firefox to http://localhost/glpi raised an "Object not found!" message and there was nothing corresponding to your error in the error_log.  /usr/share/php/ezc/ does not exist.  In fact /usr/share/php/ is empty.  /var/www/glpi/ is empty because the instruction to download the glpi tarball resulted in Connection timed out and a series of retries.

Went back a bit and reassigned access rights to /var/www/glpi to root.  And there it stands.  Where to go from here?

CC: (none) => tarazed25

Comment 8 Len Lawrence 2017-08-27 16:39:56 CEST
Checking the prerequisites I saw that php was missing.  Installed php-cgi and php-suhosin but that made no difference.  Error 404 again.
Comment 9 David Walser 2017-08-27 16:59:47 CEST
www-data is a Debian user.  The package already contains the files, so it shouldn't be downloading the tarball.  You shouldn't be changing the ownership of the files in the package.

Check /etc/httpd/conf/sites.d/glpi.conf for the Alias to see what the URL should be and where the files are stored (it looks like they're in /usr/share/glpi).
Comment 10 Len Lawrence 2017-08-27 17:10:34 CEST
Thanks David for the pointer.  I really am so far out of my depth here that I was going to chuck it in.

I am still unclear about who the operator is in all this; is it me, is it root, or  ....?
Comment 11 David Walser 2017-08-27 17:23:20 CEST
I don't know anything about glpi, but hopefully it's like any other webapp where you make a database and visit the URL through localhost.  It looks like the URL is /glpi from what Herman said, but it also looks like there may be a packaging issue.

CC'ing the packager, Guillaume, since he forgot to CC himself when assigning to QA.

CC: (none) => guillomovitch
Whiteboard: (none) => feedback

Comment 12 David Walser 2017-08-27 17:24:05 CEST
Len, BTW I'm not sure what you mean by operator.
Comment 13 Len Lawrence 2017-08-27 17:55:53 CEST
Who is regarded as the user?  Who should be given access to glpi?
I know virtually nothing about databases and web interfaces.

I tried this:
And yes, I did wonder what the tarball might contain that was not already installed.  Contents of usr/share/glpi moved to /var/www/
Gave myself full access rights to /var/www/glpi/

mysql:
MariaDB..> create database dbbglpi character set utf8;
ERROR 1007 (HY000): Can't create database 'dbbglpi'; database exists
MariaDB [(none)]> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> exit
Bye

Tried http://localhost/glpi/ and hit error 404.

> drop database dbbglpi;
Query OK, 0 rows affected (0.00 sec)

> create database dbbglpi character set utf8;
Query OK, 1 row affected (0.00 sec)

> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

Back to localhost/glpi/  =>  Error 404
Comment 14 David Walser 2017-08-27 18:07:08 CEST
(In reply to Len Lawrence from comment #13)
> Who is regarded as the user?  Who should be given access to glpi?
> I know virtually nothing about databases and web interfaces.

What user?  What do you mean given access?

> I tried this:
> And yes, I did wonder what the tarball might contain that was not already
> installed.  Contents of usr/share/glpi moved to /var/www/
> Gave myself full access rights to /var/www/glpi/

Why are you doing that?  Don't do that.  I imagine the Alias I told you about refers to /usr/share/glpi so it's already looking for it there, as installed by the package.  From what Herman said it sounds like that much does work, so I'm not sure why you're seeing a 404.  Anything useful in /var/log/httpd/access_log or error_log?
Comment 15 Len Lawrence 2017-08-27 18:18:16 CEST
Sorry David, I only just noticed what you said about not changing ownership.  Have reverted that.

It also struck me as very odd that the tutorial instructed the user to move the whole lot from /usr /to /var/www.  I shall put things back the way they were and see if it goes as far as Herman drove it.
Comment 16 Len Lawrence 2017-08-27 18:41:03 CEST
Re comment 14.

I was confused about who actually owned the database, root, the user, ...?
$ sudo updatedb
$ locate dbbglpi
/var/lib/mysql/dbbglpi
$ ls -l /var/lib/mysql/dbbglpi
ls: cannot open directory '/var/lib/mysql/dbbglpi': Permission denied

It is owned by mysql:mysql and I am not a member of the mysql group.  Should I be?
Comment 17 Len Lawrence 2017-08-27 18:52:09 CEST
access_log contains nothing useful, just repeated

127.0.0.1 - - [27/Aug/2017:17:09:42 +0100] "GET /glpi/ HTTP/1.1" 404 1037 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"

and nothing at all in error_log around the time of the experiments.
Comment 18 claire robinson 2017-08-27 18:59:47 CEST
I think you're over thinking this Len.

For most webapps, assuming you already have task-lamp installed and services running, you then install the package(s), configure a database for it to use - simplest way is to use phpmyadmin - then visit the url http:/localhost/<package>.

There are nothing related to any desktop user, in the same way as creating an account at Mageia doesn't require any desktop settings.

Typically, installing the package also restarts/reloads apache to re-read the new apache configuration files for the package - kept in /etc/httpd/sites.d/

There may be an web based installer which will request database details, etc to follow, and occasionally it's a manual process. To find the configuration files look in the apache packae config file to see where the "Alias" is linked to. It'll typically say something like:

Alias glpi /usr/share/glpi

Which means when you visit http://localhost/glpi apache instructs your browser to display the web stuff in /usr/share/glpi

It's really just a glorified symlink with a database attached.
Comment 19 claire robinson 2017-08-27 19:01:18 CEST
might be /etc/httpd/conf/sites.d for the conf files actually, off the top of my head.
Comment 20 David Walser 2017-08-27 19:07:58 CEST
Len, database users and Linux users are two completely different things.  You shouldn't be manually messing with the files in /var/lib/mysql.  As Claire alluded to, in mysql you create a database user to own the database and then you have to give those details to the webapp some how.
Comment 21 Len Lawrence 2017-08-27 19:40:35 CEST
Thanks Claire and David.  Databases and web applications are another country for me.  However from what you have said there appears to be no reason why the configuration interface should not display in a browser.  Everything seems to be in order, except perhaps the lamp stack.  Since I had to install php manually there is a good chance something else might be missing.

Right.  Installed task-lamp, restarted httpd and tried the link.  This time it simple hangs on a blank page.  mysqld is running.

glpi.conf has a stanza for the glpi directory:

<Directory /usr/share/glpi>
    Require all granted
    Options -FollowSymLinks
    # recommanded value
    php_value memory_limit 64M
</Directory>

but further down "Require all denied" for files, locales, mysql etc.
Comment 22 Len Lawrence 2017-08-27 20:04:37 CEST
There is a 404 error buried in the access error log:
$ tail /var/log/httpd/access_log
.....................
192.168.1.156 - - [27/Aug/2017:18:28:10 +0100] "GET /glpi/ HTTP/1.1" 500 - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"
127.0.0.1 - - [27/Aug/2017:18:28:59 +0100] "GET /glpi HTTP/1.1" 301 230 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"
127.0.0.1 - - [27/Aug/2017:18:28:59 +0100] "GET /glpi/ HTTP/1.1" 500 - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"
127.0.0.1 - - [27/Aug/2017:18:28:59 +0100] "GET /favicon.ico HTTP/1.1" 404 1037 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"
127.0.0.1 - - [27/Aug/2017:18:28:59 +0100] "GET /favicon.ico HTTP/1.1" 404 1037 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"

Went on to try Herman's neat little trick of renaming the autoloader file and up came the interface!!!

Traversed a couple of screens but refrained from either installing or upgrading glpi.  It works as far as that.  The puzzle now is why Herman cannot reach the GPL Licence page (step 2).  /var/log/glpi/ is empty here too so that is probably OK.

Good for 64-bits once the autoloader business is fixed.
Comment 23 David Walser 2017-08-27 20:07:58 CEST
A 404 on the favicon.ico is OK.
Comment 24 Len Lawrence 2017-08-27 20:30:50 CEST
And now for the update. :p

The package installed fine.  Dropped the two databases created previously and checked the autoloader fix in /usr/share/php.  Installation restarts the httpd server.

Pointed firefox at localhost/glpi/ to invoke the configuration page.  Working perfectly.

OK for 64-bits.  Do we raise a bug on the PHP autoloader issue?  Is it a separate issue or something in the glpi packaging?

Maybe we should wait for Guillaume's response to this.
Comment 25 Guillaume Rousse 2017-08-28 20:46:43 CEST
Pushing the cauldron package directory into stable release was not a great idea, for at least two reasons:
- first, it is a major version update, triggering a database schema change, which is largely unexpected given our update policy
- second, the new package relies on every PHP package dependencies to ship an autoloader with an expected filename, which is not the case in mageia 5

The correct fix here is to port the following commits to GLPI 0.84:
https://github.com/glpi-project/glpi/pull/2492/commits/7b7051fe42d36f53270b943b1a3c238c9ed503b5
https://github.com/glpi-project/glpi/pull/2481/commits/1a1e9e15f0dd52d68f18e0d64ab1ded199f3c263
https://github.com/glpi-project/glpi/pull/2481/commits/9619f0235615f14e088d31edc7a0ac3c5f30ac9a

I'll try to do it during the week, unless someone else manage to do it first.
Comment 26 Guillaume Rousse 2017-08-28 21:13:42 CEST
None of those commits apply, because the corresponding code doesn't exist in 0.84. Which could perfectly mean than 0.84 is not concerned by the problem. 

Also, those commits only correspond to the security issues fixes with 9.1.6 release, we also have similar issues in 9.1.5, 9.1.4, etc... That's way too much work, for dubious benefits. Especially given the lack of authoritative information (CVE number, and vulnerability statement).

For all those reasons, I'd rather not push any update for mageia 5, unless someone want to handle this work properly. We may eventually provide backports of glpi 9, if current infrastructure allows it, for interested users.
Comment 27 Samuel Verschelde 2017-09-06 15:09:32 CEST
Moving 'feedback' from whiteboard to keywords now that madb has been updated to handle that keyword.

Keywords: (none) => feedback
Whiteboard: feedback => (none)


Note You need to log in before you can comment on or make changes to this bug.