hmm, I don’t dare to run that test. Someone from security testing group want to confirm this?
Were did you find the test ? :o And are you running version 3.8? As 3.5 don’t have buffer overflow protection built in
Well, I saw that, but still you have to confirm stuff as sometimes people make the wrong when testing, its not uncommon, and just recently it was a debate over CIS interception of conflicer worm, that It only poped up once even at proactive according to the tread creator, the debate was on for several pages, until it was clear that he did the testing wrong, he had an allow rule for all dll files for instance. So since I don’t know DarthTrader I had to ask. But guess he did the testing good then, when you can confirm this too…
To pass this test, you need to block all requests to start the test modules, but allow the requests to terminate them.
Randomization tests must be allowed and ‘Crash.exe’ be allowed to run.
This will result in 100% results with this testing program.
(I ran it several times last night to determine what was actually going on to allow CIS to pass the test).
If you block or allow everything, the testing program fails.
Good pointing out there John. testing error, yummy.
Guess some stuff needs to be allowed while others need blocking for the test to do its thing and get the proper values. Blocking more should absolutely not result in any added security risk.
CIS handles this exceptional! (:HUG) (:HUG)
Hope we won’t see more of these dummy tests, if so I hope they come with a manual, “allow this and that, this is only supposed to test blocking against this, other things such as forbidding the program to open something.exe will make the testing think it fooled the security mechanism and result in a wrong testing result”
=== Vista-Probe regression test-suite results ===
Host: JOHN-PC
Windows version: Microsoft Windows NT 6.0.6001 Service Pack 1
Vista Probe version: 1.2.0.0
DEP policy: Can’t verify DEP policy.
=== Address Space Layout Randomization (ASLR) tests ===
Heap randomization 10 bits (guessed)
Stack randomization: No randomization
DLL base randomization: No randomization
EXE base randomization: No randomization
++ Memory corruption and permissions enforcement tests ++
Executable heap: Not vulnerable
Executable stack: Not vulnerable
Executable bss segment: Not vulnerable
Executable data segment: Not vulnerable
Executable DLL bss segment: Not vulnerable
Executable DLL data segment: Not vulnerable
→ Using VirtualProtect() tricks (change memory permissions)
(This tests show if REAL memory permission enforcement is in place)
Executable heap: Not vulnerable
Executable stack: Not vulnerable
Executable bss segment: Not vulnerable
Executable data segment: Not vulnerable
Executable DLL bss segment: Not vulnerable
Executable DLL data segment: Not vulnerable
Executable mapping: Not vulnerable
(Non-file mapping, though files can be mapped with execute permission
for evading DEP, basically that’s the method used here)
=== Secure CRT (/GS) related functions and other tests ===
GS Canary randomization No randomization
Return-to-function: Not vulnerable
(using CopyMemory())
On virtualization software: Native machine.
Note - my hardware does not support DEP, but Windows has it and monitors the system.
Heap randomization is just a guess, as the test reported 6 bits the first time I ran it.
Great job, Comodo.
