from the article:
But could the industry have solved the problem of file infectors in an elegant, definite way? The answer is yes and we all know the solution – digital signatures for executable files. Right now, most of the executables (but unfortunately still not all) on the laptop I’m writing this text on are digitally signed. This includes programs from Microsoft, Adobe, Mozilla and even some open source ones like e.g. True Crypt.first things first - this is essentially a whitelist technique (with the added bonus that the cryptographic component allows the proof of whitelist membership to be shipped with the file instead of requiring a lookup in a very big list) with all associated fundamental problems... think the problem of signing all good programs is small and will probably be solved? maybe for suitably large values of small... if you're going to focus on identifying good files instead of bad ones you have to keep in mind that the good files outnumber the bad by orders of magnitude and grows at an even faster rate... conceptually signing all good programs is simple, but in practice it's very, very hard...
With digital signatures we can "detect" any kind of executable modifications, starting form the simplest and ending with those most complex, metamorphic EPO infectors as presented e.g. by Z0mbie. All we need to do (or more precisely the OS needs to do) is to verify the signature of an executable before executing it.
I hear all the counter arguments: that many programs out there are still not digitally signed, that users are too stupid to decide which certificates to trust, that sometimes the bad guys might be able to obtain a legitimate certificate, etc...
But all those minor problems can be solved and probably will eventually be solved in the coming years. Moreover, solving all those problems will probably cost much less then all the research on file infectors cost over the last 20 year. But that also means no money for the A/V vendors.
but let's assume we do solve that problem... so if the file isn't signed then it doesn't run and if the file's signature is invalid then it doesn't run... the presence of a valid signature is assumed to mean that the file is a) not bad and b) hasn't had anything bad put into it after signing, but is that a valid assumption? given that mobile spyware can get digitally signed by symbian, i think not, at least not for the first part of the assumption... currently digital signatures like the ones joanna holds up as examples are meant to prove authenticity, not safety... putting the onus on the signatories to determine whether the code they're signing is safe doesn't solve any malware problem, it just offloads it onto the signatory... this is also not a small problem: distinguishing good from bad is and always has been the problem and offloading it onto someone else doesn't make it any easier to solve...
the second part of the assumption, that verified signature implies nothing bad has been put into the file, may well be true, assuming that the verification system itself hasn't been compromised... the digital signature proves authenticity and one of the prerequisites for authenticity is integrity and that's really the underlying ingredient here - managing system integrity... any application whitelist worth it's salt already keeps track of the integrity of the executables on the whitelist, otherwise it would be trivial to fool it by simply replacing a whitelisted application with a piece of malware with the same filename... but as yisreal radai showed in his paper "integrity checking for anti-viral purposes: theory and practice" (sorry, no suitable non-vx links at this time), systems that detect changes to the integrity of files are subject to attack and one based on digital signatures is no different... the signing key could be stolen (there's been malware designed to steal cryptographic keys in the past) and then generating valid signatures for infected files would be trivial, the key used to verify the signatures could be altered (either on disk or dynamically in memory) by a malicious process that has already been signed, or if the system allows adding new keys then one could be added maliciously that would allow the files to be modified (infected) and then resigned with the new key to trick the system into thinking the file's integrity is intact... in fact, taking a cue from the developers of stealth technology under windows, one could simply change the result returned by the signature verification function... in order to be immune from attack, an integrity checking system has to be offline and out of reach of the attacker, and that's not compatible with a system that checks integrity in real-time to prevent modified files from running...
of course there are other problems too... it's not just deciding what to sign, ensuring the signatures are themselves trustworthy, and finding the resources to sign every good program in existence... there's also the classic whitelist problem of deciding what to do in an environment where programs are being created (or even what's a program in the first place)... are we going to digitally sign word documents? yes? ok, and will that stop macro virus infection? no of course not... there are plenty of macro viruses that infect a document when the document is saved - a point at which a new digital signature would have to be created anyways... then when the person we send the document to opens it the virus runs and then proceeds to infect documents that person creates or modifies (and then signs) and so on and so on...
again, from the article:
So, do I want to say that all those years of A/V research on detecting file infections was a waste time? I’m afraid that is exactly what I want to say here. This is an example of how the security industry took a wrong path, the path that never could lead to an effective and elegant solution. This is an example of how people decided to employ tricks, instead looking for generic, simple and robust solutions.unfortunately a digital signature based whitelist is no elegant solution either... whitelisting for anti-viral purposes dates back at least as far as thunderbyte anti-virus and there have always been ways to manually check the integrity of transfered files to make sure they haven't been altered from what original vendor was distributing by using crc's, hashes, and even digital signatures... a digital signature based whitelist makes certain aspects of usage a little more convenient, but it doesn't mitigate the inherent problems of a whitelist...
joanna may have wanted to use this to demonstrate the way security solutions ought to be in an ideal world, but the world is not ideal, and the virus problem as well as the many varied ways of addressing it are not as simple as she portrays them... thus her example of security gone wrong has no legs... in the real world there is a counter-measure for every protective measure, and elegance (subjective as it is) cannot be the basis upon which the measures we take are judged...
6 comments:
You know what's funny? Both you and Joanna are right - and both of you are missing the point. :-)
The truth is that digital signatures will help reduce the malware problem. No, it won't eliminate it. But it will be better than it is now and wide use of digitally signed executables won't hurt, so it is worth doing.
Yes, signed malware for Symbian S60 R3 exists - one of it, compared to the hundreds of malware programs for Symbian S60 R2. And no viruses. Not saying that viruses will be impossible - somebody can probably get a virus signed once, and a server-based viruses that spreads as instant messages (no code) is probably possible. But viruses won't be a problem for this environment.
And the macro side is already solved. Since Office 2000, the applications ignore by default macros that aren't digitally signed with a key trusted by the user. Wonder why macro viruses are no longer a problem? ;-)
Yes, it's not a panacea. It doesn't make malware (or even viruses) impossible. Yes, it can be bypassed, it's expensive, it's difficult to implement it in 100% of the cases, it penalizes the small freeware producers and so on and so on. It won't solve the malware problem completely. But it will make it better than what it is now, so it is worth doing.
It also doesn't have all the flaws of standard whitelisting. You don't need a central database of all good software, you don't need to distribute such a database to the users, you don't even need the users to decide whether to sign something or not. All you need is a PKI (already in place) and the users to decide correctly which keys to trust. The latter, of course, is the main problem - but it's still a smaller problem than the current situation.
you know what's also funny? that i never said whitelists (or more specifically a digital signature based whitelist) wouldn't help...
i'm sorry if i wasn't clear but when i said it had no legs, i was referring specifically to joanna's argument that digital signatures would have solved the virus problem...
"You don't need a central database of all good software,"
actually, you do in order to do anything like revocation (which will be necessary since bad things can slip through the cracks)...
"you don't need to distribute such a database to the users"
not the entire database, no, only the parts of it they're actually going to use... that's sort of what the digital signature represents - the file's entry in a list (implicit or explicit)...
"you don't even need the users to decide whether to sign something or not"
that doesn't sound like a standard whitelisting flaw...
"All you need is a PKI (already in place) and the users to decide correctly which keys to trust. The latter, of course, is the main problem - but it's still a smaller problem than the current situation."
i'm not sure it is... knowing which keys to trust seems comparable to knowing which code to trust, there's just fewer instances... if that's what you mean by it being a smaller problem then i guess so but that doesn't seem like it's really that significant to the issue of trying to solve or at least mitigate the problem...
actually, you do (need a central database of software) in order to do anything like revocation
No, you don't. All you need is a PKI - a key signing hierarchy (certification authorities, etc.). The digital signature establishes a path of identification/trust from the executable through its author to the certification authority. You usually need just two keys - that of the author (included in the signature) and that of the certification authority (included in your browser). If a software author turns out to be malicious (i.e., signs malicious executables), his key can be revoked by the certification authority.
not the entire database, no, only the parts of it they're actually going to use...
Nope - only the keys of the certification authorities - and this is already distributed.
that doesn't sound like a standard whitelisting flaw...
It is a standard flaw of user-updatable whitelists.
knowing which keys to trust seems comparable to knowing which code to trust, there's just fewer instances...
That's many orders of magnitude difference. You don't need any code inspecting entity. The author vouches for his own code and the signature establishes his identity. The author is more easily traceable. If he turns out to be untrustworthy, his key can be revoked. And so on.
As I said, it won't eliminate the problem completely. But it will improve it to a huge degree. Case in point - the Office macro and Symbian worlds, where viruses, albeit not impossible, are no longer a problem.
"No, you don't. All you need is a PKI - a key signing hierarchy (certification authorities, etc.). The digital signature establishes a path of identification/trust from the executable through its author to the certification authority. You usually need just two keys - that of the author (included in the signature) and that of the certification authority (included in your browser). If a software author turns out to be malicious (i.e., signs malicious executables), his key can be revoked by the certification authority."
ok, so you're talking about vendors self-signing their code... that makes it trivial to get signed malware onto a system... it also vastly increases the pool of signing keys that can be stolen and/or used illegitimately...
so one possible scenario involves a 2 stage deployment for file infecting viruses: stage 1) compromise one of the many shops who has a cert with some signed malware (probably a backdoor of some kind unless you can find their key programmatically) and then stage 2) send your infector to them (or assemble it on their machine, whatever) and bundle their key in it so that it can resign the executables it infects and then infect their executables with your infector... then they can distribute your infector from there...
"Nope - only the keys of the certification authorities - and this is already distributed."
to my mind the signatures themselves represent entries in a (very distributed) database...
"It is a standard flaw of user-updatable whitelists."
i think you mean it's analogous to a flaw in user-updatable whitelists... users/admins don't necessarily sign executables per se when they add them to their standard whitelists, they just authorize them in whatever way the whitelist technology requires... so not having to decide which executables to sign is analogous to not having to decide which executables to authorize...
"That's many orders of magnitude difference. You don't need any code inspecting entity. The author vouches for his own code and the signature establishes his identity. The author is more easily traceable. If he turns out to be untrustworthy, his key can be revoked. And so on."
and you'll forgive me for pointing out that this then becomes a reactive, rather than proactive system as we'd be reacting to the discovery of a malicious signing entity...
"As I said, it won't eliminate the problem completely. But it will improve it to a huge degree. Case in point - the Office macro and Symbian worlds, where viruses, albeit not impossible, are no longer a problem."
i can't speak to the symbian platform but i'm not convinced digital signatures really had that much to do with the downfall of macro viruses... the execution environment was changed in such a way that macros where effectively disabled and couldn't easily be re-enabled by the flip of a switch... digital signatures were an implementation detail of that change, but i think in an operating environment where signed macros were used extensively macro viruses could survive just fine and if such environments reached a certain critical mass then macro viruses would once again be a problem... a macro virus signed with company A's signature will run just fine in company B so long as B trusts A's signature (which they would if they share a lot of macro laden documents) and when the virus starts replicating in company B it can start using their signature to sign itself...
ok, so you're talking about vendors self-signing their code...
Yes; I think Joanna is talking about the same thing.
that makes it trivial to get signed malware onto a system...
Significantly less trivial than it is now, which is the whole point of the exercise. If all (or at least the majority) of the executables are signed, and if the OS is configured (by default) not to run executables that aren't signed by a key trusted by the user, malware will have more trouble invading the system. In addition, parasitic infection won't work (provided that the OS can be secured against stealth tricks).
one possible scenario involves a 2 stage deployment for file infecting viruses...
This scenario is equivalent to the current situation (without widespread use of digital signatures) of the malware compromising a software producer, so that all executables released by this producer are infected. Certainly not impossible and happens occasionally (usually by compromising repositories of Open Source software) - but is nevertheless quite rare. Remember, digital signatures cannot eliminate the problem completely. I'm arguing that they will reduce it significantly, though.
o my mind the signatures themselves represent entries in a (very distributed) database...
There is no point of using such an abstraction. Nobody would need to perform searches in such a database. The search will be performed only for the software author's key and certificate - which is a very fast operation.
users/admins don't necessarily sign executables per se when they add them to their standard whitelists, they just authorize them in whatever way the whitelist technology requires...
Yes, yes. But since you said (correctly) that digital signatures are equivalent to integrity checking, signing an executable is equivalent to putting its checksum in the secure database of the integrity checker.
and you'll forgive me for pointing out that this then becomes a reactive, rather than proactive system
And the current system isn't reactive? :-) Again, we're talking about a difference in quantity - not in principle. The current system blacklists a single malicious executable - which doesn't bother its author at all. A system based on digital signatures would revoke the key of the author, blacklisting all executables produced by him. Many people would think twice before risking that. Add the fact that tracing the author should be much easier (if the system is implemented properly) and you get a whole new level of quality in protection.
That won't be without cost, of course. The introduction of Symbian's policy of running only digitally signed executables has had a tremendous negative impact on the authors of freeware games.
i'm not convinced digital signatures really had that much to do with the downfall of macro viruses... the execution environment was changed in such a way that macros where effectively disabled and couldn't easily be re-enabled by the flip of a switch...
That's precisely it - execution is disabled by default, except for executables digitally signed with a trusted key. (It can be re-enabled by the flip of a switch - but the switch is buried deep behind several configuration dialogs and the vast majority of users don't even know about it.) If macros were just disabled, many people who actively use them (or who produce macro packages) would have screamed. The current approach provides both security and a way to achieve the flexibility you want.
Yes, macro malware is still being made. But the real Office-based attacks nowadays use exploits - not macros. Achieving something like this for the EXE files would be similarly beneficial - although it won't eliminate the problem completely. That's why it's a good idea to have to - provided that we don't get fooled into believing that it's a panacea.
"Yes; I think Joanna is talking about the same thing."
hmmm, i didn't think she was originally, but now that i go back and re-read it you could be right...
"In addition, parasitic infection won't work (provided that the OS can be secured against stealth tricks)."
actually parasitic infection will work provided the infector has a trusted cert...
"Remember, digital signatures cannot eliminate the problem completely. I'm arguing that they will reduce it significantly, though."
and that is something i would absolutely agree with... again, i was disagreeing with joanna's argument that a digital signature based whitelist would be able to replace all the conventional methods of detecting viruses - that it was a solution to the virus problem in and of itself...
"And the current system isn't reactive? :-) Again, we're talking about a difference in quantity - not in principle. The current system blacklists a single malicious executable - which doesn't bother its author at all. A system based on digital signatures would revoke the key of the author, blacklisting all executables produced by him."
and this is basically what i'm getting at - you've turned something that could have been a whitelist back into a blacklist which is so unpopular these days (and which i really can't see joanna supporting, frankly)...
furthermore, the time between issuing the cert and revoking the cert creates a window of opportunity for parasitic infectors to successfully replicate...
"Many people would think twice before risking that."
why? they don't seem to have a problem with it now with certificates for their malicious websites...
"Add the fact that tracing the author should be much easier (if the system is implemented properly) and you get a whole new level of quality in protection."
tracing their front man, you mean, who may be about as culpable as phishing mule...
"That won't be without cost, of course. The introduction of Symbian's policy of running only digitally signed executables has had a tremendous negative impact on the authors of freeware games."
exactly - symbian has the ability to be restrictive like that, but for more conventional computer systems it's just not an option in general... users will not adopt it, and a security system that users refuse to adopt is not going to help them at all...
Post a Comment