[scintilla:bugs] #2389 SciTE automatic untrusted code execution via Lua
F8 is great
[bugs:#2389] SciTE automatic untrusted code execution via Lua
Status: open
Group: Bug
Labels: SciTE security
Created: Wed Jun 14, 2023 11:42 PM UTC by F8 is great
Last Updated: Wed Jun 14, 2023 11:42 PM UTC
Owner: nobody
Attachments:
- proof_of_concept_scite_lua_startup_win_v1.zip (752 Bytes; application/x-zip-compressed)
Hello.
I would like to raise what I believe to be another a security issue, regarding SciTE execution of arbitrary code based on malicious local properties files.
By setting "ext.lua.startup.script" in a local properties file, I have been successfully able to:
* Read and write arbitrary files
* Run arbitrary commands
... when files are opened in SciTE.
This is unsafe in scenarios where a folder contains content that the user did not themselves create, such as:
- The user opens a file in a folder shared with other users.
- The user opens a text file from repositories like SourceForge, GitHub, NPM, or CPAN.
- The user opens a text file from archives downloaded from the internet (even if the content is not related to coding).
- The user opens a text file from co-workers they would normally trust, but who themselves may have fallen victim to this or similar attacks.
Proof of concept
Pleased see attached file "proof_of_concept_scite_lua_startup_win_v1.zip" which demonstrates this issue, although please note I accept no liability for any damage or loss resulting from this code.
This windows-oriented example demonstrates both file creation and command execution, by creating text files with a "bad_" prefix as a record of the automatic command execution.
Notes regarding this proof-of-concept
I have been able to trigger this issue when both:
* Property "ext.lua.reset=1" is also defined in the local properties file.
* SciTE is registered as the default text file editor, and a file is double-clicked.
I suspect other scenarios may be possible, but I have not confirmed this.
Suggested fixes
I suspect there are many possible ways to address these issues, such as:
- Remove the "os" and "io" Lua standard libraries from SciTE.
- If "os" is problematic to remove altogether, remove function "os.execute", and consider also removing the "db" debug library.
- Please note that the "io" library also allows arbitrary code execution (as well as file access), via function "io.popen"
- Prevent properties that lead to code execution begin read from Local or Directory properties files.
- I have investigated trying to activate a Lua-based lexer from a local properties file, but I have not yet been successful.
- Implement some kind of sandbox around the Lua engine
- Disable the Lua extension engine by default, unless enabled by properties outside of Local and Directory properties files.
- Disable the Lua extension in the default build scripts, similar to build variable NO_LUA, but allow it to be conditionally compiled in if required (or distribute SciTE both with and without Lua enabled)
- (Drastic) Remove the Lua extension engine altogether.
- (Drastic) Remove the extension API altogether.
If extension hooks remain active in the codebase to some degree, I would ideally suggest implementing as several protections, for maximum user safety against this and similar issues yet to be discovered.
Visibility
I would suggest that this issue should remain private until a fixed build is made available, in order to minimize the risk to users, but this is of course at the discretion of the project maintainers.
See also
- SciTE bug #2387, which covers malicious use of "command.discover.properties" from a local properties file.
Thanks
Once again, thank you very much for your time and efforts.
Sent from sourceforge.net because scintill...@googlegroups.com is subscribed to https://sourceforge.net/p/scintilla/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/scintilla/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Neil Hodgson
- private: Yes --> No
- Comment:
Please stop using the private or priority settings.
This is an open source project and issues should generally be published. The priority indicates implementation priority which is only relevant to maintainers with 1 meaning extreme low priority that will never be progressed.
Allowing per-directory scripts is a deliberate feature that should be enabled by default. Its possible that there could be an option in user properties to allow users to disable scripting if they want.
F8 is great
Please accept my apologies regarding the priority and visibility.
My intention is not to be annoying; allow me to explain.
These kinds of code execution issues can be extremely serious.
Because code execution flaws allows attackers full access to that machine as the logged-in user, the potential for extremely nasty outcomes is very significant, including:
- The attacker gains access to the victims email, potentially allowing malicious account password resets
- The attacker gains access to secrets like SSH keys and stored passwords, which can be used for other attacks, including pushing malware to other projects.
- The attacker can access extremely personal information, such as private photos, videos, and personal documentation.
- The attacker can steal any cryptocurrency whose keys are on the machine.
- The attacker can drop ransomware.
I would recommend that every user of an unpatched build of SciTE should be extremely cautious, and may need to stop using the app until updated builds can be installed.
This is why the usual approach would be to treat code execution security issues as a higher priority class than other defects, and should not generally be disclosed to the public at large until fixes are made available.
This is why I do not feel comfortable reporting security issues as initially public - I am aiming for "responsible disclosure", rather than "zero-day", and so giving the project maintainers control.
However, I do respect that ultimately this is your project, and you are free to take any approach you deem appropriate.
I hope this explains why I am submitting tickets the way that I have, and I would urge you to re-consider.
[bugs:#2389] SciTE automatic untrusted code execution via Lua
Status: open
Group: Bug
Labels: SciTE security
Created: Wed Jun 14, 2023 11:42 PM UTC by F8 is great
Last Updated: Thu Jun 15, 2023 01:50 AM UTC
Owner: nobody
Attachments:
Neil Hodgson
SciTE is implemented by a community, not just an individual. There are 446 credited authors. A private bug is visible to only 7 people, most of whom will not be interested in any particular issue. I didn't implement scripting and use only basic scripting features.
Changes made here may cause failures in currently working techniques and should be disclosed to impacted users before being made. That allows negotiations to minimize problems. The best way to communicate with many (but not a majority of) users is to write to the mailing list.
https://groups.google.com/g/scite-interest
[bugs:#2389] SciTE automatic untrusted code execution via Lua
Status: open
Group: Bug
Labels: SciTE security
Created: Wed Jun 14, 2023 11:42 PM UTC by F8 is great
Last Updated: Thu Jun 15, 2023 09:43 AM UTC
Owner: nobody
Attachments:
Neil Hodgson
Fixed with [fdc77a].
[bugs:#2389] SciTE automatic untrusted code execution via Lua
Status: open
Group: Bug
Labels: SciTE security
Created: Wed Jun 14, 2023 11:42 PM UTC by F8 is great
Last Updated: Sat Jun 17, 2023 11:46 AM UTC
Owner: nobody
Attachments:
- proof_of_concept_scite_lua_startup_win_v1.zip (sourceforge.net) (752 Bytes; application/x-zip-compressed)
Hello.
I would like to raise what I believe to be another a security issue, regarding SciTE execution of arbitrary code based on malicious local properties files.
By setting "ext.lua.startup.script" in a local properties file, I have been successfully able to:
- Read and write arbitrary files
- Run arbitrary commands
... when files are opened in SciTE.
This is unsafe in scenarios where a folder contains content that the user did not themselves create, such as:
- The user opens a file in a folder shared with other users.
- The user opens a text file from repositories like SourceForge, GitHub, NPM, or CPAN.
- The user opens a text file from archives downloaded from the internet (even if the content is not related to coding).
- The user opens a text file from co-workers they would normally trust, but who themselves may have fallen victim to this or similar attacks.
Proof of concept
Pleased see attached file "proof_of_concept_scite_lua_startup_win_v1.zip" which demonstrates this issue, although please note I accept no liability for any damage or loss resulting from this code.
This windows-oriented example demonstrates both file creation and command execution, by creating text files with a "bad_" prefix as a record of the automatic command execution.
Notes regarding this proof-of-concept
I have been able to trigger this issue when both:
- Property "ext.lua.reset=1" is also defined in the local properties file.
- SciTE is registered as the default text file editor, and a file is double-clicked.
I suspect other scenarios may be possible, but I have not confirmed this.
Neil Hodgson
- status: open --> closed-fixed
[bugs:#2389] SciTE automatic untrusted code execution via Lua
Status: closed-fixed
Group: Bug
Labels: SciTE security
Created: Wed Jun 14, 2023 11:42 PM UTC by F8 is great
Last Updated: Mon Jul 06, 2026 01:43 AM UTC
Owner: nobody
Attachments:
- proof_of_concept_scite_lua_startup_win_v1.zip (sourceforge.net) (752 Bytes; application/x-zip-compressed)
Hello.
I would like to raise what I believe to be another a security issue, regarding SciTE execution of arbitrary code based on malicious local properties files.
By setting "ext.lua.startup.script" in a local properties file, I have been successfully able to:
- Read and write arbitrary files
- Run arbitrary commands
... when files are opened in SciTE.
This is unsafe in scenarios where a folder contains content that the user did not themselves create, such as:
- The user opens a file in a folder shared with other users.
- The user opens a text file from repositories like SourceForge, GitHub, NPM, or CPAN.
- The user opens a text file from archives downloaded from the internet (even if the content is not related to coding).
- The user opens a text file from co-workers they would normally trust, but who themselves may have fallen victim to this or similar attacks.
Proof of concept
Pleased see attached file "proof_of_concept_scite_lua_startup_win_v1.zip" which demonstrates this issue, although please note I accept no liability for any damage or loss resulting from this code.
This windows-oriented example demonstrates both file creation and command execution, by creating text files with a "bad_" prefix as a record of the automatic command execution.
Notes regarding this proof-of-concept
I have been able to trigger this issue when both:
- Property "ext.lua.reset=1" is also defined in the local properties file.
- SciTE is registered as the default text file editor, and a file is double-clicked.
I suspect other scenarios may be possible, but I have not confirmed this.