I block direct disk, direct memory and driver install on my dangerous applications group. It does not stop anything from working.
What other things do you block in the dangerous applications profile? I am thinking of adopting the idea.
For a long time I have had direct disk, direct memory and driver install. This causes no problems apart from loads of false positives on disk access being logged.
I have recently tried process terminations and protected registry keys. IE 8 appears to need to terminate itself but blocking it makes no difference. Is this another false positive? IE 8 also tries to write to protected registry keys. This could be a problem. A better alternative could be to block all dangerous applications from writing to HKEY_LOCAL_MACHINE*. This would only make a difference as administrator. I might try this. Adding c:\windows* and c:\program files* to blocked files might be a good idea also for running as administrator. Well behaved programs should not write to any of these file locations or registry keys.
I have yet to try Microsoft office in the dangerous group. To test I have just added winword.exe and edited a document. No problems apart from direct disk access being logged. Managed to edit and save a document.
I believe that direct disk access via CPU interrupt calls would be rather dangerous if done by someone that does not take care.
Direct disk access would be: INT 13H - Wikipedia
As compared to the windows API call CreateFile etc which at some point will do some INT_13 interrupts. A program cannot gain any more permissions than it already has due to recent CPU’s and operating systems. The OS runs in protected mode which allows it to hook CPU interrupts.
As mentioned before the direct access could be used for rootkit detection, although I’m not sure if a rootkit can modify the operating systems behavior when certain interrupts are triggered.
Are you sure? INT 13 it taken over by windows so if you call it the call goes to windows instead. I always assumed direct disk access would involve using the windows disk driver directly.
Yes, INT 13 would be hooked by windows. I guess it’s probably a driver, as you mentioned that handles the hooked INT 13 call.
Either through Int 13 or the windows API, it all ends up at the same place. The windows API just creates a more human readable abstraction of the interrupt API (A few lines of C compared to many lines of assembly).
I think you’re oversimplifying things just a bit too much. Here’s how it goes:
kernel32!CreateFile > ntdll!NtCreateFile > ntoskrnl!NtCreateFile > ntoskrnl!IopCreateFile > … > ntfs!NtfsCreateNewFile > …
I think this is API file access (i.e. normal) not direct disk access.
I mean from the programmers perspective, writing a few lines of C (Which would call into CreateFile, as you indicated) to writing many lines of assembly using the interrupts directly (Direct disk access).
I think the problem is that CIS intercepts two things:
Direct disk read access – it seems a benign operation and is common so it causes so many Direct disk acess pop ups.
Direct disk write access – can be malicious or legit - it,s far less common and will give only few pop ups
What the developers do-- they should allow Direct disk read access by default( with option to intercept it ofcourse in advanced settings for power users) and intercept direct disk write access sending a pop up to the users.
I suggested it since long but no benefit.
Same way CIS File Defence architecture not good. File Defence should consist of:
File Read - allowed by default with no pop up( may be an option to intercept it for power users)
File Create/ Write - intercepted with a pop up
File Modify - intercepted with a pop up
File Delete - intercepted with a pop up
And another still long awaited feature request— Tray icon color change acording to HIPS/ FW status.
:o :o :o
There are many more wishes but IMO these are three most important and desired ones( atleast to me).
??? You can simply open \Device\Harddisk1 and write to it. Of course, there is int 13 but it’s not portable.
This is not the main problem. If you write a simple program to write to a file using windows API you get a pop-up for direct disk access. Blocking this pop-up does not stop reading or writing to the file. It is a false positive. I have written my own program to test this.
Interesting. Not sure if it,s true. I am not a programmer, just an ordinary user. They must fix it, for sure.
I hope they do fix it. I block direct disk access for loads of applications (including firefox, IE and microsoft office) and I get loads of attempts logged as blocked. It fills my log up but stops nothing from working.
I think u are misunderstanding. It might be blocking direct disk access infact without breaking any functionality. U need to test it properly.
With Comodo 32 bit I get a lot more direct disk acces pop ups than with comodo 64 bit.
Could it be that only 32 bit is affected?
I only have 32 bit.
Can you send me your program(s) to test it? If their handling is not too complicated 
I have just realized (I have tested with Process Monitor) my test program uses CreateFileMapping API call that may make the difference. A very simple program using just CreateFile, WriteFile and CloseHandle does not trigger defence+. Firefox also uses CreateFileMapping.
The CreateFileMapping returns error “file locked with only readers” which means only read access is allowed. I will investigate further.
On second thoughts CreateFileMapping may be a red herring. Enabling direct disk in defence+ for the test program makes no difference and the disk writing is done with CreateFile WriteFile and CloseHandle. I appears to trigger direct disk access in defence+ only some of the time. I can run the same program twice. The first time it triggers defence+ and the second time not. This does not appear to be defence+ learning. There is nothing in computer security policy and I am blocking everything.
CreateFileMapping is associated with the file reading.