New properties to deny some untrusted code execution

[scintillaDotOrg]

Some new properties have been committed to SciTE to prevent some possible execution of untrusted code.

When some files are downloaded, perhaps a project from GitHub, there may be SciTE.properties files included to customize settings for those files. Some of these are minor like changing the set of keywords for a programming language or the colour of comments but some may have further ramifications.

SciTE.properties may set the Lua scripting file with ext.lua.startup.script which is automatically run. This has legitimate uses such as providing new commands for the downloaded files but may also read and write files or execute commands. Setting  ext.lua.startup.script in SciTE.properties will now be disabled unless allow.local.script is set to 1 in user or global options. allow.local.script also controls whether the extension.<filepattern> property may be set in SciTE.properties.

Script lexers may be implemented in Lua and accessed by specifying lexer.<filepattern>=script_<name> and this is now disabled unless allow.script.lexer is set to 1 in user or global options.

These features are rarely used so requiring an extra property setting is not a large burden.

The properties.local.enable property may be set to 0 to completely disable reading SciTE.properties files. This is a drastic reduction in SciTE capabilities but can be used in particularly security-conscious situations. This setting may evolve in the future with allow-lists or deny-lists for where local options files may be used.

While I haven't heard of any exploits that target SciTE.properties, other more popular editors have been targeted.

The committed changes can be examined either in the repositories

   hg clone http://hg.code.sf.net/p/scintilla/scite

or from

   https://www.scintilla.org/scite.zip Source
   https://www.scintilla.org/wscite.zip Windows executable (64-bit)

Neil

[Neil Hodgson]

Some more changes are being made to improve safety and precision when running commands from SciTE.

All properties files included with SciTE now quote path name variables in commands with double quotes so that paths that include spaces (as is common on Windows) or some other special characters work correctly.
For example,
command.build.*.tex=dvips -f $(FileName).dvi > $(FileName).ps
has changed to
command.build.*.tex=dvips -f "$(FileName).dvi" > "$(FileName).ps"

On Unix, it is possible to execute commands inside a string with the `command` or $(command) syntaxes. This can be exploited by distributing a file with a name containing an invocation like doesNot`doEvil`.c and hoping someone runs a compiler or linter on the file through a shell.

To prevent this, SciTE added an unsafe.path.characters property that can be set in user options. It currently defaults to `$\" on Unix and is empty on Windows. For any path that includes any of these characters, SciTE refuses to run commands through shell. Most people never use these characters in file names so this should have little impact but if you want to you can set unsafe.path.characters to empty.

It is also possible to perform Unix shell escaping on commands with the properties escape function like this:
command.go.*.py=py $(escape FileNameExt)
Escaping can be tricky to get just right in some circumstances and unsafe.path.characters is more robust so should be the default strategy here.