Messages in this thread | | | Date | Sat, 4 Dec 1999 03:15:36 -0500 (EST) | From | "Robert G. Brown" <> | Subject | Re: malware defense |
| |
On Sat, 4 Dec 1999, Horst von Brand wrote:
> 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.
Perhaps we're talking about different problems altogether.
A certification boot/rescue floppy is good, sure, for right when you think you've just been cracked or perhaps to use on a very long rotation basis, and I've used them for that purpose for years. It is useless in even a modest size organization in any other context. Surely you don't advocate using such a floppy every day on every machine in a large organization, and even if you did this is far too large a time granularity to do you any significant good.
My remarks and comments on trying to do the certification with a daemon were addressed to the issue of trying to detect a crack in real time or during a regular and routine fine-granularity scan, not long after the fact or after a floppy-based reboot, and I even tried to make them relevant to the kernel list (rather than yet another security rant) by pointing out that -- as a kernel module rather than as a daemon -- the idea had considerable merit.
> 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.
Hmmm, I wasn't aware that I was advocating security through obscurity (and yes, I'm pretty familiar with the longstanding debate on open source security and even agree with you in a lackadaisical sort of way). Security by personal vigilance, yes, that I was advocating. Well-defended servers I was also advocating, but that is hardly radical -- most of the sysadmins I know in open environments like a University embrace the "feudal castle" defense strategy in one form or another simply because they cannot possibly exert enough control to totally secure hundreds of workstations running three or four operating systems being used by thousands of users (including many who login from remote sites that may well have been cracked, providing instant access into the best defended network in the universe). Keeping those basically untrusted users (many of them are students, after all:-) OFF their servers and logging all workstation activity immediately to secure loghost servers at least requires crackers to crack the next (much tougher) tier in their defenses to make really significant gains.
Again, to try to keep the discussion relevant to the proposed daemon, I think that we'd agree that relying on a locally installed MD5 as a cron-driven tool to detect cracks on a system is of far less value than one might expect, and that the RO floppy, however valuable in its place, isn't a scalable alternative. On systems with local disks, crackers simply and routinely replace the MD5 and ps and ls and so forth binaries you use to do most systems checks now (I know this for a fact as I was cracked -- again -- embarrassingly recently). Crackers would simply replace the "MD5 daemon" if one were developed along with the rest, unless it were somehow set up so that shutting it down or replacing it was itself a signal that the system was cracked. Note that I'm ASSUMING that the MD5 source or MD5 daemon source is and properly should be open, but their openness or closedness is irrelevant if they are destined to be replaced instantly upon a successful crack.
Now:
a) I have yet to hear of a "publically scrutinized, easy to use and unintrusive" open SECURITY system that a bad guy cannot take apart just as carefully as it is originally put together and reassemble into a functional simulacrum that allows them to exist within its aegis unobserved. That doesn't mean that one cannot exist; just that I don't think that one does now. rootkits are just one example of this process in action, and fairly clumsy ones at that. More complex tools just make crackers work harder (not a bad thing at all;-) but what is needed is a primary security certification tool that absolutely cannot be subverted without crashing the system.
b) You are obviously a fairly talented guy who knows a lot about security. I (immodestly enough) know a bit too; at least I've been doing systems work long enough to have learned a few things. However, the world is full of total and complete systems neophytes who are now installing and running linux. Some are running it on personal boxes. Others are running whole networks (shudder). Most of these systems are on the Internet and hence vulnerable to a wide range of attacks. Many of the owners of these systems haven't the faintest clue that something like a "security upgrade" exists and couldn't build a kernel if their life depended on it -- until right after the first time that they are cracked. There will >>always<< be a time-delay between the development of "solutions" in the open source community and the distribution of those solutions to the rest of the world, and crackers will >>always<< exploit that interval. Perfect security is no more possible than a world free from disease; the germs evolve faster than we do.
I was intrigued by the daemon suggestion because -- running as a kernel module that cannot be tampered with without destroying the integrity of the kernel itself (except perhaps by God's Own cracker, software being, after all, software) -- it actually sounded like it MIGHT form the basis for a scalable, open source solution to at least part of both a) and b). Perhaps I'm wrong. But it seems like it would be possible to make a kernel module non-removable and tamper proof (two key requirements). The kernel doesn't need to go through a subvertable layer to use the network. I suspect that a kernel+module could be designed that just might be able to at least certify selected certification software as it is loaded and run, and that might just be enough to make it MUCH harder to crack and encapsulate.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu
- 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/
| |