64-bit systems and anti-malware software

User-mode hooks are not fine- they are weak. And if you are going to build PrevX x64 with it- poor users who will rely on such the "defense"...

 

Prevx x64 has 0 usermode hooks - feel free to check for yourself. You and tzuk are misreading my post.

 

If you would be so kind as to enlighten all of us and Microsoft on what flaw you've discovered in Windows' access management, that would be useful

I disagree - a program is not malicious if it only reads screen contents. If it tried to then email them somewhere or other nefarious actions, then it would be malicious but you will be telling a lot of blind users that they can't use their PCs anymore.

This is the flaw in leaktests and why developers shouldn't spend time adding protection for leaktests - they don't represent real threats.

 

I need to stop being anecdotal I'm not suggesting that Sandboxie or any other software uses usermode hooks on 64bit. It is possible to block leaktest with usermode 64bit hooks but not real malware.

If Sandboxie only used usermode hooks, no one would ever use it because it would be flawed conceptually.

 

ZwMakeTemporaryObject.

 

You definitely do not understand the sandbox ideology. Sad.

 

Today it's a leaktest, tomorrow it's a trojan in the wild. Not good enough! Anti-viruses can afford to have this attitude because they're not primarily behavior blockers, and in any case, failing is built into the concept: Either they identify the virus or they don't. Front-line security software like Sandboxie doesn't have this luxury.

YES!

Thank you. That's exactly my point. I can't implement some things except as user-mode hooks, and I won't implement them as user-mode hooks because that would be a false sense of security.

You asked earlier about an example of missing functionality. There's a bunch of kernel services for connecting processes via LPC ports. Where are the kernel interfaces to supervise this?

 

What is the threat of a program reading the screen if it can't do anything with it? In my opinion, a program that just reads screen contents and shows them back on screen to the user is not malicious - screen savers do this, screen readers, screen magnifiers, user-initiated screenshot programs, etc. etc.

Unfortunately I can't do your work for you. It is possible, that's all I can say.

 

Thank you for another personal attack akin to your previous one insulting my intelligence after swearing at me in another thread. I will continue to not use personal attacks.

My same comment applies here: "What is the threat of a program reading the screen if it can't do anything with it? In my opinion, a program that just reads screen contents and shows them back on screen to the user is not malicious - screen savers do this, screen readers, screen magnifiers, user-initiated screenshot programs, etc. etc."

I agree with sandboxing a program from the harddisk/internet/registry/OS/etc. but if you really want to have a secure sandbox and you consider echoing screen contents back on the screen to be malicious, wouldn't drawing on the screen be equally malicious?

What does your sandbox do if a program tries to draw all across the screen, potentially preventing the user from working? Is Photoshop malicious because it has an eye-dropper function which lets you get a pixel from the screen and then it draws on the screen as well?

 

I'll leave it to Ilya to debate the technical details with you, as I'm not familiar with clipboard protection.

But it seems to me that you're arguing that Ilya's approach of stopping a clipboard attack at the source (the moment when clipboard contents are copied) is the same as your approach of trying to guess, at the time of use, whether the pasted contents came from the clipboard.

Clearly, it's not the same.

Well, that's convenient. When I say there's missing functionality, you don't think twice before injecting doubt into the discussion by listing a long list of available kernel interfaces and asking (in so many words) what could I possibly be missing. Then I tell you what I'm missing, and you just blow it off. Nice.

 

We're primarily discussing the reading of screen contents (i.e. graphical screen contents from BitBlt/StretchBlt/etc.)

Not trying to blow it off, but don't think you HAVE to be in kernel mode for everything. While you can't prevent a program in the sandbox from following a usermode hook, a LPC calls a local function in another process. I'll leave you to fill in the blanks

 

It's irrelevant - it can be easily blocked with a simply privilege check as I suggested (callers need at least the DELETE privilege on the handle AFAIK).

 

Absolutely. Other things besides facts are being revealed in the exchanges I have read on this thread...

 

