Linked by Thom Holwerda on Thu 24th Jul 2008 22:04 UTC
Thread beginning with comment 324516
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
What is so hard about UAC running an md5 against the exe file in question.
IT'S NOT POSSIBLE!
First example:
1. user executes destroy.exe: UAC prompt, user clicks on "always consent"
2. malware executes destroy.exe, no prompt because the exe is the same.
-> you're pwned!
Second example:
1. user changes a firewall rule: UAC prompt, user clicks on "always consent"
2. malware changes a firewall rule, no prompt because the firewall configurator executable is the same.
-> you're pwned!
Third example:
1. user copies a file in c:\windows using windows explorer: UAC prompt, user clicks on "always consent"
2. malware copy a trojan in c:\windows, no prompt because the copy command executable or the explorer.exe is the same.
-> you're pwned!
Edited 2008-07-25 08:31 UTC
What is so hard about UAC running an md5 against the exe file in question.
IT'S NOT POSSIBLE!
First example:
1. user executes destroy.exe: UAC prompt, user clicks on "always consent"
2. malware executes destroy.exe, no prompt because the exe is the same.
-> you're pwned!
IT'S NOT POSSIBLE!
First example:
1. user executes destroy.exe: UAC prompt, user clicks on "always consent"
2. malware executes destroy.exe, no prompt because the exe is the same.
-> you're pwned!
Incorrect. End user loads it once, knows that it is an application he or she wants to use on a constant basis - heck, it could be their very own application they've written.
If you do an md5, compare the result of the stored one to the one done at the execution of the application - if malware has through some way replaced the legitimate file with something bad - the md5 comparison will fail and a warning along the lines of "exe has failed security check, file possibly compromised, excution haulted".
Second example:
1. user changes a firewall rule: UAC prompt, user clicks on "always consent"
2. malware changes a firewall rule, no prompt because the firewall configurator executable is the same.
-> you're pwned!
Third example:
1. user copies a file in c:\windows using windows explorer: UAC prompt, user clicks on "always consent"
2. malware copy a trojan in c:\windows, no prompt because the copy command executable or the explorer.exe is the same.
-> you're pwned!
1. user changes a firewall rule: UAC prompt, user clicks on "always consent"
2. malware changes a firewall rule, no prompt because the firewall configurator executable is the same.
-> you're pwned!
Third example:
1. user copies a file in c:\windows using windows explorer: UAC prompt, user clicks on "always consent"
2. malware copy a trojan in c:\windows, no prompt because the copy command executable or the explorer.exe is the same.
-> you're pwned!
If you are going to compare, don't be dishonest and quote only the first half; the issue was addressing a specific question; the specific question was a specific executable file. It didnot involve file copying, it didn't involve anything else. It involved running one piece of software and the contious asking whether its ok to run it because it isn't signed.
The issue has NOTHING to do with UAC, because it isn't UAC querying the end user. This security check exists on Windows XP to; if you choose to run something downloaded via the internet from the download window - when one clicks on 'open', one is faced with the same question.
Edited 2008-07-25 09:36 UTC





Member since:
2005-07-06
[q]The reason why you can't say "yes, and don't ask me again" is because the next time it comes up, it might be caused by something malicious.[/quote]
Did you read the whole request, he wants it on a per-application basis. What is so hard about UAC running an md5 against the exe file in question, store the result of that exe so that the next time it is loaded it is just a matter of a quick check against the stored md5 to see if it is the same exe - and allow the application to run?
Geeze, I thought of a solution just then that addresses the fundamental problem and the perceived security implications in under a minute. It isn't rocket science - just good old fashioned commonsense.