Bug 23592 - php-smarty new security issue CVE-2018-13982
Summary: php-smarty new security issue CVE-2018-13982
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard:
Keywords: advisory
Depends on:
Blocks:
 
Reported: 2018-09-18 13:45 CEST by David Walser
Modified: 2018-10-13 14:17 CEST (History)
7 users (show)

See Also:
Source RPM: php-smarty-3.1.32-1.mga7.src.rpm
CVE: CVE-2018-13982
Status comment:


Attachments

Description David Walser 2018-09-18 13:45:03 CEST
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.
David Walser 2018-09-18 13:45:11 CEST

Whiteboard: (none) => MGA6TOO

Marja Van Waes 2018-09-18 14:02:19 CEST

Assignee: bugsquad => php
CC: (none) => marja11

Marc Krämer 2018-09-18 14:15:20 CEST

CC: (none) => mageia
Assignee: php => mageia

Comment 1 Marc Krämer 2018-09-18 16:15:29 CEST
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

Comment 2 Thomas Backlund 2018-09-21 17:47:25 CEST
@Marc,

fyi, when the package is fixed in cauldron, assign the package to mga6 and remove the MGA6TOO

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

Comment 3 Marc Krämer 2018-09-21 19:20:02 CEST
ok, I'll remember it next time.
Comment 4 Dave Hodgins 2018-09-30 23:33:31 CEST
# 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

Dave Hodgins 2018-09-30 23:33:45 CEST

Keywords: (none) => feedback

Comment 5 Len Lawrence 2018-10-01 09:14:41 CEST
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

Comment 6 Thomas Backlund 2018-10-01 09:53:36 CEST
(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
Comment 7 Marc Krämer 2018-10-01 21:27:27 CEST
This Requirement is autogenerated. How do I suppress this?
The Spec does not have any Provides or Requires itself.
Comment 8 Dave Hodgins 2018-10-02 04:53:57 CEST
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.
Comment 9 Marc Krämer 2018-10-02 09:35:06 CEST
@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)

Comment 10 Len Lawrence 2018-10-02 20:39:53 CEST
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.
Comment 11 David Walser 2018-10-02 21:52:59 CEST
The last "fix" to the package was incorrect anyway.
Comment 12 Len Lawrence 2018-10-03 16:41:35 CEST
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.
Comment 13 William Kenney 2018-10-03 18:15:37 CEST
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

William Kenney 2018-10-03 18:16:10 CEST

Whiteboard: (none) => MGA6-32-OK

Comment 14 William Kenney 2018-10-03 18:30:30 CEST
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
William Kenney 2018-10-03 18:30:56 CEST

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: MGA6-32-OK => MGA6-32-OK MGA6-32-OK

Comment 15 David Walser 2018-10-03 18:33:39 CEST
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

Comment 16 Marc Krämer 2018-10-03 18:37:55 CEST
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.
Comment 17 David Walser 2018-10-03 19:07:43 CEST
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.
Comment 18 Marc Krämer 2018-10-03 21:45:40 CEST
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.
Comment 19 David Walser 2018-10-03 21:53:30 CEST
Marc, I'm on my cell phone and don't remember the exact syntax off the top of my head.

Keywords: feedback => (none)

Comment 20 Marc Krämer 2018-10-03 22:11:50 CEST
@David: sorry. But thanks for the advice.
William Kenney 2018-10-04 17:33:58 CEST

Whiteboard: MGA6-32-OK MGA6-32-OK => MGA6-32-OK MGA6-64-OK

Comment 21 Dave Hodgins 2018-10-04 19:32:14 CEST
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?
Comment 22 Dave Hodgins 2018-10-04 21:30:19 CEST
Removing the oks as the version from comment 18 is not on the mirrors.

Whiteboard: MGA6-32-OK MGA6-64-OK => (none)

Comment 23 Marc Krämer 2018-10-04 22:43:23 CEST
I was quite sure I did, but I wasn't. But I did it now.
Comment 24 Dave Hodgins 2018-10-05 00:12:06 CEST
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

Comment 25 Len Lawrence 2018-10-05 01:49:50 CEST
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
Comment 26 David Walser 2018-10-13 00:08:42 CEST
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.
Comment 27 Marc Krämer 2018-10-13 14:17:29 CEST
it is the same referenced CVE for both bug reports:
CVE-2018-13982
so the are the same.

CVE: (none) => CVE-2018-13982


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