D

Deleted member 65228

I also noticed that OSArmor blocks file execution at the earlier stage than ReHIPS. It looks like ReHIPS first allows execution and then suspends it (waiting for the user's action). That is not a good way to block files.
I recon they will use the same kernel-mode callback that OSArmor uses. If multiple drivers register the callback, only one drivers callback routine is triggered at a time. If I make 3 drivers which all register PsSetCreateProcessNotifyRoutineEx, only one at a time will receive the notification. So the second driver may receive the notification first, then the first driver after the thread for the callback routine for the first notified callback routine has ended.

They likely suspend it so they don't have to hold up the thread for the callback routine, so the thread ends and the execution was successful, except the new process is in a suspended state and doesn't get to execute any code until the users request deems it to be allowed to be executed. Which is actually not a bad idea at all because Microsoft advise against holding up the callback routine threads in kernel-mode.

This is assuming ReHIPS does use the common and documented and secure kernel-mode approach with PsSetCreateProcessNotifyRoutine/Ex/Ex2 for process start-up interception. Especially considering they claim not to use rootkit-like techniques like API hooking, so kernel-mode callbacks are a good bet for them to use.
 
D

Deleted member 65228

As an addition though, the process suspension thing may also be a potential vulnerability. Unless they are guarding the process starting up from being accessed by external sources until the user responds to the request. Otherwise, an attacker who already is executing code can start up a process which is pending execution by being suspended until the alert has been responded to, can just resume the process with NtResumeProcess. Lol

So if ReHIPS do what Andy says, better make sure they protect the pending execution process. Unlike when you wait to change the CreateInfo->CreationStatus instead of allowing but suspended, then it is indeed more secure by default as you don't have to worry about guarding the suspended process temporarily
 

Andy Ful

Level 60
Verified
Trusted
Content Creator
I did not make a research about ReHIPS behavior. But, when I run EagleGet downloader (as a payload from the VBS script), I can see the EagleGet program window when it is suspended by ReHIPS. So, many bad things can be done by malware in the short time between process start and process suspend events. When I do the same under the OSArmor, the EagleGet program window is not shown.
.
Edit
After @Opcode comments I repeated the test. Sadly, I could not replicate the above results. So, the result is invalid. See, also:
NoVirusThanks OSArmor
 
Last edited:
D

Deleted member 65228

So, many bad things can be done by malware in the short time between process start and process suspend events
Edit: Removed.

Hmmm. Well if the program actually properly starts up before its suspended then that is stupid in my opinion but who knows maybe ask them why they did that, I'm not sure

I thought you meant it was suspended before the main thread was resumed and the program could execute its own code, but seems like you are saying that it is suspended after the main thread had already been resumed by the Windows Loader which is indeed silly
 

Andy Ful

Level 60
Verified
Trusted
Content Creator
Edit: Removed.

Hmmm. Well if the program actually properly starts up before its suspended then that is stupid in my opinion but who knows maybe ask them why they did that, I'm not sure

I thought you meant it was suspended before the main thread was resumed and the program could execute its own code, but seems like you are saying that it is suspended after the main thread had already been resumed by the Windows Loader which is indeed silly
After reading your comments, I retested ReHIPS and could not replicate this strange behavior. So, I am sure that it was rather my testing mistake. EagleGet starts also another executable EGMonitor.exe. I think, that I allowed EagleGet and did not allow EGMonitor.exe. So in fact, EagleGet was started showing the program window, and ReHIPS blocked EGMonitor.exe . Sorry for a stupid mistake.:oops:
The second testing supports your posts about suspending processes by OSArmor and ReHIPS.:)
 
Last edited:

Andy Ful

Level 60
Verified
Trusted
Content Creator
As an addition though, the process suspension thing may also be a potential vulnerability. Unless they are guarding the process starting up from being accessed by external sources until the user responds to the request. Otherwise, an attacker who already is executing code can start up a process which is pending execution by being suspended until the alert has been responded to, can just resume the process with NtResumeProcess. Lol

