application rules now required for non-process data files?

For very many years I have been running certain Scheduled Tasks at night on my Windows XP machines. The tasks are based on custom scripts written in Perl. In recent years I have been using the firewall component of CIS as well. After giving perl.exe permission for outgoing TCP, CIS gave me no problem with these nightly tasks.

Here is the sort of single-line command issued by Scheduled Tasks:

C:\perl\bin\perl.exe D:\scripts\task.pl

As with all executed commands in Windows, the first argument is the executable and everything thereafter are just program-specific arguments. In this case, there is a filename argument referencing a text file containing script, although that is only the business of the user and the perl.exe program. CIS quite rightly knew nothing about the text file and concerned itself only with the perl.exe executable because that is what becomes the actual process. Note that when perl.exe runs a script, the process list will show perl.exe and no child process named task.pl because task.pl is not an executable or process at any time. In essence, task.pl is a data file.

Suddenly with CIS v5.3.176757, the nightly scripts are not running. Why? Apparently, when the new CIS sees a command like the above, it’s now presenting a popup requesting Internet access on behalf of task.pl, the non-executable text file! Of course, there is nobody around at night and the popup disappears and the script was unable to send out an alert email as it is coded to do for all other error conditions. One can only know this has happened long after the fact by checking the CIS log.

This is a major change! CIS is parsing command lines and selectively choosing to not only pretend certain types of text files are executables but to ignore the application rules that have been assigned to the actual executable that is running. My perl.exe application rules suddenly no longer apply and I am forced to devise new application rules. That is wildly inconsistent and unpredictable by anyone who knows what a “process” is >:(

A major new “feature” is added that drastically changes how certain types of existing application rules are interpreted and this deserves not even a hint in the release notes?!? ???

I searched everywhere for a hint from Comodo about this change, but found nothing. I did run across a lot of unprofessional ranting by Comodo’s CEO about Bob-somebody, something about how all other AV software vendors are criminals, and how something called DACS represents the CEO’s milk of human kindness and concern for all mankind. What a disconcerting and disturbing picture of Comodo that little detour was!! :o

So I have a suggestion. When you folks at Comodo have some spare time, how about starting a habit of publishing up-to-date release notes that actually cover the major changes made to CIS? And when you make a change that affects how existing application rules are interpreted (or get newly ignored), how about taking the time to warn the users? I think it is a design flaw to treat as processes things that are not processes, but not telling us about the new inconsistency makes it worse. I am now wondering if I should be expecting alerts regarding *.bat, *.doc, *.pdf, and other non-process files. ???

I agree 100%, MrsPeel. Comodo should have reported this to users.

I also think this kind of parsing should be removed, as it’s probably trivial to pass in a command line argument that means one thing to CIS but means something else. This is just one of many examples (ret-to-libc protection being another) of security software intruding into the wrong abstraction layer. CIS has no right to be looking at command line strings.

CIS is not parsing your command lines nor is it ignoring application rules; what it is doing is seeing that a file is being run through an interpreter and treats that file as a separate executable (which it is since it’s essentially turning the interpreter into a different program). As with any native executable interpreted files now need to be added to the whitelist and/or have their own application rules.

This change provides better against non-native attacks such as the ever-popular Java exploits. With the previous implementation the interpreter had the same level of trust no matter what and would only cause an alert if it performed behaviour that was suspicious or forbidden by the application rules; with the new implementation the interpreter’s trustworthiness is ignored and the interpreted file is untrusted by default so any actions it tries to perform trigger sandboxing or alerts or whatever you have set up.

Application rule handling has not changed at all; what has changed is that files running through interpreters are now treated as separate executables and so need their own rules and/or whitelisting.

According to the release notes this feature was introduced in Version 5.0.163652.1142: “Heuristic detection identifies real file behind requests of “interpreter” applications”.

This monitoring only applies to files being run through an interpreter; opening that same file in a viewer or editor or whatever will not trigger any warning or blocking or whatever since that program is not trying to run the file.

Anyway, I hope that makes things a bit clearer. :slight_smile:

Would you care to explain how CIS determines if a program is an “interpreter”, and how it determines if a file is being used by the program in that way? You have not provided a very convincing argument - it’s far more likely that it’s parsing the command line.

With the previous implementation the interpreter had the same level of trust no matter what and would only cause an alert if it performed behaviour that was suspicious or forbidden by the application rules; with the new implementation the interpreter's trustworthiness is ignored and the interpreted file is untrusted by default so any actions it tries to perform trigger sandboxing or alerts or whatever you have set up. Application rule handling has not changed at all; what has changed is that files running through interpreters are now treated as separate executables and so need their own rules and/or whitelisting.

And how is the data that goes through programs any of CIS’s business? This whole thing is just awful.

Nothing is wrong about it @ all , haven’t you ever crossed any malware that uses a .bat file to delete some critical system racecourses ? , the protection will be easily bypassed then if CIS doesn’t distinguish that the cmd was called from an unknown process. Just have a look at the same thing in other security vendors , as far as I know, kaspersky will just alert u, if you switched to interactive mode of course, that cmd will do this and that, however, with CIS it’s a bit different and I found it more convenient since u know exactly the file that was responsible for such a call and thus taking the appropriate actions will be far easier. And of course its CIS’s business to intercept any action that could harm the system < I doubt if that’s even a valid argument here especially in security :-\ < unless I got something wrong, please forgive me then.

And I don’t see a secure way of determining which file cmd or whatever other “interpreter” program is using as its script file.

And of course its CIS's business to intercept any action that could harm the system < I doubt if that's even a valid argument here especially in security :-\ < unless I got something wrong, please forgive me then.

Allow me to use a ■■■■■■ political analogy.

Imagine if in some country people from a lot of different cities are planning an attack on some important building, and they are using the internet to communicate. Is it the government’s business to be censoring the Internet in order to block these communications? No, because it’s at the wrong abstraction layer. It’s difficult to identify the target content. You will always let things slip through, and you will always block the wrong things. Instead, what the government should be doing is guarding the building itself. If websites want to employ dedicated censorship staff, then they are free to do that.

Imagine if in some computer a malicious script is trying to take over the system, and it is using an interpreter program like cmd. Is it CIS’s business to be looking at what files cmd reads and trying to determine what cmd is doing with those files? No, because it’s at the wrong abstraction layer. It’s difficult to identify what cmd is doing internally. You will always let things slip through, and you will always block the wrong things. Instead, what CIS should be doing is restricting what cmd can do (e.g. can’t directly access disks). If in the future cmd implements special access control features, then it is free to do that.

Welcome to Comodoland MrsPeel.

CIS has no right to be looking at command line strings.

I agree, as a HIPS it has an obligation to do so. Interpreted programs are programs, they can upload your stuff on malicious websites.

If you think your perl programs are safe, create a group and grant them appropriate permissions.

I also think this kind of parsing should be removed, as it's [b]probably[/b] trivial to pass

No.

The release notes indicate that it’s done using heuristics, although I’d imagine there is specific support for well-known ones as well. I’ve seen interpreter file sandboxing when using GUI-based execution, although for all I know the GUI is accessing the file in a way that is comparable to command line entry anyway. You’d certainly know more about that than I would. :slight_smile:

Either way the end result is that CIS can see that Program X executed File Y with Parameter Z, which isn’t exactly the most sensitive information.

For the purposes of security interpreted files are executables, not user data. They can do everything a native executable can, so CIS treats both types with an equal level of suspicion. You may well have written them yourself and consider them to be your personal user data, but if that’s the case just add them to the whitelist and CIS will leave them alone.

CIS isn’t watching what the interpreter does, CIS is watching what the interpreted file does as if it was a standalone executable. Interpreted files have their contents wide open for heuristic sniffing, and over time the antivirus will get better at heuristically detecting suspicious behaviour in interpreted files before they even get a chance to be executed, just like how well it does right now for native executables. Behaviour that is obfuscated in the source can be difficult to spot heuristically but can be caught by Defense+ when the behaviour is actually initiated (if it isn’t blocked entirely by sandbox limitations).

… And CIS is doing just the same , it protects the protected files and registry, which are the buildings in your analogy, from being modified by unknown files and prevents the unwanted connections by offering you to block the scrip or whatever is using the trusted file from being able to connect to the internet rather than blocking the whole interpreter or/and killing it :wink: < I think that’s an advantage and I haven’t faced any disadvantage of this feature during my usage of CIS.

@ MrsPeel

Did you not notice this behavior with V5.0? In this regard I believe the behavior of V5.0 and V5.3 should be identical.

As Arkose mentioned this new protection was introduced in V5.0. This was done because files run through a trusted interpreter will be trusted as well. There was even one example in which someone made one that was able to uninstall CIS without triggering any popups.

This particular protection layer is very important.

Agreed. Comodo could really improve in this area. As soon as a new version is released there should be up to date release notes as well.

This change was noted in the post in which they first released CIS V 5.0. In fact if you check the release notes it is noted that

NEW! Heuristic detection identifies real file behind requests of “interpreter” applications

I hope your questions have been answered.

Apparently the change was in the change logs. May be in a bit cryptic fashion. However, I couldn’t help but notice you applied a big update (going from v4.x to v5.x) on a live production environment without first testing it… :o 88) ??? That’s not Comodo’s shortcoming…

