CIS/CES 8 adds ADS to files which remain present if files distributed [M1367]

Comodo Internet Security - CIS Resolved/Outdated Issues - CIS
1

Is CIS 8 adding Alternate Data Streams to files ?

Can U reproduce the problem & if so how reliably?:
Everytime i download a file, extract from a downloaded archive, or compile it myself (using Delphi 7, XE2 or XE5) an ADS is added.
ADS-Scanner (ADS (Alternate Data Streams) Scanner) finds an ADS named “$CmdTcID”, reporting the size as 64 bytes. They start with “b” and here are three examples of what they look like.

b…^åDJ
b—YåDÔýVWӷлv¢AVZ5EÜSŸU¥ýêòŠŸVZ5EI•¦,ë³^TI–YåDú\3ÿ®Úüên
b3_åDTh¢ñ_

If U can, exact steps to reproduce. If not, exactly what U did & what happened:
1:Download an exe-file from Internet
2:Run ADS-Scanner
3:It reports the ADS

One or two sentences explaining what actually happened:
It was when I tried to copy a file I had downloaded, from my computer to a USB-drive, that Windows 8.1 warned me the file has properties that can not be copied to the new location. Probably because the USB uses FAT instead of NTFS as filesystem. That’s when I started inspecting my files for any hidden ADS.

One or two sentences explaining what you expected to happen:
No ADS added please. I don’t want to ship applications to my customers with any ADS attached to them, and I don’t want to have to confirm file-copying to my USB.

If a software compatibility problem have you tried the advice to make programs work with CIS?:
I Uninstalled CIS 8 and installed CIS 7. The ADS stopped appearing.

Any software except CIS/OS involved? If so - name, & exact version:
None that I can think of. The only software change made is updating from CIS 7 to CIS 8.

Any other information, eg your guess at the cause, how U tried to fix it etc:
I have asked at your forum if anyone else has noticed this problem. You can read the original thread here (some of it is repeated in this bugreport):
https://forums.comodo.com/install-setup-configuration-help-cis/alternate-data-stream-cmdtciddata-t108076.0.html

B. YOUR SETUP

Exact CIS version & configuration:
8.0.0.4337

Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:
HIPS - Safe mode
Auto Sandbox - Disabled
Firewall - Custom ruleset
Antivirus - Stateful

Have U made any other changes to the default config? (egs here.):
The ADS appear with default config too

During installation I choose to install only Firewall and Antivirus. I already have a portable version of Dragon and didn’t need it. I consider myself a geek and don’t want a buddy. :wink: I also uncheck the total of four checkboxes on the two pages of the installation wizard before clicking “Agree and install”.
I right click the Comodo tray icon
Hide the Widget
Select Advanced View