So if ReHIPS do what Andy says, better make sure they protect the pending execution process. Unlike when you wait to change the CreateInfo->CreationStatus instead of allowing but suspended, then it is indeed more secure by default as you don't have to worry about guarding the suspended process temporarily
It would be interesting to find out, how secure is the 'blocking' procedure in OSArmor. The most secure, so far, seems to be the SmartScreen, because it is triggered before ReHIPS and OSArmor.
 
Last edited:
D

Deleted member 65228

seems to be the SmartScreen, because it is triggered before ReHIPS and OSArmor
Well MS own Windows so they can do whatever but they probably just use a callback but have it invoked before others. Anyway as for suspension, the main thread of a newly starting up process (which will be the only thread at the start) will be in a suspended state by the Windows Loader before initialisation has completed.

Therefore, while you are waiting to respond to an alert from a product holding up a callback routine for PsSetCreateProcessNotifyRoutineEx, the main thread of the process starting up will automatically be in a suspended state. You can't suspend a process, you can only suspend the threads of a process; this narrows down to the suspension state for the process itself, which is the container for the inner workings of the process. This is why NtSuspendProcess -> PsSuspendProcess -> KeSuspendProcess -> KeSuspendThread -> KiSuspendThread. Because the threads execute the code

The Windows Loader will invoke NtResumeThread within the context of the process responsible for the starting up of another process once its ready to do so, however bits and bobs like kernel-mode callbacks which need to be invoked will indeed be before this point arrives. So it is normal for a process which you need consent provided to start-up is in a "suspended" state, because this is automatic and just how it works. Until the process has actually started up and the main thread has been resumed by the Windows Loader, it'll maintain like this.

However, it's a different story if someone is allowing the execution of a new process, and then afterwards manually suspending it themselves. That indeed would be a potential vulnerability, and I thought this is what you were saying before. But I misunderstood? As for the automatic "suspended" state, attempting to resume it if it was by the Windows Loader would be a stupid idea because initialisation would not be complete and would likely end up in the starting up process crashing

All processes being started up are started in a suspended state by the Windows Loader, and the "process" is resumed after all initialisation, so that is when the main thread is resumed

I don't think there's anything to worry about here. ReHIPS and OSArmor are great and the devs both know what they are doing. If a vulnerability is found and exploited and then discovered or by a researcher, both software teams will fix it up. and the potential abuse for either of them for a zero-day is very small

You can try monitoring various APIs for the Windows Loader and then tracking the call stack, then when the smart screen notification appears, use the call stack/logs to see how far the progress was for NTDLL calls invoked from the process trying to start-up the other process which is being intercepted by SmartScreen to get an idea of where about SS will intercept from KM
 
Last edited by a moderator:

Andy Ful

Level 60
Verified
Trusted
Content Creator
I installed both OSArmor and ReHIPS (Expert mode). Next, I ran several times the script :
Code:
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run("C:\Users\Public\Downloads\payload.exe")
WScript.Quit
.
The payload.exe , can be any not-signed executable.
The result on my machine (Windows 10 FCU 64-Bit) was always the same: ReHIPS was triggered first (every time) and OSArmor second. I had to press first 'allow' in ReHIPS to see the OSArmor alert. Sometimes OSArmor was not triggered at all.
I even installed OSArmor first and ReHIPS second, to be sure that the order of installation does not matter.
Next, I disabled ReHIPS protection and installed NVTERP 3.1.0.0. with option 'Do not check if a process is signed (save bandwidth)'. I repeated the test, and now OSArmor and NVTERP blocked execution from the script at the same moment (2 alerts visible).
So, ReHIPS block feature works differently from NVT products, and can block execution at the earlier stage.
In the end, I installed Sandboxie (forced to sandbox the payload.exe) and repeated the test. ReHIPS was triggered first, Sandboxie second and OSArmor was never triggered (payload.exe was sandboxed). But, OSArmor could miss blocking execution from the script. So, I tested another OSArmor feature: 'Block execution of unsigned processes on Local AppData'. I also set Sandboxie to block payload.exe because OSArmor can also block programs in the Sandboxie Sandbox. The result was always the same Sandboxie blocked execution and no alert from OSArmor. When I allowed running payload.exe in Sandboxie sandbox, then OSArmor immediately blocked it showing the alert.
So, my conclusion is that on my machine (the most left is triggered first):
SmartScreen > ReHIPS > Sandboxie > OSArmor
I did not test other OSArmor features, so I cannot say for sure that the above is true for all OSArmor features.
.
Edit
The post was several times edited, because of the complex interactions between Sandboxie and OSArmor. I thought that OSArmor can be triggered first and Sandboxie second, because OSArmor blocked execution of payload.exe in the sandbox so quickly, that sandboxing were not visible. I realized that this can be a problem and changed Sandboxie settings to block payload.exe and then everything was finally clear to me.
 
