I have the latest Comodo Firewall running on XP SP3. My question is about an alert after launching gpedit.msc. The alerts for running in the sandbox still occur after adding this application to the safe files list for Defense+ Sandbox. Why?
I did what you suggested. Tried to add both mmc.exe and gpedit.msc to the “Microsoft Windows Component Publisher” in “My Trusted Software Vendors” list. Comodo comes back with the response…“already in the list” for both.
Also, SP3 was slipstreamed using the original disk without any service packs. Then installed on the hard drive. Not updated to an existing installed system.
I can not add the gpedit.msc to “My Safe Files” list because it says it is already in the list. But still alerts for being sandboxed.
If you check both “do not run in the sandbox again” and the “always trust the publisher of the file” it gets added to the safe files list. I find that interesting.
One thing I did not mention but did not think it was a problem. I am using a replacement menu for Windows called “Vista Start Menu”. It has it’s own run box. I can launch regedit and msconfig from here without issue. But not gpedit.msc. Not sure why. But “Vista Start Menu” uses a hook for integration into XP.
If I launch gpedit.msc from the normal run box…no problem.
If I launch gpedit.msc from the cmd box…same problem, Comodo tried to run it sandboxed.
So, the only way to launch gpedit.msc is from built-in run box only…not using “Vista Start Menu” and not from the command prompt.
Also, “Vista Start Menu” is listed as a trusted program. I can launch any program from here without an alert.
Here is a link, so that you know what this replacement menu does.
Thanks. This helps me to understand what may be wrong, but things are still a bit confused
Your Vista start menu replacement is not MS certificated so it is probably being sandboxed - but you have not mentioned an alert for it.
To confirm this, and give more general diagnostic info could you please post your D+ logs, taken say 5 mins after answering a sandbox alert. Could you also please install process explorer from microsoft, set it to highlight only jobs (options menu), then take a screenshot when the sandbox alert is on the screen. Please make sure that both screenshots have all relevant info legible (including paths).
Could you please also give the last modified date for gpedit.msc. Does this get modified every time you run it? If not try running the file with the same date modified twice in a row (on the first time add it to my safe files, check the date before and after runs). Do you still get an alert? Please post screenshots of the main and certificate tab of the file properties box for gpedit.msc, and mmc.exe, if possible.
If you check both "do not run in the sandbox again" and the "always trust the publisher of the file" it gets added to the safe files list. I find that interesting.
You may find it gets booted out of my safe files on reboot…
It’s ‘digital signatures’ in my version of XP - sorry!
If it’s still not there then you can check in process explorer. Ask to ‘verify image signature’ under options, and await the update. Then double click on the process and post the ‘image’ tab from process explorer.
Even if the start menu replacement is not being sandboxed it is worth posting the process explorer view (remember highlighting) to see what is sandboxed and what is running what.
It’s worth being systematic as then we can help others with the same problem, and fix it long term. Also we can try to fix it without compromising you security.
Exporting the log file in .htm comes up blank…no entries. So I posted a screen shot. Am I doing something wrong here? I go to DF+ events\more and the calendar for today’ events and export .htm. The file after opening in the browser has “0” entries.
The files gpedit and mmc modify dates never change.
Nothing changes whether gpedit is in the safe files list or not. Still alerts.
Not sure what you meant by two screenshots of process explorer. I have the one with the alert just after launching gpedit…you can see the cpu is still at 95%.
I posted the “configure highlighting” with only the jobs checked. But the other colors still come up depending on whether they are launching or closing. Find that curious.
If I missed something or did it wrong, let me know.
Thanks for bearing with the process. Almost right.
You were just a bit too quick with process explorer. Could you try again please, and wait 5 mins after the sandbox alert come up (without closing mmc/gpedit). (MMC should not be green by then, maybe it will be brown, maybe white! gpedit will probably not be visible)
Also I cannot see all of of the action in the D+ logs. You can expand these by dragging the corner. I think these may provide a strong hint - ‘scanned on’ looks like the beginning of something that may be useful.
Can you tell me what it says in the logs, gpedit entry, after ‘scanned on’? Ta. This could be very useful to others.
The last modified date for mmc is wrong - its not an SP3 file. Don’t think gpedit is either. So this is likely your problem.
Simplest way to address this on systems that have been installed from an installation disk is to use:
Start ~ Run ~ and type in “sfc /scannow” without the “” and with the installation disk in the drive. I’m not sure how to do this with a slipstreamed disk. Maybe you know or someone else will. Take a restore point first. The advantage is that you could improve system stability as this ensures that all your files are the correct versions. I wonder if the slipstream disk is reliable?
Maybe simpler to find the corresponding SP3 files on the internet and replace them in system32.
Ok, I will follow up on the file dates. Should be interesting. I do not use restore points. I have an image of all our machines on the network. If the worst happens, I just restore the image. No big deal. I also have another one that is running shadow defender. If I find that the files are wrong I will try it in virtual mode.
The log says “sandboxed as, scanned online and found safe, safe.”
The last modified date for mmc is wrong - its not an SP3 file. Don't think gpedit is either. So this is likely your problem.
Did some research on gpedit. Does not look like this has been updated with any service packs. On the other hand mmc did get updated with SP3 from the one included in SP2. But I think what may have happened is that sp3 does not include .net framework. MMC version 3.0 from Vista would not be installed without .net framework. I have no applications that require .net framework, hence during the integration process before I slipstreamed the disk, version 3.0 was not installed. Probably defaulted back to the one that was included in SP2, as it does not require .net framework. The version information indicates this for sure.
This has not created any problems for me and I have a couple of applications that require the use of the console application. No problems at all.
Guess if MS wanted the user to have mmc version 3.0 on the system, they would have included .net framework in the service pack. Since they did not, it must not be a requirement.
If Comodo is looking for 3.0 then this could be the problem, but do not forget, if I launch it from the XP run box instead of Vista Start Menu, the alert does not occur.
Interesting. From all the information we have it is clear that CIS does not think the mmc gpedit version is correct.
Certainly on my computer (XP SP3) the file date is 2003. I’m wondering if 2001 is a bit early even for SP2? You .net explanation however sound reasonable - I have .net installed.
My guess is that you can solve this by updating gpedit, or by using sfc. It might be more interesting to try to find out what is running mmc - ie what is missing process 1724. (It may not be easy to do this unless you are used to using a logging system monitor like Micosoft Process Monitor - but if you are that s great - just run it with a gpedit.msc & mmc.exe filter and see if you can catch the process invocation). My guess is its gpedit.msc. If so it means that the OS is seeing the .msc file as a genuine executable. In which case it would be interesting to add .msc to the list of executable extensions in CIS - Go to D+ ~ My Protected Files ~ Groups & add to the executables group to do this.
Your point about the context from which it is run is well made.To deal with this issue the only thing I can think of is to give the modified taskbar Windows System or Installer/Updater permissions. I would do the latter (installer/updater) only for experimental purposes, and only after trying the extension fix. Defining a program launch point as an installer/updater will remove a lot of protection from your system.
I looked at my XP Pro files on my network drive. Went into the i386 stuff from the SP3 integration, no gpedit was present. The one that is present is from the original XP Pro disk. So that file is certainly one created originally.
Not much on the Microsoft Site or anywhere on the internet.
The gpedit has no version information??? The mcc does have version information is listed as a qfe.
The screenshot below has the information. The number 5.2.3790.4136 is a SP3 version. Their is an update for mcc version three and they replace a bunch of files associated with the install, but again I would have to install .net and have no reason to at this juncture.
If there is a place to find an update msc file, I certainly can not find it. I think that any .msc file simply launches the mmc with the application dll file associated with the snap-in called.
The newest update for mmc version 3 does not update gpedit.msc either…it is not in the list.
Interestingly enough is that gpedit.dll is a sp3 file with the number 5.1.2600.5512. I have no answer why your msc is a different date, other than possibly you have been auto-updating your system. I do not auto-update anything. Pick and choose what I want.
You can not add .msc to the protected files list…or I could not find a way. It is not considered an executable by Comodo.
My best solution was to simply create a shortcut to it and the problem is solved.
My gpedit.msc is 7/2003, no version, no certificate.
Is gpedit in any way treated as an executable by the OS? It is not a datafile linked by file association, though I note that when you run mmc, it loads gpedit as a command line instruction parameter. (See mmc properties)
I cannot trap any activity by it using procmon, but I am not an expert with this tool (which is seriously difficult to use!)
The modified Vista toolbar must be implicated in some way. Have you tried making it Windows system and adding the .msc extension to the executables group? (Try these separately then together I would suggest).
Kind of sorry I started this post. Created more activity than I think it deserves. Again, my apologies.
I have done some more research, since there is not much about it from the MS side.
Do any of you know that the .msc file is just an .xml file. Make a copy of it and change the extension.
Here is a small portion of the gpedit.msc. It points to different clsid’s which are the files associated with this snapin. If you search the registry and look the classes up you will find the files needed to run gpedit. Since XP, Vista, and 7 have so many of these snapins this was the most efficient way to deal with it, one mmc used for all.
The confusing part of this for me is that the file version for all the libraries do not seem to coincide as one would expect with the actual mmc console version. While Mike and I were sharing all this information, I was convinced that I did not have the latest version of mmc because not of the files indicated that to me, including mmc.exe which I have already posted.
But below is a screenshot of an unassigned mmc with the “about” displayed. It seems I do have version 3.0.
I can kind of understand why the gpedit, dfrg, diskmgmt, eventvwr, etc. do not have a version tab. They are just text files. By the way any of these will trigger an alert in Comodo if launch from the command prompt rather than the run box.
And yes, I too have tried to capture the gpedit on process viewer, but we are probably talking about 1 scan cycle.