I can't check right now, but I think it was mentioned that Sandboxie doesn't use ASLR by default.

Any plans on changing this?

I like HungryMan's suggestion.

lol what the hell happened in here?

ASLR is inthe OS... all he has to do is turn it on.

Thank you tzuk, I appreciate you looking into this.

Also... holy moly at the links you posted.

An exploit that needs ROP gadgets and a single exploit that bypassed Chrome's sandbox.

Yes, clearly DEP and ASLR are useless


It depends how much has to be changed. If some part of the code has to be rewritten it may be worth it.

ASLR is definitely a nice feature to have.

Tzuk, curious to see if you've tried this.

Not yet. When I do get around to it, I will post an update here.

Sounds good - thanks.

Just curious if any progress has been made here. Still running Sandboxie on one of my computers. I use EMET, which forces ASLR (by reserving the address space before Sandboxie) and I've had no problems with Sandboxie in case that helps. It's not that much of an issue since I can do this but natively compiled ASLR >>>>>> mandatory ASLR.

The earlier mention of actually highlights the issue perfectly - that a single DLL not supporting ASLR is enough to create ROP and bypass DEP/ASLR entirely.

Hungry Man,

I seem to keep running into you all over the internet. You should consider taking a vacation from your computer.

Anyway I just popped in to say that you can add support for DEP/ASLR yourself in almost any application or library. The 'support for ASLR' is nothing more than a single bit and you can change this on any dynamic link library or executable yourself. There is a Microsoft tool for doing this called editbin.exe that is distributed with Visual Studio and Platform/Microsoft SDK.

The commandline for adding DEP support would be: editbin /NXCOMPAT YourExe.EXE
The commandline for adding ASLR support would be: editbin /DYNAMICBASE YourExe.EXE

Note: This will cause the binaries to no longer match the digital signature... I have not tested to see if SandBoxie verifies and refuses to load modified files. If Sandboxie verifies the digital signatures then unfortunately you will need to wait

I also posted this message for tsuk; because if SbieCtrl.exe is compiled with an older compiler that does not support ASLR then you can use editbin distributed with the Platform SDK and put the above into a 'Post-Build Step' before using signtool.

Best Wishes,
-MessageBoxA

Regarding progress with this. I don't feel any urgency to implement this feature, because I don't think any half-decent malware writer would craft an exploit against SbieDll. For starters, very few people in the world have SbieDll. On top of that, ASLR exploits rely on specific builds of specific DLLs, and SbieDll gets recompiled with every release of Sandboxie, so crafting an exploit against a specific version of SbieDll further reduces any effectivety of the exploit. Finally, there are known techniques for bypassing ASLR when targetting Windows DLLs, so who would waste their time targetting SbieDll.

Nevertheless people seem to be concerned, so I said I wouldn't mind adding ASLR at some point. But it turns out you can't limit ASLR to select a random DLL address in the lower 2GB of the address space. And for various reasons, SbieDll needs to be loaded in the lower 2GB of the address space. So this means that I can turn on the ASLR bit in the 32-bit SbieDll, but not in the 64-bit DLL. For the 64-bit DLL, I would have to rework SbieDll a bit, so it can load in the higher addresses. And test this change.

So to bring the two paragraphs together: The reason I didn't yet add ASLR is because it requires some work; the reason I haven't done this work yet is because I think use of Sandboxie is not widespread enough to justify any urgency with this issue.

And in case anyone thinks I'm being cavalier with security, ASLR exploits are not going to be able to break the sandbox barrier.

@MessageBoxA,

Thanks for the information. I know you can do this with DEP, I wasn't aware about ASLR.

@Tzuk,


Outside of fixed address areas in the OS I don't know of any methods to bypass properly implemented ASLR (besides brute forcing/ heap spray and assuming proper DEP.)

I get that sandboxie hasn't been targeted and this is therefor not a priority. I agree that it isn't urgent. I just wanted to check in.[/quote]

Yes, with regard to buffer overflow exploits, I remember doing some testing about 1-2 years ago and was pleased to see Sandboxie containing the "exploit".

I found a web site that says otherwise, that was good enough for me. But check out tutorial number 6.

http://www.corelan.be:8800/index.php/2009/09/21/exploit-writing-tutorial-part-6-bypassing-stack-cookies-safeseh-hw-dep-and-aslr/

A great article though it was originally hosted elsewhere I believe. The author may have spread it around himself... though I doubt it. This actually could very well be the original host lol but that's not really relevant. Regardless, I've read it and it's really a great piece of work, as are the other tutorials (, which incidentally really prove how insanely difficult it is to bypass these techniques when you layer them, and he doesn't even cover all mitigation techniques.)

Ughhhh assembly lol what a pain.

They bring up this great exploit, which is both an ASLR and potentially a /GS stack cookie bypass (/gs is not applied to structs, so I wouldn't consider it one honestly.)

Sandboxie is written in C and C++ or just C++? Structs are nice but, depending on the code, outclassed (unintential pun) by classes, which would get the stack cookie (I believe, and assuming /GS.) This isn't super relevant.

I'm interested in the ASLR only randomizing the top two areas. I'm guessing that this has to do with top-up allocation of the heap whereas the stack is top down? This was a stack overflow, afterall, but that wouldn't really make too much sense. I don't know enough about how ASLR is implemented here. I'm probably way off on that guess but too tired to try to figure out more.

Anyways, as with just about all ASLR issues it's an issue of implementation (or rather, if the design goal of ASLR is to randomize things, it is clearly bein implemented in a way that is not achieving this inherent goal) - in this case it's likely Microsoft's fault, and therefor really not your job to fix. Only you can analyze the code and decide if ASLR is worth it, I wouldn't even begin to presume to know how you've designed the program or whether stack cookies would mitigate this potential (and I think it's fair to call it limited, due to the fact tahty ou can only overwrite a limited set of bytes, there is a bit of guesswork* and it also relies on specific gadgets) technique. It's also worth noting that things have changed since Vista and that making use of other techniques would probably make this attack infeasible.

The other two bypasses have to do with modules that are fixed. "using an address from a non-ASLR enabled module" "ASLR Bypass : SEH based exploits

In case of SEH based exploit, the basic technique is the same. Find modules that are not aslr protected, find an address that does what you want it to do, and sploit… Let’s pretend that we need to bypass safeseh as well, for the phun of it." "Possible jump addresses could be :"



*without safeseh/sehop you can bruteforce this indefinitely, with either of them I would assume that this would be taken care of but I'm not sure