I am having serious problems on Win XP SP3 with the CIS firewall ever since that thing upgraded itself to 4.0. The problems relate to any process that identifies itself to COMODO with a contracted 8.3 DOS name, as is the case (inter alia) with OUTLOOK.EXE. Such a process will not observe any ruleset (except for the “All Application” set). I tried every permutation for Application Path - no matter. The only way I can make a process abide by a ruleset is if I launch it such that it identifies itself to COMODO with its long file name. Unfortunately, I have not been able to establish to date how to force this under all circumstances. On OUTLOOK, for example, I have completely failed. The problem first manifested itself on my music server, SqueezeSvr.exe. When I launched this in the recommended way, it wouldn’t work because it showed up as “C:/PROGRA~1/SQUEEZE~2/server/SqueezeSvr.exe”. However, when I launched it from file explorer, then it reported to COMODO as “C:/Program Files/Squeezebox/server/SqueezeSvr.exe” and would observe the firewall rules. Bizarrely, since I shut down SqueezeSvr.exe and relaunched the “official” way, it continues to report its LFN to COMODO and works. (It still doesn’t work very well because MySQL is part of the Squeeze distribution and mySqld.exe always comes up with its 8.3 name and I cannot therefore make the music database accessible.)
EDIT:
CPU: 32 bit
OS: Win XP Pro S3, using admin account (of course)
CIS: 4.0, Defense+ disabled.
These steps may allow you to reproduce the problem:
(1) Find a Win XP machine
(2) Perform a fresh install of CIS 4.0, reboot.
(3) Allow all traffic on you local are network.
(4) You should find that there’s only a handful of rules in your Firewall/Advanced/Network Security Policy (NSP). All is quiet in your Firewall/Common Tasks/Firewall Events because all outbound traffic is green-lighted by the “All Application” rule on top of the NSP.
(5) Click on Firewall/Common Tasks/View Active Connections.
(6) Look out for an application - ANY application - that identifies itself to COMODO with a mangled 8.3 DOS name (you will need to right-click one to “show full path” first)
(7) Create a new firewall ruleset in NSP, selecting the application in (6) from the list of running processes. (You will get the mangled name.)
(8) Add one rule for this process: Block all traffic from IP Any to IP Any.
(9) Move this ruleset ABOVE the All Application rule in the NSP.
(10) Observe how this application will continue to communicate with the network.
Do anything to the ruleset in (7). Pick up the application from the file system, for example, so that you will get the correct long file name. No matter. The application will continue to breathe. It gains access to the network via the All Application rule. If, per chance, you can somehow succeed and restart the application (6) such that it reports to COMDO with its LFN, then your rule will stick.
Avoid LFN rules, making by the way a better security against system partition formatting or infection:
create a specific software partition where you install your programs instead of Program Files, and make sure when you install these programs that the name you are able to give yourself to these programs has neither a blank space, neither more then 8 letters under the path.
Also note that your theory is somewhat invalid if not for folder names, at least for filenames, because it reports" Squeezebox" as not respecting 8+3 whereas it does not the same with “SqueezeSvr”, although you have there 9 letters.
“Outlook” respects this syntax, but not “Microsoft Office”.
Sorry, if I understand correctly, you are suggesting I completely rebuild my machine in such a way that, hopefully, 8.3 names will not show up again? Do you have any inkling how much WORK would be involved in doing this? How much RISK this entails? And how totally unquantifyable the chances of success of this course of action are?
Get real! Far easier to uninstall COMODO and find another firewall…
I forgot to mention: On investigating this bug, you will quite likely find that it has been reported already many times over by many different users. It is reported in a different guise. You will likely find that MOST reports of incidents where COMODO refuses to “remember my answer” to treat this application as eg a “Trusted Application” are down to this bug. In other words, you are looking at a CRITICAL feature failure in COMODO. Sometimes, people have re-installed COMODO and it miraculously resolved the problem. No surprise there since the reporting of 8.3 names v LFN seems pretty random, meaning that a reboot (rather than a re-install) is as likely to fix the issue (temporarily)…
I am not saying you should reinstall everything, altough there’s no risk involved when reinstalling applications to another partition, i have done it several times, but that it should be done on a clen installation.
I am not either advocating any bug or the responsiveness of Comodo to these bugs; i am only saying that Microsoft deliberately killed Ms Dos, and that more and more “modern” (?) systems and software, and not only Comodo, do not support LFN in Dos 8+3 mode: http://lfntools.sourceforge.net/
And that, even under old Ms Dos days, you were at risk with long names, systematically crashing them if, for some reason or another (particularly system crash) you had to use some commands (copy…) to restore the files: so, you see, the problem is not totally new…
It’s an interesting point. At long last - one has to first find the right question - I googled upon this
I immediately flicked that switch but no (immediate) joy. No surprise there, perhaps, since the switch only appears to affect NEW files. Now, clear course of action would be to copy every affected binary, whereby forcing a new file creation. A little tedious perhaps, but a lot less so than your suggestion. I am just a little disturbed by what I read from MS in response to this suggestion. Even more so when I read that on Windows 7 64-Bit (!!) there are apparently services (!!) that depend on 8.3 names.
I am now thinking of reverting this switch. I do not believe for one minute that, as you suggest, this failure by CIS to deal with 8.3 names to be a design feature. Bear in mind that I was NEVER ASKED whether I wanted CIS 4.0. My Anti-Virus puked a couple of days ago and told me that it would only continue its work if I upgraded. That’s what I did. And I had plenty of hours to regret that decision since.
Bear in mind that I was NEVER ASKED whether I wanted CIS 4.0.
I never was myself but, for sure, if i am, for the reason that make you write and many others, i most certainly shall not upgrade from v3 if i have any choice.
If you are only using COMODO for your firewall, then, good, you probably have a choice. If you are however using CIS as both your AV + firewall (like this fool here), your clock’s ticking. It won’t be before too long that the AV component will demand an update and you will have no choice but to agree.
On that note, and in case a COMODO developer reads this far into the thread, I would also like to add that I am not happy with the frequency at which the AV updates force me to reboot the system. Other AVs that I had in the past were much easier on reboots…
I wonna come back to that since it seems a potentially significant clue. I double checked and my earlier report is inaccurate. SqueezeSvr did indeed flag up in CIS as
C:\PROGR~1\Squeezebox\server\SqueezeSvr.exe
and burcine is correct in his observation that this mangling DOES NOT conform to the 8.3 convention. It strikes me as possible, therefore, that there may be a bug in the function used by COMODO to expand 8.3 names where this function will expand all path components correctly except for - sometimes - the very first one.
Just a thought. Pure speculation on my part, of course.
It also is from mine, since i don't know how and why Comodo would fetch the application path in Dos mode (and even, as is said, if i am not concerned because i have no LFN and no program lying under "Program Files").
If you are only using COMODO for your firewall, then, good, you probably have a choice. If you are however using CIS as both your AV + firewall (like this fool here), your clock's ticking. It won't be before too long that the AV component will demand an update and you will have no choice but to agree.
I am using full CIS v3 (altough i don’t think whatever antivirus is any useful), but the answer is no:
i was prompted twice since yesterday for update, i said twice “no”, and that’s it.
You could uncheck “automatic updates”, i did not myself.
But i have 2 Comodo rules, one for asking (and not allowing) CIS, the other the same for cmdagent.exe:
i am not confident in any thing, including Comodo…
It seems that the problem has previously been documented:
Version 3.0.14.276
VPN Clients can now connect to VPN servers
cmdagent.exe no longer consumes 100% CPU
System reboot no longer takes too long when CFP is installed with some other security software, e.g. avast!
CFP can now find the application behind a connection (for example Kaspersky web scanner)
"System Idle Process" is now changed to "Windows Operating System" to describe application less traffic (So no more "System Idle Process" in CFP)
Internet Connection Sharing (ICS): CFP is now compatible with ICS servers (users will be required to answer some popup alerts)
System performance has been improved
Defense+ no longer allows some applications to modify a protected file if it is not allowed
Eliminated 8.3 path conversion and its associated duplicate entries/not remembering my answer problems
One (more) v4 bug?
Other persons in this same forum report that v4 is still a “release candidate” and should not have gone to production at the time speaking.
Despite what i have said, i actually have some software under Program Files (D:\Program Files\The Bat!\TheBat.exe) and under my program partition either not obeying the path rule (“Microsoft Office”) or the 8+3 rule (E:\FTPExpert2\FTPExpert.exe, E:\FileZilla-3.3.2\filezilla.exe…) and i do not have this behavior with v3 (xp sp3 pro), so i can’t see the origin of your bug.
I don’t understand what’s going on my system either. Here’s an exercise I did earlier, using SysInternals/ProcExp:
Launch C:/Program Files/Squeezebox/server/SqueezeSvr.exe the “official” way via SqueezeTray.exe and I see in procexp “PROGRA~1/…” (bad for CIS).
Launch C:/Program Files/Squeezebox/server/SqueezeSvr.exe from explorer.exe and I see in procexp “PROGRA~1/…” (bad for CIS).
Copy C:/Program Files/Squeezebox/server/SqueezeSvr.exe to a.exe then launch a.exe from explorer.exe and I see “C:/Program Files/Squeezebox/server/a.exe” in procexp (good for CIS).
Rename SqueezeSvr.exe to SqueezeSvr-old.exe and a.exe to SqueezeSvr.exe then launch SqueezeSvr.exe from explorer.exe and I get C:/Program Files/Squeezebox/server/SqueezeSvr.exe in procexp (good for CIS).
Launch the new image the “official” way via SqueezeTray.exe and I see in procexp “PROGRA~1/…” - Arrrrghhh!!
It feels like there’s some name resolution cache somewhere on the file system that may have gone screwy for this executable? Beats me what this might be, though…
When i proceed to your test with D:\Program Files\The Bat!\thebat.exe, procexp reads the full path.
If now i run cmd.exe, making a dir/p at the root of D:, i read full names, including “Program Files” (what did not happen under win2k, i don’t remember with xp sp2).
Altough i don’t know why, your issue is therefore related not to comodo itself (or whatever other software) but with your cmd.exe command (or with some os setting, but i cannot imagine any for cmd.exe output).
The default behavior of xp and newer is full path name, as NT has no real dos mode, but only a dos emulation.
The only way to retrieve what your related would be the default interpreter (cmd.exe) being replaced either by an older version (command.com) or a “viral version” (command.exe).
If going to My Computer, Advanced, environment variables, Comspec should show
%SystemRoot%\system32\cmd.exe.
Other issues of course would be very long path names, or including ascii characters (like accents, but english speakers are not concerned), or copy from a partition to another (NTFS to FAT, external media…), but i suppose you didn’t do any of them.
Well, there are clearly two issues here:
(1) COMODO doesn’t handle 8.3 names when presented with them, for whatever reasons. Since such names are legit on Windows, it should handle them. It clearly also makes an effort: procexp shows EVERY non-conformant path component being mangled; COMODO restores every component except the first. So there is a bug.
(2) It is clearly highly irregular that a set of processes of my machine should choose to identify themselves in this manner. Why this should happen, I have no idea. And I have posted on enough forums now (MS included) that I had thought someone should by now have come up with an answer. Zippo.
I checked the environment variables and ComSpec checks out alright.
We had a power cut this morning and upon recovery, SqueezeSvr pops back as C:\PROGRA~1. I looked at MSCONFIG/startup and in there I find the 8.3 path. Trouble is that SqueezeSvr isn’t the only entry with 8.3 path and all the other processes report to procexp with their LFN. In other words, there does not appear to exist a correlation between how a process if launched and how it will report its name.
Just had a situation for the first time where SqueezeSvr would show up as “C:/Program Files” in procexp and STILL show up as “C:/PROGRA~1” in COMODO. So the analogy between the two is apparently no perfect.