D+ in Safe mode, services.exe under Computer Security Policy has every item set to “ask” without exceptions. We download DPC Latency Checker.
Add dpclat.exe to “My own safe files”. Launch dpclat.exe. D+ will automatically learn every alert except: “dpclat.exe tries to create dpclat.sys in \system32\drivers” and “services.exe tries to load dpclat.sys which could not be recognized”. If we choose “allow+remember” on last alert, then corresponding item will be added to allowed exclusion list of “Driver Installations” of services.exe, leaving everything at “ask” position.
Let D+ read digital signature from dpclat.exe and add that signature to “My Trusted Vendors”. Launch dpclat.exe. D+ will automatically learn every alert except: “dpclat.exe tries to create dpclat.sys in \system32\drivers” (we allow this). Main alert is missing! What happened: D+ automatically set every item (except three) for services.exe to “allow”, including “Driver installations”.
If we block creation of dpclat.sys, then main alert is present. Obviously this is buggy behaviour, pls fix this.
Applications in Comodo’s safe list and with safe signature behave differently from programs in “my safe files”. This difference appears to be by design. Since “safe list” and “trusted vendors” both match hash of exe to ensure the correct program, these programs are trusted more. My safe files is just what the user (who might be wrong) has added and so is trusted less.
I don’t like this automatic setting everything to allow but I think this is the explanation for the difference in your two scenarios.
It is likely that dpclat_driver.sys is digitally signed as well and thus the driver was automatically allowed.
AFAIK with D+ Safe mode, safelisted applications (eg services.exe) will get most of their default Access rights set to allow (equivalent to Trusted applications) as soon as one of the corresponding actions will be learned, this would explain why unrelated access right of services.exe were set to allow as well.
It would be reasonable to test a similar scenario with an (unsigned/unknown) application that rely on services.exe but do not create/delete its (unsigned/unknown) driver on the fly and add also that driver to “My safe files” before the test.
That could be true. And that could explain why main alert is triggered if i block creation of dpclat.sys: no .sys file > no signature > no learning > alert.
And that could explain why there is alert when pagedfrg.exe is launched (“services.exe tries to load pagedfrg.sys which could not be recognized”): pagedfrg.exe is signed, but pagedfrg.sys may be not signed.
Nevertheless, it is not very interesting when “Driver Installations” of services.exe is set to “allow”. Main complaint is why “Driver Installations” of services.exe is set to “allow” automatically, despite services controller can be used to load various 3rd party drivers (including malicious)?!
Since the default action of “Driver Installations” for services.exe policy is set to “allow” for all pre-built configurations and that services.exe load many legitimate drivers it looks the current behavior is focused to prevent the installation of new drivers but not to prevent loading of properly installed drivers.
In D+ safe mode case running as dcplat.exe unknown (not saflelisted) app this can be done either by blocking registry modification alert of HKLM\SYSTEM\ControlSet???\Services\dcplat_driver (for all configurations) or file creation alert of dpclat_driver.sys (if proactive security configuration is used).
AFAIK blocking the related registry alert (HKLM\SYSTEM\ControlSet???\Services\driver-name) , thus thwarting a driver installation, would not only prevent drivers loading at runtime but also prevent drivers which are not immediately loaded and are actually configured to be automatically run by services.exe during bootup (by setting the proper registry entry) thus before the user could logon and before driver load alerts could be possibly displayed by CIS GUI.
Indeed AFAIK before a driver can possibly be loaded it should be properly installed.
I know that. In all cases when such technique is used to load driver this registry modification alert is present. But this is irrelevant to discussed subject. I did not call this “flaw” initially because of this very registry modification alert which can prevent driver from being loaded.
Nevertheless, autolearning for services.exe should be changed in the following way in order to be consistent:
If driver (.sys file) is safe, D+ (in Safe mode) should autolearn its loading by setting “Driver installations” to ask with allowed exception for this driver instead of setting “Driver installations” to allow.
…And overall autolearning mechanism of D+ in Safe mode is not an excuse.
The ironical part here is that main alert (unknown.exe tries to modify protected registry key HKLM\SYSTEM\ControlSet???\Services\some_driver_name) says nothing about driver is being installed. Not a single word about “driver”, only “protected registry key”. There is already quite big thread with request to make that very important alert informative enough.
Without doubt mentioning that the service registry repository is involved and what it does would provide a more informative alert though this would not change the type of actions to be blocked in order to prevent the installation of such threats.
Indeed those who are supposed to know about drivers/services but are not assumed to know about the service registry repository might not be willing to ignore the severity of related red alerts if the purpose of such action is mentioned (if they are assumed to read the alert/security considerations).
The irony is that though actually a registry modification is needed and is displayed with the highest severity (red) rating this aspect is often neglected for the sake of arguments.
Whenever individual preferences might provide feedback for future improvements IMO it would be also important to not have eventual readers misunderstand what they need to do with the “current” CIS even more if users would be seemingly assumed to.
AFAIK the autolearning mechanism of D+ in Safe mode is part of the overall behavior to which those scenarios were consistently conforming.
Anyway if a forthcoming version will be updated to have services.exe “Driver installations” set to ask with allowed exception in D+ Safe mode what would happen to legitimate, but not safelisted (eg: by digital fingerprint hash or digitally signed trusted vendor), drivers which are registry-configured to be automatically ran before the user logon but were never ran/loaded beforehand using services.exe (without a chance to mark them to be remembered and thus without a correspondent exception )?
Should they be silently allowed by setting a corresponding exception even if unknown?
Should they be silently allowed without setting a corresponding exception?
Or would it be consistent to block them all?
Whatever will be, the resulting behavior will obviously apply to eventually installed malicious (automatic/system/boot) drivers as well.
My suggestion may be wrong. To stop malware threat main red alert about HKLM\SYSTEM\ControlSet???\Services\some_driver_name registry modification is enough…and it is…main
However, when second driver loading technique is used, then there is always red alert “tricky_malware.exe tries to load a driver”. I want this alert to be always displayed (except using Paranoid mode) when services controller is used to load a driver - that’s all.
p.s.: i refer to 2 driver loading techniques described by wj32here
As an end user I would prefer D+ to be much flexible as possible so I would appreciate such possibility as well since I rely on D+ not only as a protection tool but also to understand what’s going on when I run an app.
This said it is undeniable that the development is focused on making D+ a solution compatible with the widest audience and thus the tradeoff often leans toward KISS approach (for what an HIPS could be).
Maybe the rumored Behavioral Blocker layer will provide some improvement on these aspects though I would prefer that a registry modification will not be represented as auto-run like I see in some 3rd party screen-shots even if that from a behavioral perspective the description would appear fitting.
If such approach would be applied to other registry/file settings to launch applications at startup sure users would get the point (though I wouldn’t have a clue about what actually is going on).
ATM I’m anticipating V4 as IIRC development is focused on the forthcoming release whereas only fixes will be apparently scheduled for V3.
If there is a chance to get a new feature I’m all for it and IMHO it would be crucial for the whole member base to organize such wishes in a way it would be possible to provide some statistics (polls) before the first V4 beta will be rolled out (it would be more likely to implement something when the design is ongoing than after it will be finalized) and possibly provide wishes that are tailored for the type of audience CIS is intended for or that at least would not overlap with their preferential D+ modes.
While many topics are still focused on AVs (reviews, scores and such) IMHO it is likely that the ongoing challenge is to help many users with the transition toward more sophisticated approaches whereas AV, in spite of their promises of allround unfaltering protection, do seemingly relegate related education as an unnecessary liability. :-X
the tradeoff often leans toward KISS approach (for what an HIPS could be).
What is KISS: KasperskyISS (Kaspersky Internet bla bla bla)?
Maybe the rumored Behavioral Blocker
Do i understand you correctly: these rumors are about CISv4 ?
IMHO it would be crucial for the whole member base to organize such wishes in a way it would be possible to provide some statistics (polls) before the first V4 beta will be rolled out
This [i]may[/i] be excessively because:
* there already may be highly detailed design of future v4 (based on previous feature requests, technical improvements etc);
* current feature requests for CIS v3 may be treated by development team as requests for v4 because they (Team) know that new features are not going to be implemented in v3.
It’s still in the early stages of development. From what we know now it will be part of the upcoming v4 and it may be related to a promised behaviour blocker component. Very little we know (for sure). Current estimations assume a beta version of v4 not before the end of the year. Patience is the key word here…