A signed Squirrel binary can be used to execute untrusted code
See original GitHub issuehttps://techmonitor.ai/technology/cybersecurity/microsoft-teams-vulnerability etc.
Do we need to do anything about this? As long as we’re not allowing privilege elevation is it a problem?
What can be done to mitigate risks of executing untrusted code?
Check for a matching code signature before --processStart
?
Embedding update URL in Update.exe?
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (6 by maintainers)
Top Results From Across the Web
Codesigning error, it is trying to sign a binary file that is ...
Squirrel version(s) 2.0.1 Description I'm using a lib that divides it's binary file into 3 files, the first one gets signed fine, ...
Read more >r/netsec - Code execution using Microsoft Teams binaries
This is a LoL technique and can be used for application whitelist bypassing. This is a red team technique, not a true "vulnerability"....
Read more >Squirrel Sandbox Escape allows Code Execution in ...
It enables an attacker to bypass the sandbox restrictions and execute arbitrary code within a SquirrelVM, giving the attacker full access to the ......
Read more >ldd(1) and untrusted binaries - Julio Merino (jmmv.dev)
ldd uses the dynamic linker to load the binary and its dependencies into memory, and then relies on the dynamic linker itself to...
Read more >Building a secure/sandboxed environment for executing ...
The application of sandbox is obvious, you can execute the code which you don't trust without worrying about security much.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Some thoughts on certificate validation. Policy. It might be nice with some choice since use cases might differ.
If I remember correctly for clickonce you can change certificate to any new certificate as long as you don’t change anything else (name/url).
Different possible certificate check policies:
Other thoughts:
Not one hundred percent secure but at least as an additional validation: Maybe we can check if the common name (CN) of the update nuget package’s signature is the same as the one of the signed update.exe? That would at least allow to replace the certificate if it expires …