Last edited:

NoVirusThanks

From NoVirusThanks
Verified
Developer
Here is a new v1.4 (pre-release) (test2):
http://downloads.novirusthanks.org/files/osarmor_setup_1.4_test2.exe

*** Please do not share the download link, we will delete it when we'll release the official v1.4 ***

So far this is what's new compared to the previous pre-release (test1):

+ Prevent regsvr32.exe from loading .sct files
+ Block execution of any process related to SecurityXploded (unchecked by default)
+ Change the tray icon when the protection is disabled
+ Show the protection status on the GUI
+ Added more than 80 internal rules

This pre-release version can be installed over the top of the previous one.

Please let me know if you find new FPs.

On the first week of January we'll update the driver to support Secure Boot.

@shmu26

Can you confirm me the FPs related to the HP printer are gone now?

@Slyguy

That's strange, did OSArmor block something? And what other securty apps are installed?

@Stas

OSArmor should not modify boot time, that's definitely strange. What other security apps do you have installed?

Will try to reproduce on a few XP VMs.
 

Andy Ful

Level 60
Verified
Trusted
Content Creator
...
@Slyguy

That's strange, did OSArmor block something? And what other securty apps are installed?
...
.
I had similar problems with osarmor_setup_1.4_test.exe (system was frozen, tried 3 times), but after installing osarmor_setup_1.4_test2.exe everything seems OK, so far.:)
But, the feature 'Block any process executed from wscript.exe' works only sometimes like on previous versions.
 

Evjl's Rain

Level 45
Verified
Trusted
Content Creator
Malware Hunter
just installed v1.4 test2. everything went smoothly so far
however, I noticed all the rules and exclusions are reset

also is this a correct syntax if I want to whitelist kaspersky's process? Do I need to include a %PROCESSCMDLINE%?
Code:
[%PROCESS%: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 18.0.0\avp.exe]
EDIT: I found this is a correct syntax, avp.exe is excluded
 
Last edited:

NoVirusThanks

From NoVirusThanks
Verified
Developer
@Andy Ful

But, the feature 'Block any process executed from wscript.exe' works only sometimes like on previous versions.
Yeah, I found why it is happening. It will be fixed in the next build.

Much thanks for testing and reporting it with the sample code :)

@Evjl's Rain

You may even allow all processes started from avp.exe like this:

Code:
[%PARENTPROCESS%: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 18.0.0\avp.exe]
To handle also future KIS versions you can use the ? chars on the KIS version number:

Code:
[%PARENTPROCESS%: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security ??.?.?\avp.exe]
Hope that helps.
 

NoVirusThanks

From NoVirusThanks
Verified
Developer
Here is a new v1.4 (pre-release) (test3):
http://downloads.novirusthanks.org/files/osarmor_setup_1.4_test3.exe

*** Please do not share the download link, we will delete it when we'll release the official v1.4 ***

So far this is what's new compared to the previous pre-release:

