BaySec 2

BaySec 2 is tonight, June 20 2007.

Details here.

Hope to see you there!

Attention Jed Pickel

It appears that I owe you a big apology. You were right, I was wrong.

(It's amazing the stuff you find when googling yourself.)

Open Source Remorse

So rather than continuing to carry on in the Matasano blog comments (1, 2) and being mirrored in Alan's blog, I figure I should gather my thoughts on this subject in my own long-winded blog entry.

Now, my recent comments have been prompted by Alan's and Tom's comments at each-other, but they aren't about that per se. I gather the background there is that StillSecure has released Cobia which includes Snort (and other open-source bits?), but the Cobia bits aren't GPL. I really don't know anything about whether there's any inappropriate linking or anything going on, I haven't looked at it. The StillSecure guys raise some legal doubts about the GPL, and Tom points to Marty's post about the "clarifications" in the Snort license.

(Update: Alan tells me that Cobia does NOT include Snort. Leaving me wondering what Tom was was upset about in the first place. Shrug. Sorry about further muddying things with my incorrect claim, Alan.)

The key point that Tom raises that I want to take issue with is this:

Why do I care? Because companies like StillSecure are driving open-source projects “underground”, into proprietary licenses. Wow, that sucks.

Now, let's hang on a second there. It looks more to me like a basic desire to make money has caused the open-source security tools developers to start changing their licenses.

They have open source remorse.

It looks more to me like they are finding it difficult to get people to pay them when their stuff is licensed only under a GPL license. Obviously, if the software is only available under the GPL, then anything else it goes into also needs to be GPL. (Modulo calling vs. linking vs. straight source modification, etc... I'm not here to try to hash that mess out.)

I've watched this happen with BitTorrent, Nessus, nmap, and Snort.

Is there anything wrong with making money with software? Certainly not. I've worked at Sybase, contracted at ArcSight, tried my own hand with Enforcer for AnchorIS, and am currently about 4 years in at BigFix. BigFix, by the way, has licensed nmap for commercial use, and Fyodor's licensing terms were very reasonable. All those companies I worked at are traditional, closed-source software vendors. So I fully stand behind profiting from software licensing.

We are salesmen, and completely up-front about that.

But I believe there is a different standard if you're going to go the open-source route. Maybe I'm too much of an idealist, but then, the GPL is kind of an idealist license.

So here's the game: You create some very early, proof-of-concept open-source security tool. Maybe you're early to the market, or maybe you have some genuinely nifty feature, but you're a known concept, an IDS or a scanner.

How do you gain popularity? Well frankly, being free can be a huge help. And if you're not doing it for a living anyway, it works for everyone. What do most open-source projects want? Help. For the packages I've mentioned, they got it

Maybe it wasn't in the form of (much) code. But it was in the form of signatures, QA, people running mailing lists, people submitting fingerprints and banners for obscure software, filing bug reports and feature requests, help compiling on weird unixes, packet captures, books, articles, and other general evangelism. The license also allows every Linux distro in the world to ship your stuff, further cementing you as a de-facto standard.

Those things are absolutely massive contributions for a young project. I don't wish to discount the efforts of the key developers on each of those projects. The packages would most certainly have fallen into obscurity without their leadership. But even then, you don't maintain such a project for years without a positive feedback loop.

But for the projects mentioned, the maintainers eventually decided they would like to make a living off the project.

This is where I admit that I don't know what's in the hearts and minds of the people who are now selling commercial licenses for these projects. I can only judge based on their actions and published licenses.

But it sure looks like they're taking the combination of their own work and the community support, and selling it for a profit.

Why do I care? Because I believe that a lot of people, myself included, gave support because they thought they were helping out a project that was only under a GPL license. Changing it after the fact strikes me as a kind of dishonesty. If you help out a commercial software company, great. You knew what you were helping. I know a lot of people who do free QA for Microsoft.

But if you think you're contributing to a project because your help will always be available to the world, and you'll find it in your favorite latest Linux distro, sorry. Nessus is all the way there, no new Nessus for anyone who doesn't want to register, download and install it themselves, and so on. And no source. Snort and nmap can still be shipped around, but we'll see if it stays that way. No more free Snort sig feeds for you though, if I recall correctly.

I should clarify a point. I keep talking like these projects aren't GPL anymore. That's because I don't think they are, at least not entirely. Nessus clearly isn't anymore. No question there. How about Snort and nmap which have commercial versions available for licensing?

Marty asks in the Matasano blog comments next to me "Snort isn't GPL?"

No.

So you can take Snort and code on it or mix it with other code, and your users can demand the source from you under the GPL terms. That seems pretty GPL, right? So what if your code is in Snort, and SourceFire sells a license to a commercial software vendor. Can you make that vendor give you a copy of their source?

Nope.

Anyone remember the point of the GPL? It's so that no one can take your code away from you.

So you might be wondering, how can they take your GPL code and sell it under another license? Am I accusing these projects of stealing code? No, not really. I assume that they have acquired the rights to all the bits of code or have purged the stuff they can't track down.

Yes, this does mean they had to have planned this for a while. They had to stop taking contributions from all the outsiders or people who will only submit GPL code. I believe these guys are smart enough to get this right, though I wouldn't mind seeing how they went about auditing the codebase.

Does this mean they can never take outside code again? Well, it means the submitter has to be willing to give them a license to do whatever they want with it, including selling it non-GPL'd. This would include, say, people working on it for the Google Summer of Code.

SourceFire has that part tied up rather neatly, too. If you read Marty's "clarifications", you'll see that if you get your code near any SourceFire people, then you automagically grant them the right to sell it as closed-source.

So no, not GPL.

Another interesting thing about the GPL, it only covers code and maybe some docs. If you made some other kind of contribution like the ones I mentioned earlier, not covered. They can just take it and sell it.

So who is really killing GPL'd projects? If you think StillSecure is stealing without giving back, I'm not seeing how SourceFire isn't doing some of the same.

I've met Fyodor and a bunch of the SourceFire guys a number of times. I don't have anything against them personally, and it's not like I don't wish them financial success. I just wish they had either had the license they really wanted in the first place, or didn't go changing it late in the game.

That's your manifesto?

Pete Lindstrom posts his Secure Software Manifesto. Pete, you'll have to do better than that. I guess a manifesto is not a thesis, it's not intended to be a self-contained set of assertions and evidence. But I feel it necessary to call out what look like some glaring factual errors and inconsistencies to me.

1. Public vulnerability information (e.g. CVE, disclosure info, etc.) provides data about the activities of the hacker/bugfinder/security researcher community; it tells us nothing about the absolute or relative level of vulnerability of software.

On the contrary, I think the effort required to find bugs, and the rate and volume at which they are discovered are the best indicators of the relative level of security of a software package. I will agree that this doesn't tell us the absolute number of vulnerabilities left. There's always the chance that the researchers found the absolutely last bug in a package on the 31st while doing their Month of x Bugs.

The past is not necessarily a predictor of the future, but the past may be a predictor of the more recent past. Or you might prefer correlator. I believe the data is all there for someone who wants to, say, take the bugs for packages from 2005 and see how they correlated with bugs in 2006. At least for known bugs.

2. The defining aspect of a software program's vulnerable state is the number of vulnerabilities (known or unknown) that exist in the software. It is not how hard programmers try not to program vulnerabilities nor how hard others try to find the vulnerabilities.

The first sentence is a fine definition. The second sentence seems to be trying to distance itself from the first, though. If you try hard to create fewer vulnerabilities (and have some talent and experience in that), don't you think you will create fewer vulnerabilities? And if you missed some, and other find them and you fix them, don't you mostly end up with fewer vulnerabilities?

So no, using the definition of "vulnerable" to mean there is at least one vulnerability left, there's probably no amount of effort you can expend that is going to get that count to zero. But don't we want software packages that have fewer vulnerabilities, if you can't have zero?

Because if there's no value to that, I know lots of people who could be doing something else with their time.

3. The contribution of a patch to the vulnerable state of a software program is a tradeoff between the specific vulnerability (or set of vulnerabilities) it fixes and the potential new vulnerabilities it introduces.

Sure. Do you mean to imply that patches often introduce new problems? I'm kinda under the impression that's relatively uncommon, but I'd be willing to be proven wrong.

4. There is currently no known measurement that determines or predicts the vulnerable state of a software program.

False. If you use the definition of "vulnerable" meaning that there is at least one vulnerability, then I have a program that will read any other program of some minimum complexity, and return the probability that it is vulnerable. The answer is usually 1. I'm very confident in my low false-positive rate.

Facetiousness aside, I agree that there is no metric or program to find or event count all of the vulnerabilities in a program. Maybe not even most of them.

But there are programs, services and consulting that will find "some". Is there value in finding "some"? Is it useful to know how hard it was to find "some"?

5. We don't know how many "undercover" vulnerabilities are possessed and/or in use by the bad guys, therefore we must develop solutions that don't rely on known vulnerabilities for protection.

Once again, I agree with your opening statement, and am left wonder where you got that particular conclusion. Why not "therefore we must find and fix as many vulnerabilities as possible" or "therefore we must infiltrate the underground and gather intelligence"?

6. The single best thing any developer can do today to assist in protecting a software program is to systematically, comprehensively describe how the software is intended to operate in machine (and preferably human) readable language.

As a QA guy, I'd have to say that would be really, really awesome. Yes, can I have that please? But if I had that, isn't that the same as programmers trying hard, ala your point 2?