Smarty 2.6.8 Released [21-March-2005] For those using template security: A vulnerability in the regex_replace modifier has been fixed that allowed PHP code to be executed from a template, even with template security enabled. If you are using template security features, it is highly recommended to upgrade, or at least replace the modifier plugin. A problem with the {strip}{/strip} tags (that was introduced in 2.6.7) has been fixed. Casting objects to arrays in the {foreach} "item" attribute has been addressed. ChangeLog: http://smarty.php.net/misc/NEWS download: http://smarty.php.net/download.php Reproducible: Always Steps to Reproduce: 1. 2. 3.
PHP team, please bump
dev-php/smarty-2.6.8 is in portage now.
Arches: please test and mark stable
Stable on SPARC.
Stable on x86 and amd64.
Stable on ppc.
Stable on hppa, thanks to KillerFox for testing.
Stable on alpha.
GLSA 200503-35
Smarty 2.6.9 has been released with some more security fixes, I'll add the ebuild soon.
will be released as an update to GLSA 200503-35
smarty{,-docs}-2.6.9 in cvs, stable on x86 and amd64. Arches please mark stable.
Alpha stable.
sparc done.
security: UPDATE draft sent, please approve
UPDATE sent
Just a note, this is a misleading bullitin (and showing up high in google results): http://www.gentoo.org/security/en/glsa/glsa-200503-35.xml The vulnerability does not open attacks from remote users, it only allows someone with direct access to template files to execute PHP commands from within the template. It would be good for someone to change that wording, thanks.
tomk/php-bugs/auditors please advise wether this is remotely exploitable.
(In reply to comment #19) > tomk/php-bugs/auditors please advise wether this is remotely exploitable. > According to the first entry in: http://smarty.php.net/index_archive.php it's not remotely exploitable. You need local access to the smarty template files to be able bypass certain checks when template security is enabled. That being said, when such a template has been created by a local user then the vulnerable code would be run when accessed remotely via the webserver. I'm unsure as to the criteria used to determine whether that is defined as being locally or remotely exploitable.
I defined it as remotely exploitable because smarty's "template security" feature is typically used to allow untrusted users to plug their own template in a PHP application (for example, a bulletin board that allows users to customize templates). The hole is that the "template security" feature can be bypassed to allow to execute arbitrary code while theorically this should not be possible for those users. In which case the hole is remote, because the attacker doesn't need to be a local user. I agree it's a little misleading to use the term "Remote attacker" everywhere, since the attack can only be remote if the application allows users to upload their own templates...
> I defined it as remotely exploitable because smarty's "template security" > feature is typically used to allow untrusted users to plug their own template > in a PHP application (for example, a bulletin board that allows users to > customize templates). yes, but generally, such PHP interfaces are reserved with an authentication device (at least, i hope so). Consequently, the potential attackers are not totally "unknown". This is remote but reserved for known members of a group. Well i think this doens't worth any update and we could close it.
I think we can close this bug now, please REOPEN if anyone disagrees.