Welcome to pc-pete land, too. 88)

This was done to capture malicious scripts (perl, python, etc.). Prior to this being introduced, if a malicious script was inserted into your system and it was run by a trusted application, any actions of the script were similarly considered trusted. Consider the implications of a script that contains “echo y: format c: /q /u” and then running this under a trusted interpreter.

A major new "feature" is added that drastically changes how certain types of existing application rules are interpreted and this deserves not even a hint in the release notes?!? ???

This was disclosed in the release note for Version 5.0.163652.1142: “Heuristic detection identifies real file behind requests of “interpreter” applications”.

I searched everywhere for a hint from Comodo about this change, but found nothing.
So I have a suggestion. When you folks at Comodo have some spare time, how about starting a habit of publishing up-to-date release notes that actually cover the major changes made to CIS?
I am now wondering if I should be expecting alerts regarding *.bat, *.doc, *.pdf, and other non-process files. ???

If you don’t wanted interpreted scripts to be parsed by Defense+, open CIS, click DEFENSE+ → DEFENSE+ SETTINGS → EXECUTION CONTROL SETTINGS and turn off “Do heuristing command-line analysis for certain applications”.

Ewen :slight_smile:

Please define the term “execute”, and how CIS is supposed to detect this. No new process is being created.

, which isn't exactly the most sensitive information.

