Vulnerability or Works as Designed?

This is another attempt for an answer from development regarding my example below. Is this considered a vulnerability or is it working as designed?

Possible scenario: Trusted file unknowingly replaced with a key logger which has the same name. Due to the trusted nature of the original file, I was unable to block the activity that ensued.


p.s. If you do not see any images below this line, you are not logged on to this forum

[attachment deleted by admin]

Is this a hypothetical or a real world example? I would have expected the firewall to detect the differences, either by hash, size, date or whatever means.

Ewen :slight_smile:

The only additional information was that the replaced file ended up in ‘My pending Files’ as being modified which means that the file should now be considered untrusted. As you can see in my example, there were no more alerts showing up after running the modified file. Your question regarding hypothetical suggests to me that my images are fake ;D. I did run this scenario, but I guess you could still call it hypothetical. :slight_smile:

The fact remains that currently a file can be modified and it will still have the current access rights of the original file.

Al (you need to login to see attachments) Adric

Sorry Al, I didn’t even look at the images. Mea culpa …

I assumed it was something like that :slight_smile:

Ciao, Al

Hey Al,

Are you running 3.15? I’m pretty ■■■■■■ sure that previous versions would detect the change in executable, by either hash, or some other file attribute. I’d hate to think that as of 3.15 that “trust” is perpetual.

If you are running 3.15, can you log into and lodge a support ticket on this as a mettter of urgency. If you haven’t used the support centre, you will need to register as your forum credentials don’t flow through to the support centre.

Please post any feedback/results back here for the benefit of others.

Ewen :slight_smile:

I already reported the issue in a very similar situation and that was the answer of Egemen:;msg125956#msg125956

what’s worrying is that you’re saying now 3.14 would have sent alerts in such cases. I havenn’t got the setup file of 3.14 anymore, otherwise I would have tried.

No. I did not bother with that update since egemen only listed 2 fixes that were not a problem for me.
Now, i know you are going to ask me to install the greatest and latest, but before I do that, might you have some spare time to try my scenario with 3.15 and post the results with pictures?

I can post the links for cports and the key logger if you need them.


[attachment deleted by admin]

Do two support tickets qualify me as an expert support center user? :slight_smile: I just love the way tickets always come back as closed. i’ve never seen a support system like this before ;D

I did not receive any feedback to share with others other than you will hear from us. :).

Al (#LUF-526256, #WZH-885410) Adric

What is unknowingly here??? CFP is clearly telling you that a seamonkey.exe is trying to modify the contents of cports.exe.

Are you installing cports.exe? No.
Are you updating cport.exe? No.

Then it clearly says consider blocking this request. It has detected the change and could not determine if this was a legitimate change or not hence was asking you to approve.(If it could detect, it would not ask you).

Internet Explorer is also a safe application but you can download a lot of malware from internet. Just because an application is safe does not mean it can modify the files. And the security considerations section is quite obvious about this.

So if a virus tried to infect an executable, were you going to approve and tell CFP did not detect it?

CPF is clearly telling me - “This usually happens when you try to install or update an application. If you are not performing any of these operations, you may consider blocking this request.”
How would I ever be able to update cports if I can’t replace the file?

Even if I downloaded this file as a zip file, I would still need to update the original file and the only protection I have is me with only one chance to make the correct decision whether to replace it or not.

Unknowingly here means that I’ve found a new version of cports and want to update it. I have no idea that this file is not really cports. How could I?

How would you know that?

For me, this would be a legitimate change because I am unaware that I am downloading something bad disguised as a legitimate update.

How in the world am I supposed to know something bad is trying infect an executable that I want to update? How am I supposed to tell the difference between downloading something legitimate or not?

If I block it, I may have blocked malware, but I may also have blocked something legitimate. Where does that leave me?

If a file is modified and a rule for it already exists, then I would think the rule should no longer be considered valid since we are talking about a modified file. In my case, If the rule was not longer considered valid, I would have received new alerts for cport and noticed that the behavior was not what I was expecting. Your argument is that I have to make the right decision when replacing a file otherwise I’m SOL. Invalidating a rule would give me one more chance to make the right decision.

Also, i thought that files which ended up in ‘My Pending Files’ were no longer considered clean/safe. So why is cport in ‘My Pending Files’ being allowed to run without new alerts?


Al (I hope I’m not being dense) Adric

It wont do him any good. According to your scenario, the user is already aware of the update process, and he is manually updating it. CFP is asking him and he approves it. The user who approves a file modification change alert from CFP will care for “this executable has just changed” alert? He was already been a more intuitive alert and he approved it.

Also, i thought that files which ended up in 'My Pending Files' were no longer considered clean/safe. So why is cport in 'My Pending Files' being allowed to run without new alerts?

Sure. They will not be granted any “additional rights” unless approved. For example, cport.exe has a rule which allows it to make DNS queries. Now after the update, and it has been included into the pending list, if it tries to initiate keylogging, CFP will show you an alert. The keyword here is “additional access rights”.

CFP has a stateful file inspection algorithm, and it has been carefully designed. Hash keeping had multiple problems which can not be accepted in a hips like D+. For example, preventing viral infections.

However your points about “average user” having problems with understanding the alerts are valid.
We have elegant solutions coming for the next releases which should ease the decision making process for the users.

Until that time, about the file modification alerts: Unless you are installing/updating/downloading something, if some executable file is about to be created or modified by some unknown application, dont allow this if you are not sure.

Hope this helps,

I don’t agree that it will do the user no good if the rule is invalidated. If I allow file replacement, that should not assume that I know what the new file will be doing. My preference would be to treat a modified file as a new file which has no rules. I would get new alerts and possibly notice that this was not normal behavior for the modified file. I would now have the same chances for blocking a modified file as I would if the file were new. Of course, I may still make the wrong decision, but at least I had a second chance to shoot myself in the foot.

That’s only good if the original application did not have any special access rights to begin with. Why
should a modified file still be treated as a Trusted Application after I made the mistake of replacing it?

I would have a better chance at stopping the file with new execution alerts rather than deciding if I should allow its replacement. I mean, if someone downloads a file that he/she thinks is ok, why would he/she not replace the old file?

I’m not going to beat this to death and we probably will not reach an agreement on how modified files should be handled, but hopefully someone will rethink how changed files should be treated and possibly come up with a better solution.

What would the impact be on CFP if D+ were to remove existing application rules whenever that application was modified?

Maybe this would cause a whole lot of other problems. I don’t know. Something to think about.

Al (does modified=new?) Adric

Hi again,

As you see, the point we come is about “the user making a mistake”. Preventing this mistake is the real problem. There are no bounds for the mistakes of the users…You may not even have a second chance to receive a hash change alert after such an action happens…(ntoskrnl.exe can be infected - i have seen this to be attempted by malware- and no hash keeping can detect it because it is the operating system kernel on disk!). Even if you have, this would lead a lot of redundant popups for a user who is clearly not capable of answering them.

This is just an example, when you put the user factor into the equation, the solution you need to provide, will not be simple. And it is not. There will be 2 new solutions for this in CFP, and both of them are trying to address the very complex problems in computer science and security.


What are these two solutions?