Please use the standard sandbox with high-risk vulnerability carefully! #4269
Replies: 8 comments 6 replies
-
|
Does the usage of start restrictions prevent this? "Allow only selected programs to start in this sandbox*", which sets Does adding |
Beta Was this translation helpful? Give feedback.
-
|
probably not, from the vague description it sounds to me as if its something similar to #1714 to fix it we just need to filter the problematic syscall, although I wonder why here EnableObjectFiltering=y does not help, or it was turned off, waiting for a PoC and more details. PS: Also a standard unprivileged user should not be able to inject LSASS.EXE if that works that it works outside the sandbox as well and that would be a very very bad windows bug. |
Beta Was this translation helpful? Give feedback.
-
|
What I can publicly disclose is that the system call used in this vulnerability is a completely normal and indispensable system call for some ordinary programs, but it uses some means to attack one of the system areas called behind the system call in the ring0 environment during the system call. Unfortunately, the level 1 reporter of this vulnerability is not willing to disclose the original sample, so there is no POC yet. Also, I'm sure the malicious program first used another vulnerability to elevate to administrator privileges before injecting lsass.exe, but even injecting other ordinary user programs can do a lot of damage, which is worth noting.
…---Original---
From: ***@***.***>
Date: Sat, Sep 28, 2024 01:51 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [sandboxie-plus/Sandboxie] Please use the standard sandbox withhigh-risk vulnerability carefully! (Discussion #4269)
probably not, from the vague description it sounds to me as if its something similar to #1714 to fix it we just need to filter the problematic syscall, although I wonder why here EnableObjectFiltering=y does not help, or it was turned off, waiting for a PoC and more details.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Injecting code into another (sandboxed) process running with the same security context is not a vulnerability. If a malicious program can open some process for full access, it's free to do with it whatever it wants, which is also Microsoft's position on that matter. So is there a sandbox escape or not? What exactly is the impact of running a malicious sample inside the standard sandbox? If not injecting code into LSASS, where does it allow injecting code? It's only a vulnerability if the answer includes unsandboxed processes. |
Beta Was this translation helpful? Give feedback.
-
You should know that Lsass.exe is not only an unsandboxed process,but also an unique critial system-privllage process! |
Beta Was this translation helpful? Give feedback.
-
Sure, but this did not seem to be the point. Does the vulnerability exist outside Sandboxie? (If so, then this is a Microsoft issue and, if Sandboxie can prevent it from being exploited in some cases, that is good news, while Windows being vulnerable is bad news.) Does the vulnerability rely on Sandboxie in any way? E.g. only something run inside a sandbox can trigger this. (Bad news for Sandboxie, if that is the case.) |
Beta Was this translation helpful? Give feedback.
-
|
So, simply blocking the system call exploited by this vulnerability is not reliable. Attackers can easily use another completely problem free system call to indirectly attack the system structure. Due to the forwarding feature of LowLevel, it can be said that all NT system calls will run with service privileges, so the damage caused by using system call evasion will even be much greater than running directly. If you don't want to completely solve it in a regular sandbox, at least give users of the regular sandbox a prominent reminder about the security threats that the regular sandbox has exposed, and guide them to use security enhanced sandboxes.
…---Original---
From: ***@***.***>
Date: Sat, Sep 28, 2024 01:51 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [sandboxie-plus/Sandboxie] Please use the standard sandbox withhigh-risk vulnerability carefully! (Discussion #4269)
probably not, from the vague description it sounds to me as if its something similar to #1714 to fix it we just need to filter the problematic syscall, although I wonder why here EnableObjectFiltering=y does not help, or it was turned off, waiting for a PoC and more details.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the additional information. The issue you're describing stems from exploiting vulnerabilities in the Windows kernel through a system call. These are fundamentally Windows bugs and fall under Microsoft's responsibility to address. Such vulnerabilities are not inherently caused by Sandboxie itself, and depending on the specifics of the exploit, they may not be easily mitigated within a sandbox environment. Fortunately, in this case, it seems mitigation is possible, but we can’t assume this will always be true for every Windows kernel exploit, even when invoked with a locked-down anonymous token. This is precisely why Sandboxie provides the SyscallLockDown=y option, which helps mitigate the majority of kernel-based exploits. However, enabling this option by default can lead to compatibility issues with certain applications, making automatic activation impractical. I believe that when users run something potentially suspicious, they should opt for the most secure environment—typically the red box—where security is the priority. Using a yellow box, on the other hand, generally indicates that the user is focused more on isolation and compartmentalization rather than absolute security. As for making this distinction clearer in the user interface, it's worth considering. We could potentially add a more prominent explanation in the first-time startup wizard or when creating a new sandbox to better guide users in making informed decisions about the security versus usability trade-off. I'm open to further suggestions on how to improve the user experience and ensure users are making educated choices when configuring their sandboxes. |
Beta Was this translation helpful? Give feedback.
-
|
According to the first reporter, the vulnerability can also be mitigated by enabling "DropAdmimRight" in the standard sandbox, but it has not been confirmed yet.
…---Original---
From: "Sebastian ***@***.***>
Date: Tue, Oct 1, 2024 00:30 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [sandboxie-plus/Sandboxie] Please use the standard sandbox withhigh-risk vulnerability carefully! (Discussion #4269)
Lsass.exe is not only an unsandboxed process,but also an unique critial system-privllage process!
Sure, but this did not seem to be the point.
Does the vulnerability exist outside Sandboxie? (If so, then this is a Microsoft issue and, if Sandboxie can prevent it from being exploited in some cases, that is good news, while Windows being vulnerable is bad news.)
Does the vulnerability rely on Sandboxie in any way? E.g. only something run inside a sandbox can trigger this. (Bad news for Sandboxie, if that is the case.)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
The initial reporter claimed that the essence of this vulnerability was to use syscall to bypass Sandboxie's hooks at the user layer and call unfiltered thread pool related functions to achieve injection purposes. Unlike the initial report, he claimed that injecting into lsass.exe requires an administrator token (although even a simulated administrator token can be used), but it can be confirmed that even without an administrator token, malicious programs can inject into other ordinary privileged processes through this method, and then indirectly control the system using other privilege escalation techniques outside the sandbox. Sandboxie played an important role in easing user concerns, as most people believe that granting administrator privileges is not dangerous as long as it runs in the sandbox.
…---Original---
From: "Sebastian ***@***.***>
Date: Tue, Oct 1, 2024 00:30 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [sandboxie-plus/Sandboxie] Please use the standard sandbox withhigh-risk vulnerability carefully! (Discussion #4269)
Lsass.exe is not only an unsandboxed process,but also an unique critial system-privllage process!
Sure, but this did not seem to be the point.
Does the vulnerability exist outside Sandboxie? (If so, then this is a Microsoft issue and, if Sandboxie can prevent it from being exploited in some cases, that is good news, while Windows being vulnerable is bad news.)
Does the vulnerability rely on Sandboxie in any way? E.g. only something run inside a sandbox can trigger this. (Bad news for Sandboxie, if that is the case.)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
You can directly search for the open-source repository of "thread pool injection" on Github to try testing it as a PoC. In fact, this injection method has been widely used, and it is difficult to determine whether many malicious programs have already infiltrated many systems with Sandboxie through this method.
…---Original---
From: "Sebastian ***@***.***>
Date: Tue, Oct 1, 2024 00:30 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [sandboxie-plus/Sandboxie] Please use the standard sandbox withhigh-risk vulnerability carefully! (Discussion #4269)
Lsass.exe is not only an unsandboxed process,but also an unique critial system-privllage process!
Sure, but this did not seem to be the point.
Does the vulnerability exist outside Sandboxie? (If so, then this is a Microsoft issue and, if Sandboxie can prevent it from being exploited in some cases, that is good news, while Windows being vulnerable is bad news.)
Does the vulnerability rely on Sandboxie in any way? E.g. only something run inside a sandbox can trigger this. (Bad news for Sandboxie, if that is the case.)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
If you're talking about PoolParty, it's not a vulnerability. The slides from the corresponding BlackHat talk make it clear that it's a detection bypass at maximum. Before injecting code, this technique requires opening the target process for |
Beta Was this translation helpful? Give feedback.
-
I have said basically in the standard sandbox, Sandboxie lets most syscall through without restricting token rights, and the sample uses Syscall instead of standard calls, the driver handling this syscall detects this behavior only by requiring administrator privileges to be injected into the system process. The driver level of Sandboxie for this sample uses syscall that is not currently filtered and can also be considered a vulnerability. |
Beta Was this translation helpful? Give feedback.
-
|
That is, the main idea behind this“Vulnerability” is to bypass Sandboxie‘s defense-centric hook with Syscall, and then use the unusual syscall approach to bypass the overt syscall that is being heavily defended, to perform dangerous behavior that is permitted by the system but not considered by Sandboxie. |
Beta Was this translation helpful? Give feedback.
-
A standard sandbox escape vulnerability that has been used in Trojans has been discovered, a malicious program can inject and control“LSASS.EXE” in the latest version of Sandboxie by running it in a standard sandbox with standard user privileges to take control of the user‘s system without the user’s knowledge. I have submitted a safety report on this, but I can not provide the technical details.
For all Sandboxie-Plus users, make sure SyscallLockDown is on when running unknown software in the sandbox, or use a security-enhanced sandbox to mitigate this vulnerability. If you can not use this option, it is recommended that you temporarily use the virtual machine test software. I also urge Sandboxie maintainers to delegate this option as soon as possible, or pop-up alerts when a user creates a standard sandbox, and turn this option on by default in the standard sandbox for users who have credittials.
Beta Was this translation helpful? Give feedback.
All reactions