> he attached patch will forbid some operations

You seem to have forgotten to attach it.

I've attached the patch the reporter has sent me by e-mail.

1) I can't add anything to ticket #54446, even if my password allows me
to read it, so I used security@
2) The ticket actually includes a test case and a patch
3) This is clearly a backwards incompatible change
4) You may decide to restrict READ_FILE and READ_NETWORK too
5) You may want to make this behavior configurable (accept nothing,
accept read-only, accept read/write)
6) Actually, it is trivial to get code execution on any PHP application
accepting untrusted XSLT
7) This bug will be publicly disclosed in June, and I hope that a patch
will be released before

This is basically a well known feature, you can write files with XSLT since "forever", it's IMHO perfectly in the boundaries of what it's supposed to do and not a "newly found security" hole.

But I guess even I didn't always clean untrusted XSLT properly for all the possible cases. That's why I think it's a good thing to disable write-access for XSLT by default. Not many are using that feature. I'll try to come up with something for added protection.

PS. We should disable write access for SQL by default, too, it's the same line of thought ;) </sarcasm>

Added a new patch with 2 new methods:

setSecurityPrefs and getSecurityPrefs

default is

 XSL_SECPREF_WRITE_FILE |  XSL_SECPREF_WRITE_NETWORK | XSL_SECPREF_CREATE_DIRECTORY;

please review

I just tested your patch against my test script and it successfully blocked the file creation attempt. Tested too the two configuration methods.

OK for me ...

I'll commit the page in the next few days. will be on holiday next week

When will the patch be committed ?

The patch should be committed soon. We have a problem for the 5.3 branch since it changes a struct and therefore breaks binary compatibility. I don't have a solution for that now.

Christian, can you commit it for 5.4+?

It's on my personal todo since weeks. I'll try to do it in the next few days (have to write a decent NEWS entry mainly)

This is now fixed in trunk and therefore 5.4

It's now als in the PHP 5.3.x branch (will be in 5.3.9). We couldn't use the same approach as in PHP 5.4 due to ABI compatibility problems. We had to introduce an ini option. Here's a code example, which works in 5.3 (actually anything >= 5.0) and 5.4 for writing from within XSLT. 


***
$xsl = new XSLTProcessor();

//if you want to write from within the XSLT
if (version_compare(PHP_VERSION,'5.4',"<")) {
    $oldval = ini_set("xsl.security_prefs",XSL_SECPREFS_NONE);
} else {
    $oldval = $xsl->setSecurityPreferences(XSL_SECPREFS_NONE);
}

$xsl->transformToXml(...);

//go back to the old setting. Better safe than sorry
if (version_compare(PHP_VERSION,'5.4',"<")) {
    ini_set("xsl.security_prefs",$oldval);
} else {
    $xsl->setSecurityPreferences($oldval);
    //or just do
    // $xsl = null;
    // to get away of this object
}

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Since the fix for this came through debian repos (today) i'm getting the error:
Warning: XSLTProcessor::transformToXml(): Can't set libxslt security properties, not doing transformation for security reasons