A possible security issue in php-adodb has been announced: http://www.openwall.com/lists/oss-security/2016/09/07/8 It will be fixed in 5.20.7. We should at least update Cauldron when it's available.
Assinging to all packagers collectively, since there is no registered maintainer for this package
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
Debian-LTS has issued an advisory for this today (September 13): http://lwn.net/Alerts/700508/
URL: (none) => http://lwn.net/Vulnerabilities/700521/
CVE-2016-7405 assigned: http://www.openwall.com/lists/oss-security/2016/09/15/1
Summary: php-adodb possible SQL injection security issue fixed in 5.20.7 => php-adodb possible SQL injection security issue fixed in 5.20.7 (CVE-2016-7405)
Also fixed in 5.20.6 is CVE-2016-4855, which is a flaw in one of its "test scripts," which sounds to me like it's probably not anything serious then, but something we can fix too. LWN reference: http://lwn.net/Vulnerabilities/701151/ Fedora has issued an advisory for this on September 17: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/YEQRR6ACD2LKEM7HJDVFCLPQ4ZY6U7K4/
URL: http://lwn.net/Vulnerabilities/700521/ => http://lwn.net/Vulnerabilities/702316/
php-adodb-5.20.7-1.mga6 uploaded for Cauldron. If applicable, we could backport patches for Mageia 5. RedHat's bugs identify the following fix commits. CVE-2016-7405: https://github.com/ADOdb/ADOdb/commit/bd9eca9f40220f9918ec3cc7ae9ef422b3e448b8 CVE-2016-4855: https://github.com/ADOdb/ADOdb/commit/ecb93d8c1
Version: Cauldron => 5Severity: normal => major
Suggested advisory: ======================== The updated package fix security vulnerabilities: The qstr method in the PDO driver in the ADOdb Library for PHP before 5.x before 5.20.7 might allow remote attackers to conduct SQL injection attacks via vectors related to incorrect quoting. (CVE-2016-7405) Cross Site Scripting vulnerability in test script (CVE-2016-4855) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7405 http://www.openwall.com/lists/oss-security/2016/09/15/1 http://lwn.net/Alerts/700508/ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4855 http://lwn.net/Vulnerabilities/701151/ ======================== Updated packages in core/updates_testing: ======================== i586: php-adodb-5.18-5.1.mga5.noarch.rpm x86_64: php-adodb-5.18-5.1.mga5.noarch.rpm Source RPMs: php-adodb-5.18-5.1.mga5.src.rpm
Status: NEW => ASSIGNEDCC: (none) => nicolas.salgueroAssignee: pkg-bugs => qa-bugsSource RPM: php-adodb-5.20.3-1.mga6.src.rpm => php-adodb-5.18-5.mga5.src.rpm
CC: (none) => mageiaWhiteboard: (none) => advisory
MGA5-32 on AcerD620 Xfce No installation issues. Looked in vain for some simple testing that does not involve writing some test script myself.
CC: (none) => herman.viaene
Prior to testing, here are useful POC links: For the first problem: https://github.com/ADOdb/ADOdb/issues/226 and the second: https://github.com/ADOdb/ADOdb/issues/274 although whether we can use these POCs is another matter. They presume quite a lot of related infrastructure. The second one is modelled on Win7, and Chrome (ugh). The updates have already been pushed by some other distributions.
CC: (none) => lewyssmith
Trying M5-64, awaiting mailList feedback.
Testing M5-64 real h/w : php-adodb-5.18-5.1.mga5 Following advice on IRC, it seems that both Cacti and Moodle use this module. Tried both, even if Cacti gives me problems routinely. It showed graphs just for the last day. Moodle functioned fine in various small usages. I was bedevilled by wanting to show that this module *is* called by these two applications - by looking at its last *access* time with either of: $ stat -c %x /usr/share/php/adodb/adodb.inc.php $ ls -lu /usr/share/php/adodb/adodb.inc.php This always showed the last 'write' time. The relevant / fstab option was (normal) 'relatime', which needs to be 'atime'. I changed that, re-booted, it made no difference (except that the timestamp was for the system re-boot; it did not change subsequently). Perhaps this was due to (ex man mount for the 'atime' option): "the inode access time is controlled by kernel defaults" not being appropriate. Giving up finer proofs, I shall OK this. Confirmation welcome.
Whiteboard: advisory => advisory MGA5-64-OK
For future reference, rather than trying to use unreliable access time, you can use audit to put a watch on a file to see if it gets accessed.
FWIW, after talking with Lewis I decided to update with my observations of a few days ago on x86_64. I used moodle as a basis for testing php-adodb. I started with installing moodle which picked up php-adodb as one of many dependencies. When done I had the following. [mrambo@rambobox mageia]$ rpm -qa | egrep "moodle|php-adodb" moodle-2.8.12-1.mga5 php-adodb-5.18-5.mga5 I ran through the moodle setup which included adding a user, and then setting up a class. Everything worked well and I noted the access to the mariadb databases worked well with many tables being added and manipulated. As php-adodb is a database abstraction package used to manipulate a variety of databases, including mysql/mariadb, if the application can access the database without error it seems like it must be ok at least in a general sense. After seeing moodle work I added the Testing repo and updated php-adobd. [mrambo@rambobox mageia]$ rpm -qa | egrep "moodle|php-adodb" moodle-2.8.12-1.mga5 php-adodb-5.18-5.1.mga5 After the update everything in moodle operated as it had before the update and I was able to add additional content to moodle. I noted that the mariadb data table timestamps were being updated as content was added. I couldn't figure out a way to determine whether either of the two CVEs had been addressed. After seeing David's comment #11 I tried to use audit to watch for access but could not get past a permission denied error when running autrace. Given adodb's purpose, the fact that the databases can be manipulated and the application works implies that the update is ok.
CC: (none) => mrambo
Installed 32 bit mga5 in a VM this morning and repeated the same tests previously done on x86_64 using moodle as the testing basis for php-adodb. [mrambo@mga5test ~]$ rpm -qa | egrep "moodle|php-adodb" php-adodb-5.18-5.mga5 moodle-2.8.12-1.mga5 Performed moodle setup and added a class that I enrolled the admin user in. Enable the testing repo and updated php-adodb. [mrambo@mga5test ~]$ rpm -qa | egrep "moodle|php-adodb" moodle-2.8.12-1.mga5 php-adodb-5.18-5.1.mga5 After the update moodle operated as it had before. Added another class, enrolled user, and noted that certain of the data tables were being updated as all of this was done. Since php-adodb is a database abstraction package and the databases were clearly available and being updated I believe this update to also be good on mga5 32 bit.
Whiteboard: advisory MGA5-64-OK => advisory MGA5-64-OK MGA5-32-OK
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Hi, please upload the advisory
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0363.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED