Dear Rails team,
The handling of the recent vulnerability in Rails has proven somewhat
problematic for us. We have recently adopted Rails as our web platform
of choice; previously, we used J2EE. We love Rails. We hate J2EE. We
don’t want to go back. It took a lot of effort and convincing to get the
management teams of our various projects to sign off on the use of
Rails. The nondisclosure policy in handling this vulnerability has
seriously jeopardized our (and many other people’s) ability to use Rails
in a commercial environment, so we would like to suggest that it be
changed.
The core issue is that releasing a patch to fix a critical security
vulnerability without telling anyone what the vulnerability is does very
little good as a knowledgeable cracker can just SVN diff the new version
with the old one and peruse that patch to have an exploit ready to go.
(The 1.1.4 to 1.1.5 patch is under 2,000 lines, not even that long.) It
only takes one person to do that and release it onto the net. Then,
thousands of script kiddies will have the exploit within minutes. I am
sure that, even as I type this, the 0-day exploit rooms on IRC are
buzzing with prepackaged copies of exploit code for the Rails bug. Not
disclosing the vulnerability does very little to keep the information
out of the hands of malicious hackers; it only harms legitimate users.
As a system administrator, how can I know whether my systems have
already been compromised when I don’t even know the general nature of
the vulnerability? I’m not suggesting that specific exploit code ought
to be posted, but we do need to know, at least generally, what is going
on in order to be able to effectively deal with it.
As a business, if I don’t have any clue what the problem is, I can’t
reassure my customers that their data has been safe, because I don’t
know. I have to spend resources to diff the new code with the old code
and find out exactly what the problem was, needlessly duplicating work
that dozens or hundreds of other people and companies (and crackers) are
simultaneously performing around the world, because of the decision to
withhold that information. Only then can I check to see whether the
exploit has been used on my system, potentially hours later.
Further, though the authors promise that the exploit is fixed in 1.1.5,
how can I be sure of that if I don’t even know what the exploit was?
Nobody is perfect. Everyone makes mistakes from time to time. If, by
some chance, there was a mistake in the fix in 1.1.5 (or perhaps the fix
opened up some other problem), it becomes that much harder for the
legitimate user community to catch and solve the problem. All bugs are
shallow to many eyes. But nobody will even discuss the original exploit
(except crackers amongst themselves), so how can we possibly audit the
fix? Even if, several days later, the details of the original exploit
are released, that’s several days that our public, Internet-facing
systems were sitting vulnerable to problems that the crackers surely
knew about; the problem could have been fixed in minutes if the whole
Rails developer community was looking at it.
Sun and the big J2EE app server vendors send out glossy brochures and
sales teams to wine and dine their customers. The glossy brochures and
the multibillion dollar brand name stamped onto the product give
managers a warm, fuzzy feeling. It makes them feel safe, because
(theoretically) they have someone to sue if things go wrong. Rails
doesn’t have that. Rails is produced by a decentralized team of people
on the Internet. While we, as technical people, recognize the technical
benefits of Rails over something like J2EE, it took a whole lot of
convincing to get the non-technical management people to forget about
the Sun cheerleaders and sign off on Rails for their expensive new
projects.
If our customers do not feel that their data is secure on our hosts,
they will not host with us. Since that is how we make our livings, this
becomes a big problem for us. The melodramatic “the sky is falling,
UPGRADE NOW NOW NOW” tone of the 1.1.5 announcement did not help,
either. If a customer reads this announcement, the customer will call us
up to ask what is going on. What are we supposed to tell him – “Uh… I
don’t know, the actual problem is secret, so we can’t really tell you
whether your data has been compromised, but some guys on the Internet
assure us that the issue is fixed now.”?? We would be back on J2EE
within the week if we do that, if we still had customers at all.
I therefore propose that full (or at least partial) disclosure be
adopted as standard policy for future Rails vulnerabilities. Doing so
will not give the cracking community any information that they wouldn’t
have in 30 minutes or an hour anyway – information that the legitimate
user community is denied for days, thus granting an advantage to the
malicious crackers. What it will do is allow Rails to exist as a
competitive, viable platform for commercial web development, and it will
allow system administrators to maintain the integrity of their systems
and their data.
I close with a quote I found at
Full disclosure - Wikipedia :
A commercial, and in some respects a social doubt has been started
within the last year or two, whether it is right to discuss so openly
the security or insecurity of locks. Many well-meaning persons suppose
that the discussion respecting the means for baffling the supposed
safety of locks offers a premium for dishonesty, by showing others how
to be dishonest. This is a fallacy. Rogues are very keen in their
profession, and know already much more than we can teach them respecting
their several kinds of roguery.
Rogues knew a good deal about lock-picking long before locksmiths
discussed it among themselves, as they have lately done. If a lock, let
it have been made in whatever country, or by whatever maker, is not so
inviolable as it has hitherto been deemed to be, surely it is to the
interest of honest persons to know this fact, because the dishonest are
tolerably certain to apply the knowledge practically; and the spread of
the knowledge is necessary to give fair play to those who might suffer
by ignorance.
-- From A. C. Hobbs (Charles Tomlinson, ed.), Locks and Safes:
The Construction of Locks. Published by Virtue & Co., London, 1853
(revised 1868).
–