+ Block execution of .js scripts
+ Block execution of .jse scripts
+ Block execution of .vbs scripts (unchecked by default)
+ Block execution of .vbe scripts
+ Block execution of .hta scripts
+ Block execution of .cmd scripts (unchecked by default)
+ Improved setup installer and uninstaller
+ Added button to reset protection options to the default values
+ Fixed all reported FPs

This pre-release version can be installed over the top of the previous one.

Please let me know if you find new FPs.

The issue reported by @Andy Ful (processes started by wscript.exe not always blocked) will be fixed on the next week.
 

Stas

Level 9
@Stas

OSArmor should not modify boot time, that's definitely strange. What other security apps do you have installed?

Will try to reproduce on a few XP VMs.
Other security apps installed are Privatefirewall, Qihoo 360TS, Malwarebytes Anti-Exploit, CryptoPrevent v7.4.21
I did tried to disable Qihoo 360TS & Malwarebytes Anti-Exploit startup process & services it doesn't help. After blue Welcome screen it stays on my wallpaper for very long time with no start menu or desktop shortcuts and Task Manager will not open too until start menu appears. After uninstalling OSArmor it boots fast again.
 

NoVirusThanks

From NoVirusThanks
Verified
Developer
Here is a new v1.4 (pre-release) (test5):
http://downloads.novirusthanks.org/files/osarmor_setup_1.4_test5.exe

*** Please do not share the download link, we will delete it when we'll release the official v1.4 ***

So far this is what's new compared to the previous pre-release:

+ Improved detection of parent process
+ Block execution of .ps1 (PowerShell) scripts (unchecked by default)
+ Improved setup installer and uninstaller

Now the .db files (exclusions and custom-rules) are not deleted on uninstall.

This pre-release version can be installed over the top of the previous one.

Please let me know if you find new FPs.

@Andy Ful

The issue you reported should be fixed now, please confirm :)

@Stas

I installed that 4 security apps on a W7 VM, then I rebooted, then I installed OSArmor.

No issues at this point.

I rebooted the VM, and no issues again.

Will try to use the VM and see if something happens.
 

shmu26

Level 85
Verified
Trusted
Content Creator
I am still seeing blocks from HP printer software:

Date/Time: 12/31/2017 9:02:38 AM
Process: [3608]C:\Windows\SysWOW64\mshta.exe
Parent: [14256]C:\Program Files\HP\HP Officejet Pro 6830\Bin\HP Officejet Pro 6830.exe
Rule: BlockHtaScripts
Rule Name: Block execution of .hta scripts
Command Line: "C:\Windows\SysWOW64\mshta.exe" "C:\Program Files\HP\HP Officejet Pro 6830\Bin\HPSPProgress.hta" -lang_id="1033"
Signer:
Parent Signer: Hewlett Packard

Date/Time: 12/31/2017 9:03:07 AM
Process: [764]C:\Windows\SysWOW64\mshta.exe
Parent: [14256]C:\Program Files\HP\HP Officejet Pro 6830\Bin\HP Officejet Pro 6830.exe
Rule: BlockHtaScripts
Rule Name: Block execution of .hta scripts
Command Line: "C:\Windows\SysWOW64\mshta.exe" "C:\Program Files\HP\HP Officejet Pro 6830\Bin\HPSolutionsPortal.hta" -data_folder="C:\ProgramData\HP\HP Officejet Pro 6830\HPUDC\HP Officejet Pro 6830 (Network)\"
Signer:
Parent Signer: Hewlett Packard
 

Stas

Level 9
@Stas

I installed that 4 security apps on a W7 VM, then I rebooted, then I installed OSArmor.

No issues at this point.

I rebooted the VM, and no issues again.

Will try to use the VM and see if something happens.

LOL Windows 7 is good boots very fast but on my XP boot is extremely slow, but it doesn't mater to me I don't use that old pc often, just wanted to see if it will work well on my XP. I forgot to say that my XP has POS updates installed.
 
Top