Your thoughts Tony Klein + Anyone else

Hi Tony.

I've been playing around with some rules to protect the 'Context Menu' when i came across something interesting. I originally set my group to cover all of the
branches (HKCR,HKCU,HKLM,HKU). But after your reply to my post on 'NeverShowExt' https://www.wilderssecurity.com/showthread.php?t=118967 and the microsoft article,http://technet2.microsoft.com/WindowsServer/en/Library/dd670c1d-2501-4f32-885b-0c6a1ae662f41033.mspx i reduced it down to just the HKCR branch.

I had the following rules:-

HKEY_CLASSES_ROOT\*\Background**
HKEY_CLASSES_ROOT\*\Openwithlist**
HKEY_CLASSES_ROOT\*\Persistenthandler**
HKEY_CLASSES_ROOT\*\Shell**
HKEY_CLASSES_ROOT\Clsid\*\Background**
HKEY_CLASSES_ROOT\Clsid\*\Inprocserver32**
HKEY_CLASSES_ROOT\Clsid\*\Openwithlist**
HKEY_CLASSES_ROOT\Clsid\*\Persistant**
HKEY_CLASSES_ROOT\Clsid\*\Shell**
HKEY_CLASSES_ROOT\Systemfileassociations\*\Openwithlist**
HKEY_CLASSES_ROOT\Systemfileassociations\*\Shell**

All with '*' for value - 'create/modify key' - 'set/delete value' - 'ask user'.

I then thought about how that works,if the modifications are made directly to HKCR,that's fine,we're covered,but what if it's made to either HKCU or HKLM? It
should be carried over to HKCR according to the microsoft article you pointed out. If RD blocks the mods to HKCR,are they then removed from the other two
branches aswell? If not,do the mods still work properly,or are they just 'invalid data' ?

So thought i'd test it. (as you do) First off,i just deleted a few bits of 'data' in HKCU & HKLM,(i chose some entries in '*','Directory' & 'Folder') no pop-ups... so
i put the 'data' back,no pop-ups... I then renamed some 'values',still no pop-ups... Strange... So i added a new 'key',got a pop-up,added some 'data',(copied from
Ad-Aware's scan entry),got a pop-up. Went to a folder (on HDD),right-clicked and there was my new context menu item,selected it and Ad-Aware did a scan... The new item isn't in HKCR by the way.

In short,if you only cover the HKCR branch,you only get alerts for existing 'keys' being modified/deleted, but not the 'values' or
'data' within them. To be alerted of any 'value'/'data' mods in the existing keys,you need to cover those branches aswell.

OK...Just done the same test for HKU,not good... you don't get any alerts for anything... 'mod','delete','add' key, 'value' or 'data' modification.
If you add a key,it gets carried over to HKCR though,but no alerts... Covering the three branches - HKCR,HKCU,HKLM does also cover HKU,but only for 'key'
'mod'/'deletion',you get an alert for new key being added,but selecting block doesn't stop it from being added . Again,you need to cover this branch to get any
alerts for 'value'/'data' modification.

I replaced all my rules back for all branches,and now get 'all' alerts for 'any' modifications.

What are your thoughts on this? Anyone else reproduce the same results?

I haven't tested this with any other rules yet,if i have time i'll give it a go.
(Unless someone else beats me to it... hint hint)

 

I just had time to test the following.

Take this rule of mine:

HKEY_CLASSES_ROOT\Directory\Shell** | * | CREATE KEY, MODIFY KEY, SET VALUE, DELETE VALUE | Ask User, Log to Disk | File Associations | 7

Now I created a new value in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shellex\PropertySheetHandlers\{ef43ecfe-2ab9-4632-bf21-58909dd177f0}, which ought to be covered by this rule, and I do indeed get a popup.

If I go over to HKCU\Software\Classes\Directory\Shell, and create a "Test" subkey there, I get a popup.

I Get NO popups creating values in the Test subkey, and even more curiously, I get no popup when DELETING said subkey...

Although most of the action in this field IS taking place in HKLM it does need looking into.

We've become aware of some anomalies there ourselves, and certainly it has our attention.

Thanks!

 

Cool,that's good to hear . Do you know if RD can be tweaked to cover this sort of thing,or will we have to start putting rules for all branches?

Thanks

 

Well, as I said, probably 99,99% of all activity in that area takes place in HKLM\Software\Classes, so you should be very well protected as it is at present.

At the moment I'm not aware of any workaround, but I'm certain the issue is high on Jason's to-do list