A security issue fixed upstream in php-smarty has been announced: https://www.openwall.com/lists/oss-security/2018/09/17/4 The issue is fixed in 3.1.33.
Whiteboard: (none) => MGA6TOO
Assignee: bugsquad => phpCC: (none) => marja11
CC: (none) => mageiaAssignee: php => mageia
Updated php-smarty packages fix security vulnerabilities: ======================== Smarty 3.1.32 or below is prone to a path traversal vulnerability due to insufficient template code sanitization. This allows attackers controlling the executed template code to bypass the trusted directory security restriction and read arbitrary files. ======================== References: https://www.openwall.com/lists/oss-security/2018/09/17/4 Updated packages in core/updates_testing: ======================== php-smarty-3.1.33-1.mga6.noarch.rpm Source RPMs: php-smarty-3.1.33-1.mga6.src.rpm
Assignee: mageia => qa-bugs
@Marc, fyi, when the package is fixed in cauldron, assign the package to mga6 and remove the MGA6TOO
Whiteboard: MGA6TOO => (none)Version: Cauldron => 6CC: (none) => tmb
ok, I'll remember it next time.
# urpmi php-smarty A requested package cannot be installed: php-smarty-3.1.33-1.mga6.noarch (due to unsatisfied pear(cacheresource.pdo.php))
CC: (none) => davidwhodgins
Keywords: (none) => feedback
In reply to Dave Hodgins, comment 4. Thanks for your response Dave. I had not got as far as the update. Starting off at: php-smarty-3.1.21-3.1.mga6 php-pear-1.10.1-3.mga6.noarch
CC: (none) => tarazed25
(In reply to Dave Hodgins from comment #4) > # urpmi php-smarty > A requested package cannot be installed: > php-smarty-3.1.33-1.mga6.noarch (due to unsatisfied > pear(cacheresource.pdo.php)) This dep most likely needs to be filtered out as it is probably an internal provide
This Requirement is autogenerated. How do I suppress this? The Spec does not have any Provides or Requires itself.
Perhaps suppressing it is the wrong approach. Find out which package provides cacheresource.pdo.php and add it to Mageia 6. As a new requirement of an update to an existing Mageia 6 package to fix a security problem, the package that satisfies the new requirement is allowed to be added to Mageia 6, as an updates package.
@Dave: I find this really wired. The requirement is autogenerated and fullfilled by the package itself. We have the same package in mga7 without this requirement which installs fine. ---------- pushed php-smarty-3.1.33-1.1 to testing.
Keywords: feedback => (none)
Ran the update but cannot test the PoC example. It always fails on this autoload.php thing. There does not appear to be a vendor specific one. The upshot of this is that I am abandoning this update test. Leaving it to somebody with more knowledge of the php infrastructure.
The last "fix" to the package was incorrect anyway.
Discovered where Smarty is defined - /usr/share/php/Smarty/ <?php require_once "Smarty/Smarty.class.php"; $smarty = new Smarty; $smarty->enableSecurity(); // Fails $smarty->display('eval:{fetch file="/etc/passwd"}'); Before the update: Started the php web server and pointed firefox at localhost:8000/sample.php The server reported the failure: [Wed Oct 3 15:13:49 2018] PHP Fatal error: Uncaught --> Smarty: directory '/etc/passwd' not allowed by security setting <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 402 [Wed Oct 3 15:13:49 2018] 127.0.0.1:40644 [500]: /sample.php - Uncaught --> Smarty: directory '/etc/passwd' not allowed by security setting <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 402 The PoC report claims that this next test succeeds. // Works $smarty->display('eval:{fetch file="'.addslashes(getcwd()).'/templates/../../../../../etc/passwd"}'); But the server disagrees and issues the same error: [Wed Oct 3 15:22:35 2018] PHP Fatal error: Uncaught --> Smarty: directory '' not allowed by security setting <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 402 [Wed Oct 3 15:22:35 2018] 127.0.0.1:42756 [500]: /sample.php - Uncaught --> Smarty: directory '' not allowed by security setting <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 402 After the update the /etc/passwd test fails, as it should: [Wed Oct 3 15:31:10 2018] PHP Fatal error: Uncaught --> Smarty: Smarty Security: not trusted file path '/etc/passwd' <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 654 [Wed Oct 3 15:31:10 2018] 127.0.0.1:44940 [500]: /sample.php - Uncaught --> Smarty: Smarty Security: not trusted file path '/etc/passwd' <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 654 The second test now fails in the same way. [Wed Oct 3 15:33:54 2018] PHP Fatal error: Uncaught --> Smarty: Smarty Security: not trusted file path '/home/lcl/dev/php/templates/../../../../../etc/passwd' <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 654 [Wed Oct 3 15:33:54 2018] 127.0.0.1:45598 [500]: /sample.php - Uncaught --> Smarty: Smarty Security: not trusted file path '/home/lcl/dev/php/templates/../../../../../etc/passwd' <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 654 It is difficult to draw much of a conclusion from this because the vulnerability was caught before and after the update although the error report might indicate that it is handled in a different way. Whatever, it seems that the package can be passed as OK for 64-bits. Leaving this for comment though in view of comment #11.
In VirtualBox, M6, Mate, 32-bit Package(s) under test: php-smarty Using testing process used in: https://bugs.mageia.org/show_bug.cgi?id=22458 default install of php-smarty installs without error [root@localhost wilcal]# urpmi php-smarty Package php-smarty-3.1.21-3.1.mga6.noarch is already installed install php-smarty from updates_testing update installs without error [root@localhost wilcal]# urpmi php-smarty Package php-smarty-3.1.33-1.1.mga6.noarch is already installed
CC: (none) => wilcal.int
Whiteboard: (none) => MGA6-32-OK
In VirtualBox, M6, Mate, 64-bit Package(s) under test: php-smarty Using testing process used in: https://bugs.mageia.org/show_bug.cgi?id=22458 default install of php-smarty installs without error [root@localhost wilcal]# urpmi php-smarty Package php-smarty-3.1.21-3.1.mga6.noarch is already installed install php-smarty from updates_testing update installs without error [root@localhost wilcal]# urpmi php-smarty Package php-smarty-3.1.33-1.1.mga6.noarch is already installed
Keywords: (none) => validated_updateWhiteboard: MGA6-32-OK => MGA6-32-OK MGA6-32-OKCC: (none) => sysadmin-bugs
Either the thing causing the bogus requires should be patched out, the autogenerated requires should be filtered out, or something that provides it should be found. Adding a bogus provides isn't the right fix.
Keywords: validated_update => feedback
The requirement is fullfiled by the package itself. The file which is required by the autogenerator is in this package. Honestly, I don't know how this autogenration works and how this could be fixed. Since the package really provides this file, I think this is a possible solution. Btw. it seems to be fixed in mga7, since this requirement is not generated there.
The Wiki says how to filter out autogenerated requires. The file isn't provided by the package from the sense that if some other package required it that it'd be able to find it, if it was, the provides would have been automatically generated. If smarty itself is able to find the needed file, the requires that was generated is like a false positive. That happens sometimes. You just have to filter it out.
David: It would have helped me, if you'd just written, see %global __requires_exclude . pushed php-smarty-3.1.33-1.2.mga6.noarch.rpm, which uses this feature.
Marc, I'm on my cell phone and don't remember the exact syntax off the top of my head.
@David: sorry. But thanks for the advice.
Whiteboard: MGA6-32-OK MGA6-32-OK => MGA6-32-OK MGA6-64-OK
Found php-smarty-3.1.33-2.mga7.noarch.rpm on the mirror but only php-smarty-3.1.33-1.1.mga6.noarch.rpm for m6. This is on both the princeton and kernel.org mirrors. I also do not currently see php-smarty on https://pkgsubmit.mageia.org/ which goes back roughly 2 days. Marc, can you confirm the version submitted? Wilcal, which mirror did you use?
Removing the oks as the version from comment 18 is not on the mirrors.
Whiteboard: MGA6-32-OK MGA6-64-OK => (none)
I was quite sure I did, but I wasn't. But I did it now.
Update installs cleanly over the prior version. Advisory committed to svn. Will wait for wilcal to repeat his tests when he's ready.
Keywords: (none) => advisory
Updated to php-smarty-3.1.33-1.2.mga6 Checked the PoC example via localhost:8000 and confirmed that the exploit was caught in both cases. $smarty->display('eval:{fetch file="/etc/passwd"}'); [Fri Oct 5 00:42:53 2018] PHP Fatal error: Uncaught --> Smarty: Smarty Security: not trusted file path '/etc/passwd' <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 654 [Fri Oct 5 00:42:53 2018] 127.0.0.1:39712 [500]: /example.php - Uncaught --> Smarty: Smarty Security: not trusted file path '/etc/passwd' <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 654 $smarty->display('eval:{fetch file="'.addslashes(getcwd()).'/templates/../../../../../etc/passwd"}'); [Fri Oct 5 00:48:40 2018] PHP Fatal error: Uncaught --> Smarty: Smarty Security: not trusted file path '/home/lcl/dev/php/templates/../../../../../etc/passwd' <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 654 [Fri Oct 5 00:48:40 2018] 127.0.0.1:39794 [500]: /example.php - Uncaught --> Smarty: Smarty Security: not trusted file path '/home/lcl/dev/php/templates/../../../../../etc/passwd' <-- thrown in /usr/share/php/Smarty/sysplugins/smarty_security.php on line 654
openSUSE has issued an advisory on September 25: https://lists.opensuse.org/opensuse-updates/2018-09/msg00150.html It has a new CVE, but the referenced bug is for this one, so I'm not sure if it actually fixes anything new.
it is the same referenced CVE for both bug reports: CVE-2018-13982 so the are the same.
CVE: (none) => CVE-2018-13982
Sending this on. It has been hanging around long enough.
Whiteboard: (none) => MGA6-64-OK
Keywords: (none) => validated_updateCC: (none) => andrewsfarm
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0403.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
This update also fixed CVE-2018-16831: https://ubuntu.com/security/notices/USN-5348-1