Disclosing security vulnerabilities to paying customers first

Question

Particular case

An (unnamed) vendor of an open source product also sells commercial licenses and support. One of the advantages of the commercial deal is that you get notified of security vulnerabilities immediately (even before an official release has been made), and access to a pre-release security build including the fixes. It also includes access to builds of older versions with security fixes applied.
In other words, users without such commercial support only get notified after a release has been made, when paying customers have already known about the vulnerability for some time. Although they have access to the original (vulnerable) versions, they are not given access to the same (pre-release or backported) security builds (but, it's open source, so they can access the source code and build it themselves).

I have some serious doubts about this approach. To me it seems to expose a large part of the user base to unnecessary risk.

General question

Is this kind of disclosure applied often; are there more (open source) companies that provide vulnerability details to a broad group of commercial clients in advance? Or is providing this information to all affected parties simultaneously a must and would this generally be considered irresponsible behaviour?

Answer 1

It's easy to say that this behaviour is bad. But I think it is worth to have a more detailed look.

Security issues are quite a difficult situation for many companies, that have decided to open source (some of) their programs, while keeping a commercial version. This gets worse if a fix cannot be created immediately.

Motivation for informing paying customers first

The company obviously depend on its paying customers to survive as any company does. So they need to provide some additional value to those customers.

It is likely that huge companies will be paying customers while small companies and independent persons will tend to use the free version. Those huge companies are more likely to be the target of an attack. And in case of an successful attack, it is more likely that they will be subjected to bad press coverage.

Furthermore there is a higher risk that public security warning without a fix will get attention from people with malicious intents. Just because the number of people is a couple of orders of magnitude larger.

This is especially true, if almost all serious users are paying customers. In other words: The open source version is basically a demo for the commercial one.

Motivation for issuing a combined security warning

After the company has issued a public warning, it can claim that it is no longer responsible for any damage caused afterwards. If the users did not take counter measurements such as installing the fix, it will be their own fault.

Giving information out early to paying customers may enable someone of them to use that knowledge for evil. Depending on the legislation it might pose a legal threat to the company that it did not warn all users, although it obviously was aware of the issue.

From a user's point of view

Having talked about the motivation for the company, let's have a look at the user side. I think it is quite obvious that paying customers will appreciate this as service.

Users of the open source version are subjected to an additional risk and should therefore be very careful with using such a software in a production environment or with sensitive data.

How does the non-commercial Arianne open source project deal with security issues?

I'd like to conclude with some personal experience. Arianne is an open source project which consists of an online game framework and a 2D online role playing game called Stendhal. It is non-commercial and does not make any money at all.

There are many people out there that run Stendhal servers since it is completely open source (client, server, graphics, everything). We run one instance of Stendhal ourselves.

When we discover a security issue in Stendhal we have ended up with this process:

• We share the information among the trusted core developers, we discuss it and work together on finding the root cause.
• We fix the issue and commit the change to the public CVS. Other core developers review the fix and test it themselves.
• We take the fix live on our server.
• We prepare a bugfix release based on the latest stable version. In the meantime other core developers do some more testing. Normal players just continue playing and therefore implicitly test for side effects.
• We do a minor release of the last stable version together with a source code patch and post an announcement describing the issue.

The whole process takes about 1 to 2 hours.

We do not release bug fixes for older versions because we pay a lot of attention to make updates between versions very easy to install. The only reason someone cannot jump to the latest version is that he did modification to the code himself. For those people we provide the source code patch.

I can see that someone may argue that updating our own server first is evil, as is committing the fix to the public CVS before the announcement. But this is the most effective way to get a high quality fix out in the shortest time possible. We do need the short test on a live server because people really expect that they can install security updates blindly without having to fear side effects.

Answer 2

I would normally wait until I have time to type a well-formed answer or somebody beats me to it, but given the downvotes:

It is not an uncommon business model in either the open or closed source worlds to provide enhanced support or earlier security fixes to paying or premium customers. In some cases, these are the most vulnerable customers. The goal is somewhere on a sliding scale between patching as many high-value targets as possible before making an exploit publicly known (or providing a patch that usually makes finding the exploit easy) and making a few extra dollars along the way.

The ethics of this have not really been decided on as an industry, but as you may guess there are plenty of people who are unhappy about this idea.

Answer 3

Seems to be evil, but I'd go with the other point of view:

When a software goes open source, anyone can review it, change it, create some patches / diffs, make these patches available in his own site, etc.

Someone decides to provide support for it: "I'll check if this software is secure enough. If I find something, I send you the corrections promptly. Then, after warning you, I'll give the fix to anyone. You only have to pay me in exchange".

Be it the developer or not, it's the proposal that's being made between two companies.

Is the developer creating bugs in the soft so that he can sell the solution ? If so, then yes, they're evil and should be sued. No, they're playing it fair? They are giving everybody the soft, support against bugs (after some delay), and people are complaining about not being treated equally with the paying ones? Don't know, think it puts too much responsability on them. They don't prevent you from fixing the software yourself.