Does EE’s limited response to reported exploits constitute a security-by-obscurity mentality? As a scripting language, source code is always available and simple tracking of updates may produce reverse-engineering of version updates that include security updates, that may provide opportunity to track exploits.
Is it a good idea for EE (and maybe Code Igniter) to begin to promote an open security column vis-a-vis discovered and announced security exploits?
This is not to suggest that EE is doing anything wrong; plenty of companies currently follow very similar security models, with of course Microsoft and Apple being the most prominent among many more.
I think of it this way. The open philosophy is like a shot gun. The closed philosophy is like a sniper rifle. They both have strengths, they both have weaknesses, they both are efficient at what they do, and they are both deadly.
In each case its a matter of how good you are with your weapon of choice that determines the security of your product. We’re confident that our security record over the years bears out our expertise with the more sniper-like approach. We also have no qualms with companies and developers who prefer the shotgun method and neither will we hesitate to pick up a shotgun should the situation warrant it.
This may be oversimplifying things a bit but I hope the point is made. There is always value discussing the various security philosophies and its very important to evaluate a product based on the method employed by its creator. But such discussions should always be done gently.
I’ve been looking over the security documentation, which I think is pretty thorough and seems to rely greatly on preventative measures, which is very good, and necessary for the type of security model used by EE.
Would like to say that in this case I completely agree with Leslie.
If you read the replies to the lullabot article, which is fair in its writing, you find people who have been zapped on Drupal because they were on vacation when a security outing occurred. The hackers saw the vulnerability, and proceeded to exploit it.
No chance for the site owners to have prevented this, and it’s a common scenario at least for those of us who use a site for business—what happens when you are busy with that business, or when it is another reason you are ‘out of town’?
Sniping faults of this kind is effective. Let’s stick with that, or so I would like to propose. For this customer, I feel it improves very greatly the dependability of my site.
Thanks for the post Jared,
Just saw the article myself left a comment on lullabot and double posted here… sorry moderators
I would be interested to know why EE staff doesn’t go into details on release notes.
As in…
-when was it discovered?
-by whom?
-how many sites reported effected before the patch is released?
-what was the damage?
-code examples?(since it no longer a threat)
etc. etc.
Have you read Leslie’s reply? That’s all there is to it, really. Personally, I am a fan of “full disclosure” where appropriate, but I think the EL approach makes a lot of sense in our case.
Please note that, to the best of my knowledge, all vulnerabilities discovered & patched so far have been largely theoretical in nature. We take security very serious, trying to fix potential weaknesses before they become an issue. There was never an exploit in the wild, thus no damage.
I would be interested to know why EE staff doesn’t go into details on release notes.
Each question you have is answered here
http://expressionengine.com/blog/entry/expressionengine_164_maintenance_and_security_release/
except for:
lebisol - 08 July 2008 02:16 AM
-code examples?(since it no longer a threat)
And that’s not going to happen. Really, who would it benefit by us telling the general public exactly what code, circumstances, etc. would demonstrate the vulnerability? The pros of doing this amount to nothing more than the satiating of curiosity. The cons are the real possibility that a script kiddie will go through all of the links they find from this site to users’ ExpressionEngine sites, or Googling for them, and trying to hack sites for hours on end. So if you couldn’t update your sites the same day as the announcement, where does that leave your clients?
As our code is open, it’s possible that someone might look at a Diff, and reverse engineer an exploit after figuring out what we changed and why. Same would be the case with Drupal, and I don’t believe you’ll find them publishing step by step exploits either. If someone is really interested in doing that, discovering it, and trying it out on some live installations, wouldn’t you agree that they should have to work for it?
Thanks guys,
I think it is the wording that makes it sound vague.
Version 1.6.4 is a security and maintenance release and is recommended for all users.
* Improved security and performance of cross-site scripting filter.
“Recommended” - in my mind means unnecessary or a matter of choice and I have nothing to worry about if I don’t.
“Improved” - better than before but not any particular security whole is closed.
Again, I am quite happy with EE (as I am sure you see in my post on lullabot and in this community) but I am seeing reasoning to why other developers may run away from EE. I am not posting to bash as much as say that there is room for improvement on how things are presented to public….for what is worth.
“Recommended” - in my mind means unnecessary or a matter of choice and I have nothing to worry about if I don’t.
Not quite. Surely “recommend” is understood to mean “advise as a course of action etc”? That’s exactly what is meant here: a piece of advice which you don’t have to follow, although we think you should.
I am not posting to bash as much as say that there is room for improvement on how things are presented to public….for what is worth.
There is always room for improvement, so thanks for your suggestions. Just let me close by saying that security is an issue we take pretty serious to begin with I think our track records speaks for us, too.
As our code is open, it’s possible that someone might look at a Diff, and reverse engineer an exploit after figuring out what we changed and why. Same would be the case with Drupal, and I don’t believe you’ll find them publishing step by step exploits either.
Hi, there!
Just wanted to poke my head in and voice agreement with Derek on this point. Drupal’s security announcements do not and will not ever include step by step exploits or ‘code samples’ for security holes. The announcements sent out are meant to help administrators quickly determine whether their sites are at risk (specific plugins involved, specific versions, etc) and point them to the relevant updates. As Derek says, there’s not really much good that can come of distributing detailed exploit instructions, no matter what security/announcement model is being used.
As our code is open, it’s possible that someone might look at a Diff, and reverse engineer an exploit after figuring out what we changed and why. Same would be the case with Drupal, and I don’t believe you’ll find them publishing step by step exploits either.
Hi, there!
Just wanted to poke my head in and voice agreement with Derek on this point. Drupal’s security announcements do not and will not ever include step by step exploits or ‘code samples’ for security holes. The announcements sent out are meant to help administrators quickly determine whether their sites are at risk (specific plugins involved, specific versions, etc) and point them to the relevant updates. As Derek says, there’s not really much good that can come of distributing detailed exploit instructions, no matter what security/announcement model is being used.
—Jeff Eaton
Hi Jeff,
Thanks for stopping by! Can’t agree more with what you said.
