Trilight Zone

[tricore]

You might be surprised to learn that the mysterious hacker behind the MoKB (Month of Kernel Bugs) project actually believes in responsible disclosure. For the entire month of November, the man known simply as "LMH" is releasing a daily proof-of-concept exploit for unpatched kernel-level flaws in operating systems -- including Windows, Linux, Mac OS X and FreeBSD. I caught up with LMH over IM and found him willing to explain the motivation for the project, share thoughts on disclosure ethics and argue that some OS vendors are more dangerous than hackers...

RN: Can you introduce yourself? Who is LMH? Is there a real name?

LMH: Well, I have a name as we all do. LMH is in fact a reference to my real name. The reason for 'hiding' behind it is that while I don't mind appearing on public mailing lists, news media, etc., I want to be recognized by the work I do. A name is pretty much like a trademark, and I'm not into trading with my name, thus I prefer to use a rather simple nickname such as 'LMH'. That way people focus on the work and not who has done it. It's also good to keep a low profile sometimes. I'm based in Europe.

How did you get involved in security research?

I got involved at a young age, obviously not in the best manner. Like most people in the 'scene' I started as the rather annoying script kiddie, or high school prankster. Fortunately I got through that and started doing more useful work . I've been doing kernel-related development for some time now around some projects. I found Metasploit to be a serious, yet extremely fun playground where I met skillful individuals such as HD (Moore) and Matt Miller (skape). I've been contributing to Metasploit for some time now. I could say it's my professional career but I try to get involved in other related activities in areas like physical security.

What prompted you to do the MoKB project? Any particular reason for focusing on kernel bugs?

One of the reasons was to have fun and find interesting issues. The original intent was to get a general overview of the current state of kernel-land code but I was also pushed by the fact that some bugs apparently were being patched silently (even if they were known for months). The 'better-safe-than-sorry' saying applied fairly well to the situation, so that also motivated me to release these bugs into the public domain.

What's wrong with silent fixes? Microsoft says that anything they find themselves will be fixed silently because releasing information only serves to help attackers...

It's wrong when developers and vendors are dishonest. It's also contradictory to the apparent policy/motivations of a company if their business model focuses on security or open source software. Actually, silent fixing aids attackers. Someone who thinks that no one can notice a silent fix by either reverse engineering or simple mining of change-logs and development discussions is definitely someone harmful to himself, his company and the userbase of the product itself.

I've said it already, I ain't no fan of full-disclosure. I'm probably going to keep certain issues private instead of releasing them through the MoKB (ex. remote issues in Linux kernel and others). Sometimes you get to feel the developers or whoever is in charge of these issues doesn't deserve the privilege/advantage of being warned about them. The problem is that many people consent to these policies. Many times, the developers are great people, but things just turn into total nonsense in the upper levels of their organization.

I'm not into politics but a good example is the Army. It's the soldier who has to go through the trouble, including people blaming them for doing something that someone else been ordered them to do. It all boils down to trustworthiness. I've got hints from some people who have worked around kernel-land code and explicitly asked me to keep certain problems as private. If I fail them, they will no longer trust me. Corporations should think that way. They are losing the confidence of their customers...

You say the MoKB won't do full disclosure on remote issues but you released the Broadcom wireless driver bug -- with Metasploit exploit module -- even before patches were ready from OEMs. What was your thinking there?

Well, it depends on the target. I need to think about which issues are suitable for release. The Broadcom wireless bug was a nice one and it made sense to release it. It's been unpatched and unknown for enough time, and all the glory goes to Johnny (Cache) for working on it, as well as Matt, HD, David and the other researchers. Actually, I'm hesitant to release certain issues because they might be useful in case the FUD bar gets raised more than the tolerable limit.

Besides that, some third-parties explicitly ask me to keep some things private. As I said, I would fail to them if I released those, so no matter what I'm being told, I must keep them that way unless we decide otherwise.

I've also seen another criticism that your Linux kernel bugs are mere low-risk DoS (denial-of-service) issues. Is there a concern that you might be overblowing things?

You're right, some are low-risk. However, there are issues that have some other implications. DoS issues, when it comes to filesystem bugs, also lead to filesystem corruption, especially with Linux. I'm not overblowing issues. I'm simply explaining the security implications. The fact that some developers aren't familiar with those might lead to criticism and I get the feeling that some people want me to do their homework as well and they feel cheated when I don't give all the relevant details about a specific issue.

I'm not being paid for this and the time I invest on the MoKB is for free. There's also an obvious interest for some parties to make the MoKB look like an infamy or a smear campaign against a concrete target. In any case, it's all up to those with the technical skills necessary to check and fully understand the issues. The proof is there up for verification, I'll let people decide by themselves as I personally have strong confidence about it and no reason for feeling vulnerable about my credibility.

Again, releasing high-risk issues for the Linux kernel (such as bugs in network-exposed interfaces) is a big deal. Criticism will always be there and releasing those kinds of bugs means wasting them too. They will probably get fixed silently and that's the end of the story. Not worth the effort, in my opinion.

Have you been contacted by a vendor affected by any of the MoKB releases?

Yes, surprisingly the so-called 'proprietary software' vendors had the most positive responses so far. No negative response, no personal attacks. Microsoft and Apple, so far, seem to be changing their minds about some stuff (even if most end-users are still confused, especially when it comes to Mac OS X issues).

What was the response from Apple and Microsoft? What did they want to talk about?

I got nice feedback from the MSRC (Microsoft Security Response Center). They were asking for any additional information to help them work around the issues and were willing to provide information that I could use to check and research on some kernel-land interfaces. I talked to an Apple employee working around security issues and I get the feeling they were willing to work together and share information as necessary.

Generally, both wanted to know if I could give them notice in advance for future releases, so they could plan to deal with issues affecting their respective products.

Do you think that the severity of kernel-land bugs has been largely ignored by OS developers? Is that the reason for the project? Why did you decide to focus on this specific area?

Yes, definitely. It's less targeted and much more complex to work with and debug. So, yes, that was one of the reasons. Although there's been previous research around kernel flaws, they always seem to fly under the radar.

What tools you are using to find these bugs? Are those tools going to be released as well?

I've released most of the tools already. I'm not sure if I should release the others. As I said earlier, some third-parties are being dishonest, using the tools to find bugs and not acting properly with them. One of the tools is fsfuzzer, which was created over the last year as a simple bash script. I've ported it to other platforms, like Solaris (it's heavily oriented for Linux, so changes are necessary) and FreeBSD.

For wireless bugs, fuzzing tools are being developed on top of the Metasploit Framework and the Ruby interface to the Lorcon library.

Beyond what we've already seen (Mac, Windows, wireless drivers, Linux, FreeBSD, Solaris), are you planning to look in new areas? What can we expect to see in the second half of November?

If I have enough time, I might have a look at smart phones and PDA-type devices, maybe find some Bluetooth issues. Maybe you'll see some more bugs in different BSD flavors. More wireless bugs are coming for sure.

Actually, we're working on at least one that will be related to the 'shipping' Intel-based Macs such as the new MacBook laptops, but there's work to be done around it. Think Airport. We might even have a third-party (ZERT) patch depending on time, risk and availability of vendor patches.

Have you found a flaw that you won't release because a vendor specifically asked you to hold off?

No, I don't usually let vendors decide on my own work unless there's a truly good reason for doing it.

I'm willing to work together with any vendor that deals with the issues properly. No FUD, no silent fixing and proper crediting. The real meaning of the so-called responsible disclosure