I’m not talking about privacy, I’m talking about abstraction layers.

For the purposes of security interpreted files are executables, [b]not[/b] user data. They can do everything a native executable can, so CIS treats both types with an equal level of suspicion.

No, you are getting this mixed up with semantics. Programs don’t open files and say to the OS, “Hey, I’m going to ‘execute’ this file! Why don’t you magically take care of the security issues!” All the OS (and CIS) sees is that files are being opened, and data is being read. The rest is up to the program itself.

CIS isn't watching what the interpreter does, CIS is watching what the interpreted file does as if it was a standalone executable.

Files don’t do anything. If a process isn’t being created from an image, then no file is being “executed” from the point of view of the OS and security software.

Answer this for example. An interpreter program accepts scripts from stdin. If I originally have a script file and I split it into two files, I can redirect the two files (in order) into the program using the command prompt. What file is being “executed”?

I believe that there are specific interpreters that CIS is aware of and monitors the loading of scripts into these apps.

Yes, but I don’t see how CIS can monitor this securely. What about the question at the end of my last post?

:slight_smile: It seems that you want to know how comodo is doing it , well we all know that not any1 could answer that but a developer and that " may or may not " happen and if not that’s their right. However, I’m curios about the term " securely " ?

Yes, but I don't see how CIS can monitor this securely

can you please define it ? < I’m naive and I want to learn something.

I believe that all parameters fed to the interpreter are parsed, but I’m not 100% certain on this. I’ll see if I can find out for you.

Ewen :slight_smile:

It doesn’t really matter how they’re doing it, because it’s impossible for them to be doing it correctly as I explained previously.

can you please define it ? < I'm naive and I want to learn something.

“Securely” means that it can’t be faked.

I believe that all parameters fed to the interpreter are parsed

In my example the command line string is not relevant.