Have U updated (without uninstall) from CIS 5 or CIS6?:
No

 [b]if so, have U tried a clean reinstall - if not please do?[/b]:
 Yes on a clean freshly installed Win 7 x32 Virtual Machine, where I even get two ADS:

 1. A readable "$CmdZnID" (26 bytes) with content:
 [ZoneTransfer]
 ZoneId=3

 2. The strange "$CmdTcID" (64 bytes)

 "$CmdZnID" can be deleted with ADS-Scanner, but not "$CmdTcID"

 There is a registry setting to prevent zone-information from being created.

 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments]
 SaveZoneInformation=dword:00000001

 If I add that to Win 7 registry, then only the ADS "$CmdTcID" is created.
 On my computer (Windows 8.1 x64) I have this registry setting, which may be why I only get one ADS (still that's one too many).

 3. Yes, there is actually a third ADS, but this is windows default "Zone.Identifier", which looks very similar to "$CmdZnID" and only visible in ADS-Scanner when unchecking "Ignore safe ADS content".
 The "Zone.Identifier" can be deleted and isn't created when above registry setting is present.

Have U imported a config from a previous version of CIS:
I exported my config from CIS 7 before uninstalling it, and then imported it into CIS 8.

 [b]if so, have U tried a standard config - if not please do[/b]:
 Yes, tried that too, still get the ADS

OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
Windows 8.1 x64 is my primary physical machine.
I’ve experimented with 32bit Win XP and 32bit Win 7 Virtual Machines. ADS appears there too.

On XP the ADS is named “$CmdZnID”, only 26 bytes and readable:
[ZoneTransfer]
ZoneId=3

Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:
a=I’ve used Comodo since first public version and never looked at any other security software
b=I have disabled Windows Firewall and Windows Defender.

C. ATTACH REQUIRED FILES
The files I’ve attached are from a fresh install of Windows 7, 32bit. Only CIS 8.0.0.4337 installed.

[attachment deleted by admin]

2

Many thanks for your excellent bug report in standard format.

I can replicate this issue

Moving to format verified, and logging in the tracker

Best wishes

Mouse

3

BTW this of course may be by design, but you are right, CIS should have a way of suppressing this or fully respect the registry setting.

I will be interested in the devs response. Certainly if it happens with 8.x and not with 7.x it is likely to be CIS.

Lets see what they say…

Mouse

4

Using Procmon I can see that $CmdZnID and $CmdTcID are created by “cmdagent.exe”.
When trying to delete the two ADS with Streams, only $CmdZnID gets deleted.

I had a thought that the “Tc” part of $CmdTcID had something to do with “Trustconnect alerts” in the Firewall Settings of CIS. But having that box checked or unchecked doesn’t matter.

Maybe it’s simply some internal code used for debugging by Comodo developers that has accidentally remained in the released application.

5

Thanks that confirms it then.

I am wondering if the $DATA field is the correct length for a hash.

Logically CIS would need to know that the file (the main stream of the file to be precise) remains the same one that was downloaded. That information would need to stay with the file, so if it is copied or moved the info remains.

It might also need to know that the ZoneId had not been artificially changed. But I don’t think (not sure) from my experiments it tracks this.

It seems that changes to ADS do not effect the signed status of the file. Maybe what is signed is the executable stream.

6

Mouse1, I notice you changed the topic subject when moving this topic to “Format verified Issue Reports”, and I think the new subject might be a bit misleading.
As I mentioned in the bug report $CmdZnID (which sounds and looks like a Zone Identifier) doesn’t get created when the registry setting is set. So that works. $CmdTcID on the other hand is probably not a Zone Identifier, and that may be why the registry setting doesn’t affect it. $CmdTcID is created even when I copy files locally, extract from archives, or compile them myself. Things that doesn’t normally add a Zone Identifier. In short, $CmdTcID is something evil. >:-D

My experimenting has concluded that $CmdTcID can’t be deleted by ADS removers until CIS 8 has been uninstalled. For whatever purpose CIS 8 is using the ADS it doesn’t want to let go of it.

I have now restored my system partition from a backup made the day before I updated from CIS 7 to CIS 8. Further testing by me will be performed in virtual machines, where the problem is confirmed to exist too, until this serious bug is solved and we can go back to living happily ever after. :smiley:

FYI, there has popped up a new thread about this issue.

Hope we hear some good news from the developers soon. :slight_smile:

7

OK I was seeking a way to clearly describe this as a bug. From what you say it may be fully intended.

Maybe there should be a wish to be able to turn this off.

I will change the title again if we can work out how to describe it as a bug.

One thought is that maybe it relates to trust connect via intranet zone support. I note that Windows does not persist intranet zone ids, maybe Comodo wants to for trust connect. Possibly then this is a Comodo intranet zone ID.

8

OK, I understand how you were thinking. Before we can come up with a better topic we almost need to know if the ADS is intentional or unintenional…
I agree with you that if it is intentional we would like a setting to turn this feature off. And if it is a bug we would like it fixed.

9

I have thought of a different subject: “ADS $CmdTcID created by cmdagent.exe causes problems”, or is that too vague ?
We don’t know which priority this bug has, and don’t want a change of subject to give it less priority.

10

Bit vague I think I have seen this in CES as well so I will validate that, which will enable me to make the commercial point about software or indeed document distribution.

11

Confirmed here on my system.
One thing I’d like to add: in case of file being moved from an external drive to the system drive, the addition of such ADS alters the timestamps of said file (in particular, the Time Created one). This becomes a problem to backup utilities that rely on timestamps, because a file is marked as changed even if not.

Such new “feature” of CIS should be disabled by default, because it creates more problems than it solves.

12

Phillip Cooper, thank you for the valuable observation. I’ve linked your comment in the tracker.

Thanks again.

13

It seems that also JavaScript (*.js) files

  • in addition to all the Portable Executable format file types
    (*.cpl, *.exe, *.dll, *.mui, *.ocx, *.sys, *.scr, *.drv, *.efi, *.fon)
    are getting the $CmdTcID treatment from CIS 8.

Regarding the possibility of it being a hash;
of the 64 bytes / 512 bits in total, there are some parts that are clearly not a part of any hash…:

byte 00-03 are always 62EE8A9F
byte 16-23 are always B0A78C43565A3545
byte 32-39 are always 81F28A9F565A3545
byte 60-63 are always ABA2FCEA

byte 07 is always 44
byte 55 is always 44

bytes 04-07 are always equal to bytes 52-55

bytes 26-29 seems(?) to always be **9F55A5

If I should guess, then…

the 64-bit value of bytes 08-15
the 64-bit value of bytes 40-47
the 32-bit value of bytes 48-51

…any hash - or, if not a full cryptographic hash, at least a checksum

  • would have to be located somewhere in those values.
14

To expand on what Phillip Cooper noted about updated timestamps, the following behavior is seen on my Win7 x64 system only when Comodo v8 is installed:

Essentially, all executable files being freshly introduced to the local Comodo v8 system are being time-stamp “touched” with the current system time:

  1. If I extract executable files (.exe, .bat, etc.) from a local archive using an archive manager such as 7-Zip, the extracted file’s “Date Modified” time-stamp is updated to the current system time. Non-executable files such as .txt or .pdf are left with their original time-stamps intact. If I use the Explorer’s built in “Compressed (zipped) folder” manager for .zip archives, the time-stamps are left alone for all files (as I believe they’re being treated as part of the local Explorer domain.)

  2. All executable files copied from a local networked source are time-stamp “touched” to the current system-time. However, once they’re on the local drive, if I copy them a second time from the networked source over top of the 1st local copy, the original time-stamp is preserved (as though they were now considered local-trusted and required no re-assessment.) Non-executable files always come across with their original time-stamps intact.

My basic settings are Comodo Proactive Security configuration, with Firewall/HIPS only (Antivirus component not installed.) Custom Ruleset for Firewall, HIPS active with Clean PC Mode, Auto-Sandbox Disabled. Diagnostics checks as fine.

Apparently Alternate Data Streams are being attached to the “newly introduced” executable files and, in the process, are additionally updating the files’ time-stamps. This is a critical issue for me, which forced me back to v7 of Comodo which doesn’t have this issue.

15

I had left out another category that this affects:

  1. Application Installations - the executable-type files installed into the program and system folders (eg drivers) are all ADStreamed and time-stamp updated as well, rather than retaining the original time-stamps of the developer. This would include Windows Updates! This is a vast impact to a system, and not in a good way.
16

Could you explain what you mean with vast impact, and not in a good way?

17

Yes - you might as well not have file time-stamps if they’re going to be overwritten with inaccurate data. We’re talking about 1000s of files that will eventually be updated, including Windows Updates, Program & System files. Time-stamps are important for many uses, not the least of which Phillip Cooper mentioned regarding their use in some backup utilities. Time-stamps are often used to assess file versions and time-stamps can sometimes be taken into account when forensically tracking malware incursion substitutes (legitimate system files have a particular time-stamp for a particular version.) Since only executable-category files are updated, application file-set time-stamps will be artificially inconsistent - and it will be especially more difficult to assess versions and version-sets on those files that don’t contain version information, where you would normally instead rely on the time-stamp for assessment.

In the week that I had Comodo v8 on my system, it resulted in quite a few fresh installations for which, after becoming aware of this behavior, I felt it was best that after v8 removal I go in and remove the Alternate Data Streams attached by Comodo v8, and then uninstall/reinstall all the impacted applications to avoid any repercussions to my system, foreseen or otherwise. All these ADStreams are effectively “noise” which makes it that much harder to track legitimate (or malicious) data streams in the file system. I’m just glad I became aware of the source prior to Windows Update Tuesday.

I’m sure there are other issues with this behavior, and when they’re discovered it may be too late to recover fully because, as I said - vast impact on the system (1000’s of inaccurate time-stamps and ADStreams - that’s vast.) Developers may use app file time-stamps in an unpredictable way which may lead to unforeseen headaches, corruption and troubleshooting. Personally I don’t see how this can possibly be seen as anything short of disaster waiting to happen. I’d rather take my chances with no protection than this kind of “protection”. Everyone’s priorities are different, but that’s my take - and to me, executable file time-stamps are a critical part of the system and its assessment. These aren’t user data files, they’re app & system files, and should not be tampered with. Doing such is a very bad idea, whether this behavior is intentional or not, and with the predictable unpredictability I would advise anyone who delves very far into their system files or uses any less than fire-tested broad-spread commercial apps to avoid Comodo v8 like the plague unless this behavior is changed.

18

I was concerned about this when I first heard that Comodo was using ADS, but Comodo seemed to be using the Windows-applied Zone.Identifiers, which as you say do not seem to change dates modified. Star Group analyzed (by trial and error) how this was working in some detail, and the Windows applied Zone.ids seemed sufficient to explain observed behavior of origin based rules.

We of course did want to know for sure, so we did request information from Comodo about how the origins concept actually works, but I am afraid never received it, despite many requests, so I cannot help with further information about the additional (non-windows) ADS. I guess this was understandable given security considerations.

Just to check, are you sure about the extent of the problem? There is a known bug in which files unzipped by 7z and some other archive managers appear to get their Windows applied zone id removed in some way, so I can see that that might change dates modified. Is it possible that what you observe is being caused by third party unzipper modules like 7za.dll (which are often included in non-commercial installers). There are also necessarily issues when files are copied from non-FAT drives, as they cannot have Zone/ID and so must necessarily be assumed to come from an untrusted Zone.

Incidentally please note that Windows itself does not seem to apply persistent Zone 1 and 2 identifiers. And that Zone 4 ids can only be applied if standard browser security settings are modified, and files with it get treated under the ‘any’ origin. (Both reported issues). It might be thought that the Comodo Zone.Ids/Tc ADS are to plug the Zone 1/2 gap, but I don’t think so as have not been able to get the intranet zone rule setting to trigger at all. Maybe someone else can.

I thought they might be a way of establishing a reliable link between the file hash and its zone id but the further comments above do not seem encouraging in this respect, though maybe there is room for a short hash or CRC of some form. Maybe they are an anti-malware-tampering measure?

19

I can confirm about the change of filetime stamps…:

Yesterday, with CIS 8.0 installed, I downloaded this file
http://www.rarewares.org/files/mp3/lame3.99.5.zip

I opened it up with 7-Zip, dragged out all the files and saved them into a folder.
Comodo CIS 8.0 created a $CmdTcID for only 1 of the 35 files in this archive;
the one and only *.exe file that was inside:
“lame.exe”

The original filetime created, modified & accessed, when seen within the archive, is 2014-05-22 15:22:06
When looking at the file that was saved into the folder,
the filetime created, modified & accessed, had now became 2014-12-08 13:51:03
i.e. the current time when the file were saved.

Of the 35 files in this archive, only this one file, lame.exe,
was given a $CmdTcID ADS, and had the filetime changed.

Now today, after uninstalling Comodo CIS 8.0,
then doing the exact same thing…

  • dragging out all the 35 files from lame3.99.5.zip and saving them into a folder
  • leaves the original modified filetime of lame.exe intact.
    Filetime created and accessed is both current time, as usual,
    but filetime modified is 2014-05-22 15:22:06
  • exactly the same as seen in the archive.

So, there is no doubt whatsoever that the adding of the $CmdTcID ADS
also changes the filetime modified,

  • it is set to the current time when the ADS is created.

That said, there should not be any particular need for this to happen

  • unless it is by some - rather strange, IMO - design.
    As have been stated earlier, it is possible to both create and delete ADS’es
    without any change to the filetime modified stamp.

On another note:

It seems that…

  • in some cases, it is only the *.exe files that are getting the $CmdTcID ADS
    (just as in the example above. The “lame_enc.dll” file did not get any $CmdTcID ADS, only the “lame.exe” did.)

However, in other cases, all the filetypes of the Portable Excecutable format get $CmdTcID ADS’es.
E.g., I see that on 2014-11-12, there was a large Microsoft monthly update, and Internet Explorer was one of the programs that was updated.
Here, both…
*.exe files: ieinstal.exe, ielowutil.exe, iexplore.exe
*.dll files: DiagnosticsHub.DataWarehouse.dll, DiagnosticsHub.ScriptedSandboxPlugin.dll, DiagnosticsHub_is.dll, DiagnosticsTap.dll, F12.dll, etc.
*.mui files: DiagnosticsTap.dll.mui, F12.dll.mui, F12Resources.dll.mui, F12Tools.dll.mui
…all these filetypes (all are “PE” Portable Excecutable format filetypes) got $CmdTcID ADS’es.

Additionally, I see *.js files (in Temporary Internet Files\Content.IE5*),
*.torrent files,
*.zip files,
*.sys files: the C:\Windows\System32\win32k.sys file was also updated in that 2014-11-12 bundle

  • all of these also have got $CmdTcID ADS’es from CIS 8.0.

And while the most of them have also got all the 3 filetimes (created, modified, accessed) set to the same time (current time of the ADS creation)

  • there are some - those in the %TEMP% folder it seems,
    that have filetime created and accessed intact, and only have filetime modified set to current time of the ADS creation.

I agree with rChaz that this is not a good behaviour…
If it had been an opt-in (a.k.a. “default = OFF”) option,
so we could have made an informed decision about
whether we would want to turn it on, or not…
now, that would have been something completely different.
But this forced approach, in addition to the “no possible way to turn of File Rating”
makes me understand that the current CIS is not suited for me.
There are just too many controls missing.
I know, I know, ease of use & the average user,
and all bad stuff MUST be stopped no matter what, etc. etc…

  • I really believe that > 90% of the CIS users are perfectly OK with this. :wink:
    I used CIS 5.3, updated to 5.12 for many years,
    but in reality, since I had all non-firewall options turned off,
    I could have just used CFW.
    (Yeah - I don’t have any need for real-time anti-virus,
    they’re just annoying to me with all their false positives.)
    The thing was, back in 2010, I downloaded and thought I installed CFW, but it became CIS anyway
  • since I did not pay good enough attention to the installer…! 88)
    But today, I understand the trick
  • all the Comodo installers always contains all the packages,
    (e.g. all the 3 CIS 8.0, CFW 8.0, CAV 8.0 packages are all 212 MB large)
    and so you have to just make sure you remove any checkboxes for Antivirus etc. packages
    when you do the installation.
    I really love the Comodo FireWall though :-TU :-* :-TU :-* :-TU
  • I have been using it since v3
  • and the v8 is much better than the v5 I used earlier,
    so I will install the CFW 8.0 as soon as I am sure I have got rid of all the registry entries left from CIS 8.0.
20

Oh NO…!! >:(

After I had uninstalled CIS 8.0 and re-booted…
I thought that I should be able to remove all the $CmdTcID ADS’es
…but there were only a few streams that were possible to remove.
The ones in C:\somefolder\ were possible to remove.

However… the $CmdTcID ADS’es in folders under

C:\Program Files\Internet Explorer
C:\Program Files (x86)\Internet Explorer
C:\Windows\System32
C:\Windows\SysWOW64
C:\Windows\winsxs\

…these are not possible to remove with the “AlternateStreamView” from NirSoft

The “Streams” from SysInternals does not even see them

LADS - List Alternate Data Streams from Heysoft
http://www.heysoft.de/en/software/lads.php

  • it sees them, but have no option for deleting any (it only LISTS ADS’es)

Does anyone know any way to get these removed,
except for the “move file to a FAT volume and back to NTFS” trick…?