What's the difference between vulnerabilities in code and vulnerabilities in virus detection? Isn't the virus detection done in code? Is security through obscurity valid for virus detection but not code?
I don't think the parent is talking about vulnerabilities, but the fact that if you know how the antivirus engine works it may be easier to write a virus able to avoid detection.
That makes sense, though I think there's still a large difference between the virus detection and ranking algorithm comparison. The entirety of the virus detection code is running on the client's PC; surely it can be reverse engineered and understood fairly successfully?
The same can't really be said of Google's algorithm, as it's essentially a hugely complex black box, and you can barely interact with it. That's kind of like reverse engineering a chip purely using its inputs / outputs.
Sounds like a vulnerability. Isn't that how the argument went about source code? "If you know how the program works it may be easier to write an exploit." But then experience taught people that exposing source code to the bright sunlight by opening its source could actually make software more secure through many eyes finding holes. Why is this not applicable to virus detection algorithms?
Now that I think about it, you have a point. In general when I think about a (software) vulnerability I think about taking advantage of some bugs or unforeseen behavior of the software. If the software is acting as intended but can not protect you from a certain kind of issue can we say it has a vulnerability ? My answer was no before, now I am in doubt :-).
>If you know how the program works it may be easier to write an exploit."
BTW, this is true. Seeing the source code versus having to go through assembly listings - I know which one I'd pick if I had to find logic bugs.
>Why is this not applicable to virus detection algorithms?
Its not an algorithm, but a heuristic. If you want to look for a suspect, you don't announce "I'm looking for someone 5 feet 5 inches tall with a buzz cut who drives a ford and wears size 12 nike sneakers". In much the same way, security via heuristics doesn't mean creating a perfect detection system, because it doesn't exist. They want to make the game harder to play by hiding the rules of the game, not because they're sure that they're going to win. This is a real, tangible benefit for the customers. There is nothing really special about it, we've been using such ideas for centuries.
>How do you build a heuristic if not with an algorithm?
I don't know what that means. Perhaps superficially there is some overlap since both run on deterministic hardware, but a heuristic is completely different from an algorithm. Its a technique that can perhaps give you an imperfect answer to the question you're asking. An algorithm describes a method, which, if followed, gives you the answer. Here is an AV heuristic that I made up just now:
-Is it encrypted? +1 point
-Does it contain self modifying/unpacking code? +1 point
-Does it call OS APIs to monitor running programs? +1 point
-Does it run at startup? +1 point
-Does it have no UI? +1 point
-Does it try to punch a hole through NAT? +1 point
-Does its process name contain random strings? +1 point
If you get > 5 points, hash the executable and send the hash/executable for analysis.
>Perhaps the entire AV model employed by Symantec is flawed.
Well, for one, the heuristic isn't the "entire AV model". But what makes you think the entire AV model is flawed? Every major OS uses parts of the AV model.
because its not that easy.
if i write some part of the code to detect if you are a good human and will you go to hell or heaven, to evaluate that for me would be hard. and if you had a access to my source code you could check what i am looking for and could maybe cheat.
the vulnerability i would call is if i sent you to hell and you found a way to escape.