Messages in this thread | | | Subject | Re: malware defense | Date | Sat, 04 Dec 1999 00:22:44 -0300 | From | Horst von Brand <> |
| |
"Robert G. Brown" <rgb@phy.duke.edu> said:
[...]
> The problem is that >>any<< daemon, running basically outside of the > kernel as an ordinary task, just continues a vicious cycle of: > > a: (bad guys) develop clever(er) exploit > (good guys) develop clever(er) counterexploit > goto a: > > How do you protect against corruption/replacement of the daemon software > that checks the images? Quid custode custodes? Right now, "rootkit" > packages come with pre-scripted cracking tools that, when they succeed, > encapsulate the cracker invisibly, blinding the tools required to "see" > them. This just adds another tool or layer of tools they have to > replace. After all, how are you to know if the daemon you started is > truly the daemon that is currently running if the cracker controls the > daemon, ps, ls, and all that? They'll all lie to you, just like they do > now for many rootkits.
Then you need a way to certify what is on your system, probably off-line: A rescue-diskette style freestanding system that keeps the tools to check the files on the system, and perhaps also a database of cryptographic hashes for key system pieces.
The ideas you seem to advocate are called "security through obscurity" in crypto circles, where they have been thoroughly discredited. What is needed is publically scrutinized, easy to use and unintrusive systems that rely on secure mechanisms (i.e., crypto keys, secure hashes) to verify integrity. If the source is open, everybody will look it over, and flaws will be found and fixed quickly. If the source is closed, flaws will be discovered a bit slower by the wrong people, and never fixed.
Packages today are distributed with MD5 hashes, and signed with PGP/GPG, so it is _very_ hard to troyan a package and getting away with it for any amount of time. -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |