System Safety Monitor 2.2.0.593 out of beta

Is modification of the network hardcore rules possible in this Beta?

 

It seems not judging from the changlog. They may need some more time to implement it...

 

No,.. network rules as last beta.

 

Ummm... Unless I am mis-reading, in build 594 the default rule for "untrusted" is no longer "allow." Also, I was able to change that rule from "?" to block. I THINK I did (but after my prior fiasco I leave Stem & others to verify or disprove.)

Default illustrated below...

 

My change "stayed put" as illustrated below...

 

LOL, not again. You two folks could you please have one opinion, if not i have to install it my self

 

I only installed for about 2mins, and only checked csrss.exe which appeared to still be hard_coded as allow (so presumed all others would be the same),.. I will re-install to re-check

edit:
I have re-installed 594, and the option for the network access is still the same for those 3 windows apps. Could be because I kept the last config file?,... re-checking

No,.. still the same on this setup,

 

I checked again after a restart. The changes I made still are there, as illustrated in the above example.

Okay I see what's happening now. There is now (for example) an lsass.exe that is system group, system object, and ALSO an lsass.exe entry that is system group, application object. TWO lasass.exe entries -- one that can be modified, the other where modifications cannot be made (grayed out).

Which means that I am TOTALLY confused.

 

You must of added a rule,.. like the last time (or you imported your rules, with the 2 entries?)

So it does look like the hard_coded network rules for those apps are still applied.

 

Yah, I added them last time, & then imported them. What a mess -- it seems to me that allowing 2 conflicting rules for the same process is a bug. Agree?

 

Yes,.. I see little point in having 2 rulesets for one application.

 

Okay, I just restored my image that has SSM 593. In addition to the default rules problem identified by Stem, SSM 594 was asking the SAME bloody questions about Cyberhawk every time I restarted -- even though I made my answers to those questions permanent from the get-go.

IMO 594 isn't quite ready for primetime. Yes, it's a beta -- but I leave its debugging to wiser heads than mine. 593, however, works just fine.

 

There is now an official reply to the hard_coded network rules. They will be editable in the next build (I hope they stay that way)

http://syssafety.com/forum/viewtopic.php?p=2599#2599

 

SSM is gobbling up RAM?

As noted in an earlier post in this thread, I reinstated SSM build 593.

Just now, while I was checking something in the Windows Task Manager, I noticed that SSM's exe file was using 9.9MB Ram & climbing steadily. Now 9.98MB ram isn't very much, but WHY should SSM's ram usage be on a steady increase, I wonder?

During the time I watched it, SSM was increasing its RAM usage by about 3K - 4K per second. I closed Task manager, waited several minutes, then re-opened Task Manager. Sure enough SSM's ram usage had increased by nearly 100K during the time Task Manager was closed.

Has anyone else noticed a similar occurence -- namely, a steadily increasing usage of ram by SSM's exe file? If so, is it a memory leak or what?

 

Yes, it's a memory leak and that was one of their main reasons for providing the .594 hotfix shortly after.

However .594 introduced new severe problems so that neither one is really usable. They are more like alphas. Look at SSM forum - I have not seen such a flood of bug reports before. Seems like quality of their betas is pretty much going downhill in recent times.

 

@Kenjin- Thank you VERY much for confirming it is an application problem & not something wrong with my sweetie pie computer.

I think SSM folks might have included too many major changes in their recent betas -- that's asking for trouble.

Oh well -- this looks like a good time to give SSM a rest for a week or so, & give ProSec a trial.

 

2.2.0.595 Beta released.

What's new:
* improved detection of hidden processes (rootkits).

What's changed:
* display format of version info in the tray icon tooltip.

Bugs fixed:
* fixed driver bug leading to occasional system crashes (BSODs) that often occurred while using memory optimization software;
* child/parent settings for libraries and drivers not saved after restarting SSM;
* minor GUI issues.

 

Just received "System Safety Monitor 2.2.0.595 was released." from SSM. Still calling it a Beta but you can now block network access for the 3 apps above.

Does this satisfy the point Stem and others are making?

 

Can hash checking be enabled on these 3 applications?

 

I assume you mean checksum?

I tried it with LSASS and this is it after I closed down SSM and restarted it. Have not tried after a reboot. All options on all tabs can be changed.

 

Only the network rules can be changed for the 3 applications mentioned.
Yes I did mean checksum: If you select one of the 3 applications mentioned (rules~applications), then look at the "process control" tab,.... "dont verify checksum" is enabled (there is no checksum verification on that application) and greyed out (user cannot change this setting).

 

Is there a special strategy behind this, that they disblable such modification possibilities for user? I don't like that at all Or did i understood you folks wrong?

 

SSM state this is to stop the user from blocking/ causing problems with windows shutdown/startup. I cannot see how disabling checksum helps with this. I would prefer to know if these applications are changed in any way.

From the testing made by "djg05" about termination,.... lsass.exe is not directly protected from termination by these hard_coded rules (I terminated lsass.exe simply with APT kill 1.). Yes I was given a popup to say there was a termination attempt,.. but allowing the termination does kill lsass with a forced shutdown of the system,..... this goes against one of the main reasons "djg05" likes SSM,.. as "djg05" states SSM will protect such programs whatever the user inputs.
So a question arrises, as to the protection of these applications with hard_coded rules, and if changes are made to these applications, how would the user know.

 

Well, regarding to killing applications i have to say that i don't know any program which can protect a second application from killing by brute force method - searching all linked threads and killing one after an other.

The thing is that till version 2.1 SSM gives me full control over what is going on on my machine and how i want to manage this. With the actual Beta they are going a step back. I would accept a beginner and an advanced mode in SSM to solve this big inconvinience.

 

SSM will protect from all SPT kills, and most APT kills. PS will intercept all kill methods/attemps from both these kill programs.
Settings for SSM to block kill attempts:-