A Look at BSD Rootkits
blackbearnh writes "Windows has a reputation for being easily exploited by rootkits, but just because you're using Linux or BSD doesn't mean you're safe from infection. In an interview on O'Reilly's ONLamp site, Joseph Kong (author of Designing BSD Rootkits ), talks about how to build and defend against Rootkits under BSD. 'I know a lot of people who refer to rootkits and rootkit-detectors as being in a big game of cat and mouse. However, it's really more like follow the leader — with rootkit authors always being the leader. Kind of grim, but that's really how it is. Until someone reveals how a specific (or certain class of) rootkit works, nobody thinks about protecting that part of the system. And when they do, the rootkit authors just find a way around it. This is what I meant earlier when I said rootkit hunting is hard — as you really have to validate the integrity of the entire system.'"
is this book illegal in Germany?
> based on my penetration testing and signature analysis.
> E. Wyatt Tomlinson
OK, so we finally analyzed your signature above, and now we would like to proceed with the penetration testing of you.
Please advise.
Votez ecolo : Chiez dans l'urne !
And what do you do if you need your CD-ROM drive back? Also, some forms of malware install at the BIOS/hypervisor level. You can't even *detect* that from inside the OS! Some malware dynamically patches the kernel at runtime. So if you access settings on the hard disk or flash drive at all (and how could you not?) the malware can simply install itself after you boot.
The big question is how this malware gets there in the first place. The "towards verifiable systems" presentation linked to from the article listed such options as users who run attachments (merde), malicious employees who intentionally install kits (!), and use of a stolen password. These are all problems that can't be stopped, only mitigated. A malicious employee with physical access to a machine has everything they need, and you can't stop them. You can mitigate the problem by checking for things like tampering with the case and BIOS resets (to clear the password), but these are not foolproof solutions. Same with a stolen password. If you don't know its stolen, a window will always exist in which it can be used.
It *is* possible to build technology that does not suffer from trivial problems like buffer overflows, but you can't stop someone who has clear access to a machine. Authority is authority, and there will always be methods to steal and/or abuse that authority over a machine.
Javascript + Nintendo DSi = DSiCade