I agree with reading the screen primarily being a privacy issue (and reading the registry is probably even more of an issue - hadn't thought of that one ) but the privacy implications occur only if the program was to try and save that data to the disk or email it out or transmit it elsewhere. If you have a program which merely shows you what is on your screen or in your registry and then does nothing with it, I don't see how that could possibly be seen as malicious.

 

Mr. PrevxHelp instead "teaching" developers who are in business for years about concept of their protection, I suggest you to go to your marketing department and tell them that your prog. needs real trial mode and not rouge like false notification unlimited trial...

 

This isn't relevant to this discussion but feel free to post in our forum: https://www.wilderssecurity.com/forumdisplay.php?f=104

 

That's creative thinking indeed. I have to admit, it is a very amusing thought -- in a good way.

Alright, I take back what I said in my last post. I think this could work, but I'd be very uncomfortable with it. One of the things that is important to me with Sandboxie is to not interfere with programs running outside its supervision. Your idea requires injecting code into every un-sandboxed process in the system, including system processes, and that might trigger a barrage of warnings by other security software in the system, and who knows what other conflicts.

But I have to agree, you said that it should be possible, and your idea seems like it might be possible. And I guess I never said that you can't suggest crazy ideas.

 

It also may be worth mentioning that running from SSDT hooks or other means within the kernel that Sandboxie currently uses is still running yourself inside the context of each process across the system so there is technically little to no difference between the potential for conflicts (probably even less because it is hard[er] to bring down the entire system from usermode alone if there was a bug in the implementation).

 

As there seems to be some resolution between the developers, I will now throw in my useless uninformed opinion with the others...

Microsoft has been hardening security since Windows 2003 and XP SP1.
I find it hard to believe that given Microsoft's steady increase in securing their OSes, and the hundreds of mathematicians and computer scientists at their disposal all over the world, that they would make x64 inherently less secure than x32.

Has any of these solo developers been involved in creating an OS, that they can be critical of OS design decisions?

 

It's really interesting to see how developers of several programs discuss the potential of proactive anti-malware.

Well, I don't know how the Kaspersky x64 sandbox works in detail but it's using usermode hooks for sure. And if I didn't look over something here still my question if there is anything like safe user mode hooks is still not treated. Until I see a program that really jumps out of the sandbox what means that it writes to the real file system or the real registry I don't believe it that it's "totally insecure". The x64 HIPSes of Outpost and Kaspersky can also intercept window messages, dll injections, global hooks (KIS just partially) and several other process modifications.

So please answer if you know a possible method or if you have an idea: Is it possible to make non ring 0 hooks (almost) unhookable due to their protection?
Thank you, tzuk and PrevxHelp

 

IMO a sandbox can be considered as essentially an "OS within an OS".
Microsoft doesn't want an OS environment created in their OS, for reasons I can only speculate.

Therefore sandboxing is a great idea, but ultimately destined for extinction.
Unfortunate, since the technology was just about ready for primetime.

 

I'm going to try and not get too technical while explaining something very technical The problem with ring 3 (usermode) hooks over the target process is that they only prevent access to system functions if the author of the hooked program is not intentionally avoiding the hooked functions.

For example, if you have a hook over the import of CreateFileA(), a process can dynamically import that function using a call like GetProcAddress(). If you then hook GetProcAddress() to re-hook any attempts to circumvent the import hook, they can get one layer lower and use LdrGetProcedureAddress(). If you try hooking that, they could write their own export parser and get the function on their own.

An alternate strategy to this would be to use a trampoline/detour method which actually overwrites the code of the function-to-be-hooked so that regardless of how the function itself is obtained, the hook code will be called. However, even if you apply a detour hook over CreateFileA(), a process could use CreateFileW() to write and it would circumvent the hook. To solve this, you can go a level lower and hook NtCreateFile(), but then a process can go one level lower and skip the NtCreateFile() all together and just directly call "function 0x3C" (the service number of NtCreateFile on Vista SP2) through the SYSENTER/INT 2Eh instruction (which is the barrier between usermode and kernelmode).

NtCreateFile exists in ntdll.dll and ntdll.dll is mostly just an ease-of-use wrapper around calls to ntoskrnl.exe which actually performs the specified function. Any sane software developer is going to use CreateFileA/W() or, for specific system-level developers, maybe they'll venture into NtCreateFile() but each level lower creates an added barrage of complexity.

Going down all the way to 0x3C thru SYSENTER produces massive headaches for any developer looking for cross-platform support (the "0x3C" changes between each OS version, service pack, and sometimes between hotfixes). However, malware authors generally don't care about mass-portability so they try and get as low as possible and using 0x3C/SYSENTER from usermode gets past any usermode hook.

Therefore, when working within the local process, it is not possible to prevent an application from circumventing your usermode hooks unless you're emulating the process' instructions and intercepting the execution of it (which dramatically impacts the performance).

However, by sitting in kernel mode, it is possible to still provide adequate protection because even though it is possible to call 0x3C directly to circumvent usermode protection, kernel mode hooks will still definitely be called (as the barrier prevents processes from directly calling kernel functions).

Ironically, malware authors cast even more suspicion on themselves when using a direct 0x3C call and this can be additionally used to heuristically identify threats or generically block specific operations so while it can be useful to bypass certain systems, it is a double-edged sword

Hope that helps!

 

I think there some small measure of difference between running a small piece of code in the context of each process, just small enough to ask "am I sandboxed" and bail if not;

And then your idea, which suggests actually modifying (the system DLL in) every process. So it's a different level of invasiveness into un-sandboxed processes. And if another HIPS in the system should choose to complain about this, could you really blame it?

I do think your idea is cool, as a solution to a puzzle, but I think as a real world solution, it is inappropriate. It's bending over backwards, don't you think?

I'm not prepared to put crazy hacks into Sandboxie just because Microsoft will not even consider additional kernel interfaces, unless one complains to leading tech web sites.

 

There are a number of optimizations/cross checks which can be done to limit the scope of potential problems but I do agree it would be marginally more invasive. Personally, I would be willing to put up with some additional hooks to be able to use Sandboxie or another security product.

I wouldn't blame them, but I doubt many HIPS are going to complain very loudly on usermode hooking like this, especially because Microsoft heavily uses shim libraries which hook using Detours to provide better compatibility for their software. And anyway, it is possible to hook in usermode without a HIPS product being aware of it if you do it from a driver

It is bending over backwards a little, but developers already should be pretty flexible so a back-bend shouldn't be too difficult if we're already doing flip-flops to accomplish most of what we do

All that Microsoft would have to do is extend some of their existing interfaces to make it easier to do some of these things. I suspect they will eventually make it easier to work with but right now it is probably a matter of getting obscure workarounds in place to get that critical last <1% of functionality supported.