Date: Wed, 27 May 1998 12:04:51 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Virus on FreeBSD Message-ID: <199805271604.MAA22991@brain.zeus.leitch.com> In-Reply-To: Dave Chapeskie's message of "Mon, May 25, 1998 15:44:39 -0400" regarding "Re: Virus on FreeBSD" id <19980525154439.60457@ddm.on.ca> References: <199805211431.KAA17444@brain.zeus.leitch.com> <Pine.SOL.3.96.980522100017.17145A-100000@banshee.cs.uow.edu.au> <199805251518.LAA05684@brain.zeus.leitch.com> <19980525154439.60457@ddm.on.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
[ On Mon, May 25, 1998 at 15:44:39 (-0400), Dave Chapeskie wrote: ] > Subject: Re: Virus on FreeBSD > > On Mon, May 25, 1998 at 11:18:27AM -0400, Greg A. Woods wrote: > > I meant some way to detect the pattern of code in the *kernel* that is > > necessary to implement a module loader. > > This would be a waste of effort IMHO. When you build the kernel you > check what you are compiling in at the source level (as you've done by > checking what the NO_LKM define actually disables). If someone else has > the ability to change or replace the kernel on you (either on disk or in > memory) then your already screwed and LKMs are the least of your worries > :-) Yeah, I know it's not a really secure thing to do. It's more a matter of verifying that the rules and policies have been adhered to than trying to enforce anything outright. In this case I'm not expecting anything truely underhanded to happen, and if it does then I know that there are other audit trails and countermeasures to deal with them. Here we have possibly a dozen people who might build their own kernel, and some of those same people are also authorized to do maintenance work (such as building new kernels) on production machines. If any of those kernels that contain LKM support get from a desktop machine to a production machine, then I'd like to have some way to detect this. In other environments where the number of such authorized people may be at least an order of magnitude larger, then such simple verification measures can be of real value. The advantages of being able to give people responsibilities and the freedom to carry out those responsibilties, while at the same time not having to manually look over their shoulders 100% of the time, are great. On the other hand I don't hold a whole lot of hope that I can easily implement a tool that will be able to detect code signatures or patterns, even for a given processor family such as those FreeBSD runs on. > In general I find the idea of searching of "code patterns" to be a > waste of effort. Like the guy who wrote a perl script that looked for > code that designed to crash machines using the pentium 'FOOF' bug. The > script looked for the four byte pattern in files... it's real easy to > build up the required four bytes dynamically and then run them (assuming > of course that the memory protection mechanism provided by the OS either > allows executing from the data area or writing to the code area). I'm not too worried about the truely serious and dedicated cracker here. There are other countermeasures to stop them, including insurance coverage and just plain pulling the plug. We need to have protection against shooting ourselves in the foot, which coincidentally will also protect us against the "amateur" crackers and thus keep the insurance policy valid. In my experience with real life crackers, and in my analysis of most of the exploits commonly available, nobody at the amateur level goes to much trouble to hide their tools (most just download the root kit and blast away -- they couldn't write even one of the tools in that kit if they tried). The professionals (industrial espionage, disgruntled employees, etc.) will either try to disguise themselves as amateurs (to give the impression of a lower level of threat), or resort to covert channels and social engineering, from which we have little practical protection, at least through physical and technical controls (this is where people management and insurance policies come in handy again). -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805271604.MAA22991>