Out Of The Stone Age

Here is a Rootkit Detector I wrote for CS 558 at USC in the Fall of 2005. It consists mainly of a Linux loadable kernel module that loops through the scheduler task list as well as all open file descriptors attached to the tasks and writes what it finds to a file. Then a python script compares the kernel data to what is reported by lsof. If it finds discrepancies it reports them and alerts the user of a possible rootkit.

It was originally tested by successfully hiding a process with the adore-ng-0.53 rootkit written by Stealth. However, I have not tried this yet on my latest setup.

I’m not sure the detector actually still works, although I got it to build and install on a 2.6.24-19 i386 kernel running on Ubuntu 8.04 today. I had to make a couple of changes to the original code. Namely, I  replaced a task_t typedef with the struct task_struct variable since the task_t was removed from the kernel. I also had to add another layer of indirection to get at the file descriptors, since the max_fds and fd members of the srtuct files_struct were moved to struct fdtable in <linux/file.h>.

I was also able to install it with insmod, however I doubt it still works as it was only built for a uniprocessor system almost 3 years ago, and getting this to build was the first bit of kernel hacking I’ve done since then. I also can’t uninstall it without rebooting anymore, although, I haven’t done that yet and my kernel hasn’t crashed

I still think if updated and expanded it can be a useful tool against both kernel and user level Linux rootkits.

P.S. I know the output format sucks and the python code is a mess, but the goal here was to study rootkits and linux kernel development. If I ever revisit this I will make sure to clean up all that stuff and write a proper parser. But… this is GPLd so feel free to jump in. If there is any interest in it maybe I will setup a google code project and revisit it.

This was the first and only kernel module I’ve ever written and I wrote and tested the whole thing in about a month or so, while reading Robert Love’s Linux Kernel Development and seriously trudging through the kernel source.

Here are some (not so perfect) documents to get you started:

• Project Proposal
• Implementation

XSFS: The Extensible Steganographic Filesystem is a term paper I wrote in the first semester of my Masters program in CS at USC. I wrote it for CS555: Advanced Operating Systems in Fall 2004. The ideas in XSFS are especially useful when needing to hide large amounts of data on untrusted storage.

It would make an interesting project to clean up the ideas a bit and modernize it for untrusted storage such as Amazon S3.  It would also be a really excellent project to implement in Erlang.

Oh, and sorry for the picture. It was originally done in MS Word on the school computers for some unknown reason, and has been shuffled through various versions of OpenOffice for some time. I’m sure I have the original on CD somewhere, but for now you’ll have to take this slightly edited version.

This paper is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.

I’ve been using OpenBSD since the 4.3 release and am starting to track -current. I’ve also been heavily coding in Erlang lately. CVSsup seems like it might be able to receive a performance boost from the lightweight process model of Erlang.  I haven’t looked too closely at the protocol yet, but this seems like it might be an interesting and useful thing to try.

Michael Deng to Steve Vinoski:

“Why don’t you finish everything so the rest of us can sleep!”

If your OpenBSD 4.3 laptop is extremely hot and noisy, you can put it in Cool Running Mode with
apm -C

This took my Core2Duo T5300 from 1.73 Mhz to 800 Mhz and significantly reduced the noise and heat, when not in heavy use.

So, I still can’t correctly configure my /etc/xorg.conf file using xorgconfig or Xorg -configure. Everytime I try to add my native laptop resolution of 1280×800 it still goes back to 1024×768. So I keep deleting it and using no xorg.conf. OpenBSD then correctly detects my resolution.

However, I can’t downgrade it to 1024×768 at runtime. My main goal for doing that was to use the VGA cable to hook up my laptop to my Samsung 46″ LCD to watch movies and such.  Under Ubuntu, I had to do this because my tv wouldn’t accept the 1280×800 resolution, but worked fine with 1024×768.

Just for the hell of it I decided to just hook up my OpenBSD laptop and reboot. Amazingly it actually output at 1920×1080 to my TV! I couldn’t get Ubuntu to do that! Simply Amazing. I just keep being impressed by the quality of OpenBSD. And I haven’t even started digging into the kernel sources yet

I just installed OpenBSD 4.3 recently. I’ve played with it before and even purchased the 3.6 CD set.  However, I never had much success running it as my hardware wasn’t supported and usually just went back to Linux. I really am trying to get back into the security mindset and figured I might as well throw OpenBSD on my HP dv6345us laptop.

The Install was a breeze! At least it was until I realized that GDM wasn’t included in the AMD64 packages. So I had to reinstall the i386 version. I got Gnome up and running trivially and the native 1280×800 resolution was detected.  The weird thing here is that there is no xorg.conf file in /etc/X11. Being used to Ubuntu and other various Linux distros, this seemed strange. Each time I tried to add one and  tweak by hand I would end up with a 1024×768 resolution. So for now I’m sticking with the default config.

At this point and then it was on to configure the wireless. My laptop has an integrated “Intel PRO/Wireless 3945ABG” card. Surprisingly enough an open source driver is installed out of the box for this. Terrific! What is lacking however is the firmware. But that is easily added with the package created by Damien Berganini. It can be installed easily enough with the command:

pkg_add http://damien.bergamini.free.fr/iwifw/OpenBSD/iwi-firmware-2.3.tgz

Information on how to configure wireless with ifconfig was also readily available with a quick search of the web.

I then installed firefox, emacs, and a whole host of other thirdparty packages.

The only things that disappointingly don’t work are my function keys (f7 and f8 for brightness, etc…) and my softkeys. I will eventually have these working as they work out of the box on Ubuntu 7.04, 7.10, and 8.04.

