CyberLock 9.0

  • Thread starter Thread starter danb
  • Start date Start date
  • Featured
VoodooShield
346 Replies 63,432 Views
Hi @danb,
Thanks for the latest update. My issue with Claude Desktop is fixed.
I now have a new issue. I start to run Firefox in PortableApps (PortableApps.com - Portable software for USB, portable, and cloud drives).
When I open portable FF, Cyberlock keeps asking me about FF, even if I repeatedly click Allow. Cyberlock flags firefox.exe as safe but just do not auto allow.
Also, if I close FF, it will hang.
 
vaccineboy said:
Hi @danb,
Thanks for the latest update. My issue with Claude Desktop is fixed.
I now have a new issue. I start to run Firefox in PortableApps (PortableApps.com - Portable software for USB, portable, and cloud drives).
When I open portable FF, Cyberlock keeps asking me about FF, even if I repeatedly click Allow. Cyberlock flags firefox.exe as safe but just do not auto allow.
Also, if I close FF, it will hang.
Click to expand...
Interesting, thank you for letting me know, I will check it out right now. Does this happen each and every time you start FF portable? And do you launch FF portable directly or do you launch it through PortableApps.com_Platform_Setup_30.5.paf.exe? One last question... when there is a block, does Sirius analyze the file each and every time? If so, that means something has changed within the file, so it will have a different hash, and if that is the case, CyberLock will need to block it.

My guess is that you should be able to put FF portable wherever you want on your computer, launch and allow it once, and you should be good to go, until that file is updated. I will check it out right now and let you know something soon, thank you!
 
oldschool said:
@danb - Indeed, I even enabled SiriusGPT with this update and I like it. And I've gotten used to the mini-prompts. Everything nice and smooth.
Click to expand...
@oldschool, WOW, very cool! If Sirius can win you over, it can win anyone over, so this is a great sign ;). I am with you on AI though... it needs to be implemented correctly and in small doses. Thank you OS!
 
vaccineboy said:
Hi @danb,
Thanks for the latest update. My issue with Claude Desktop is fixed.
I now have a new issue. I start to run Firefox in PortableApps (PortableApps.com - Portable software for USB, portable, and cloud drives).
When I open portable FF, Cyberlock keeps asking me about FF, even if I repeatedly click Allow. Cyberlock flags firefox.exe as safe but just do not auto allow.
Also, if I close FF, it will hang.
Click to expand...
Please see my other reply above. So I just tested and CyberLock worked exactly as designed... it had the exact blocks that it should have had in order to properly protect the system, and then it did not block when it was not supposed to block.

Just to be sure though, can you please post or send me the exact steps to reproduce the unwanted blocks you are seeing? Thank you!
 
danb said:
. After 15 years of development and with CyberLock being as stable as it is, I figured it was time to switch to fail-closed.
Click to expand...
@danb, after many yrs of us telling people this is a default deny solution, now you say it has been fail open all along. I don't know what to say. Under what conditions did it used to fail open exactly ?

Tell me this, if your AI says something is 95% malicious, and the user is away from the computer for 1/2 hr, would Cyberlock allow it to run ? ( fail open). Or would Cyberlock block it ( fail closed ) ?
 
Last edited:
Victor M said:
@danb, after many yrs of us telling people this is a default deny solution, now you say it has been fail open all along. I don't know what to say.
Tell me this, if your AI says something is 95% malicious, and the user is away from the computer for 1/2 hr, would Cyberlock allow it to run ? ( fail open). Or would Cyberlock block it ( fail closed ) ?
Click to expand...
Sorry, I should clarify. VoodooShield / CyberLock has always been default-deny, and that has not changed.

What I was referring to by “fail-open” is a completely different, low-level failure condition. Historically, if the driver could not obtain a valid verdict from the service because of an internal error, timeout, or communication failure, CyberLock would fail-open rather than risk locking up the system.

After 15 years of development, the decision path is now stable enough that I was comfortable changing that exceptional failure fallback to fail-closed.

So CyberLock has always been default-deny during normal operation. The recent change was simply from fail-open to fail-closed when the software itself cannot obtain a verdict.
 
@danb, I think a security solution should always fail closed. Low level problem or not. Attackers can perhaps introduce the error and take advantage of it failing open. I think this is important enough for you to contact all users and informing them to do an important upgrade
 
Victor M said:
@danb, I think a security solution should always fail closed. Low level problem or not. Attackers can perhaps introduce the error and take advantage of it failing open. I think this is important enough for you to contact all users and informing them to do an important upgrade
Click to expand...
Fail-open is the default for most products, and it should be, otherwise if there is an issue with the driver, the whole computer will lock up. In fact, I have seen remarks on MalwareTips and Wilders where someone said "it is smart that you designed it fail-open" for CyberLock and also other similar products.

The last thing we want to do is to release a fail-closed beta to our entire user base before it is thoroughly tested for several months. So far we have not had any issues, but we need to be 100% sure before we pull the trigger.

And again... this ONLY applies to when there is an internal error in our software... we do not want to lock up the computer. This has absolutely nothing to do with something like when a user prompt is presented and the user clicks Block or Allow. This only has to do with internal errors, and has absolutely nothing to do with an item being blocked / allowed.
 
I am having an issues with 9.15 where CyberLock 9.15 Smart Firewall in Recommended mode blocks WinRM/WS-Man connections to a Hyper-V host on TCP 5985. Test-NetConnection host -Port 5985 succeeds, but Test-WSMan host fails and curl reports Bad access. Disabling Smart Firewall immediately restores both Test-WSMan and Hyper-V Manager connectivity. Adding an outbound firewall rule for mmc.exe does not resolve it. Is there a Smart Firewall exclusion for WinRM/WS-Man or a trusted IP/port?
 

Recently browsing

Members who viewed this thread in the last 5 minutes

You may also like...

Back
Top