I also can’t use an external monitor, once again do to the lack of use of the function keys.

I now have to decide if I’m willing to install Linux binary compatibility and the Adobe flash plugin so I can watch tv on sites like hulu.com. I still haven’t decided If I want to go down that road, although hopefully gnash will catch up soon, since Adobe just opened up their specs.

I’ll be back with more updates soon.

Titus Brown has recently posted a very good diatribe on why people should test. It should be required reading for anyone who is not currently testing. I especially like the straw men arguments, as most developers advocating testing are likely to come across at least a few of these. My favorite is:

“We don’t have time to test.” Why do you have time to write software, but not time to make sure it works?

Please take a look.

I learned about Test Driven Development recently and have been using it along with CXXTest for about a week now. I understood the supposed benefits, but in a very short period of time I have realized substantial actual benefits.

First off, by writing tests before I code I think of simple use cases for my code and understand it from a user’s perspective. This is fine in and of itself, but not necessarily that noteworthy. Once I code simple (maybe even throw-away) solutions to these tests I further my belief in my use cases. This may also sound nice, but this is certainly achievable with Big Design Up Front as well. And I don’t disagree, necessarily. Especially if you are a very experienced developer.

However, the test cases themselves are the biggest benefit of TDD. By coding these test cases I can provide a giant safety net for myself when I redesign my data structures or algorithms. Furthermore, by writing the tests first, I make sure they actually do get written. Therefore If I so desired I could code with reckless abandon and rewrite a class completely with lots of STL containers and algorithms, and by re-running my test cases I could ensure that the code still works the way it previously did. While this is not necessarily the “incremental changes” path advocated by TDD experts, it is a form of larger scale refactoring. This is what I did today, and the safety net I had created saved me in two distinct ways that I did not expect.

1. A simple corner case: Several member variables were keeping track of state in my class. I needed multiple instances of these, so I wrapped them up in a struct and used a std::map to store them keyed on an IP address. However, after storing my variables inside the stl::map, I altered an algorithm I had written to organize the data in these variables so that it would be more coherent. However I broke a very simple corner case that I likely would not have noticed for at least a few days down the road. As soon as I compiled my changes and ran the code my test caught the error and it was fixed in a matter of seconds.
2. Misuse of third-party code: First let me state that I consider the STL third-party code. Like third party code, you need examples to use it and experimentation to use it correctly. Although I have used the std::map class many times before, it has been a while since I’ve last used it. And thanks to my TDD safety net I was coding with reckless abandon. I made the classic mistake below:

std::map<KeyType, DataType> exampleContainer;
DataType extractedData = exampleContainer[someKey];

/* modify extractedData */

exampleContainer[someKey] = extractedData;

What I did was modify a copy of the data and attempt to reinsert it into the map. This is not how a std::map works. The correct way is to retrieve a reference to the data and just perform the modification. Once the key is associated with a value in the map, insertions fail. But the syntax of the [] operator does not allow for visibility of the failure. The correct code is below.

std::map<KeyType, DataType> exampleContainer;
DataType& extractedData = exampleContainer[someKey];

/* modify extractedData */

It is important to note that other tests in my test suite passed even with these code mistakes. Therefore a cursory manual test would have certainly passed over these seemingly glaring errors leaving them for much later in the debugging stage. Furthermore these errors probably would’ve percolated up into extremely odd behavior in the application, causing me to spend much more time debugging the program with gdb or print statements than I spent writing the tests in the first place. Even worse, they may have evaded me and made it to SQA, although unlikely

By having this safety net in place the errors were caught quickly and corrected immediately. I am already enjoying the benefits of TDD and I encourage every developer to give it a try. Test Driven Development By Example, by Kent Beck gives an excellent introduction to the topic.

I walked into the pet store the other day and was confronted with an unbelievable dilemma. My boss needed some cat litter, but there were at least 20 available brands. My mind shuddered. They ranged from coarse grained to fine grained, scented to unscented, single cat to multi-cat, etc… There were the commonly used, well respected brands, as well as the off brands which promised to be just as good. There was the small 5 pound bags and the giant 80 pound bags.

I immediately went home and started searching the blogs and forums for the ideal litter. I was confronted with a barrage of information, as well as some angry critiques:

“Anyone who doesn’t use the coarse grained scoopable Tidy Cat is a Moron! There is no way a fine grained litter will scale to multiple cats without tracking. It just isn’t possible. I’m so sick of this new fine grained, scented crap that keeps popping up. This is a forum for SERIOUS CAT OWNERS. TAKE YOUR CAT HOBBYIST ASS SOMEWHERE ELSE!”

I sat in my chair pondering my dilemma, thinking that I might as well go with the Tidy Cat, because it seemed that was what the majority was doing, and it worked very well. Although there was the occasional complaint that the price didn’t really reflect its value adequately.

But then I remembered, my boss only has one cat and will probably only get another after he dies, so I don’t really need the scalability. But I worried about getting the cheap stuff because of the reputation of people who use it. They are often called hobbyists, or amateurs. Sometimes they are even told they don’t care about their cats! I didn’t want myself or my boss to endure that kind of labeling.

I set off for the store bound to get the good stuff, but while heading down the aisle I had an epiphany: What if the cheaper, newer stuff is really GOOD ENOUGH for 1 cat and maybe even 2 or 3? I knew my boss was away for the weekend so I decided to buy the new stuff, let the cat shit in it and see if it scaled to his odor. I could always get the good stuff later.

Kinda reminds you of the REST vs. SOA debate, doesn’t it.