11

So it came up today; our first question that specifically digs into the bone of a security patch that Sitecore released yesterday.

Technical vulnerability details on Sitecore critical vulnerability (SC2016-001-128003)

Initially, Dmytro responded in full - thereby exposing not only what the vulnerability was, but in doing so - how one could easily engineer an attack to exploit the vulnerability.

Community quickly reacted "on the side of caution" by voting to close the question, but the question remains.

What should our policy be, on such questions?

As many argue; a bit of information on the vulnerability would help them convince local IT to patch asap. While I personally believe that "Unauthorized code execution" should be more than enough reason, I realise that we don't live in a perfect world.

But then there's the fine line; if we discuss the vulnerability in too much detail - we risk further exposing the vulnerability and putting customers at risk.

Or we just shut them down; consider them entirely off topic.

Keep in mind; the context is a 0 day vulnerability where no one has had any chance to apply the patch yet.

Thoughts?

1
  • Even though it has been announced as a zero-day, it really is not. Sitecore has had time to create a hotfix (and probably test this as well). If Sitecore had announced the vulnerability as soon as they confirmed it, it would be a different case altogether. They could have published an early warning, with a viable workaround (eg. delete Pushsession.aspx), but they chose not to. Commented Oct 19, 2016 at 8:47

7 Answers 7

10

I think this is an interesting example. A fresh vulnerability and the community (very correctly) wants to know a little bit more details as they will be assessing how best they should act. It is entirely fair that they reach out to others in the community for help and this is what this stack exchange is for.

The issue is that being on the web any info like this is now publically searchable / cachable etc and in answering we must be careful not to share too many specifics so that lazy attackers could craft something very easily. Answers on here, i think , should probably focus on mitigation and workarounds.

I think Dmytro's second (and current) answer is perfect, it shows a quick method of mitigation (deleting the offending page) that wasnt present in the original posting from Sitecore and so is a very useful answer for people in charge of securing their systems.

I think it is a issue for the mods in terms of how closely they need to pay attention to these things but I think this was flagged and corrected quickly. It was tagged as 'security' so its easy to filter and examine.

6

Great question, let me see if I can get an official statement from Sitecore on this.

3
  • That input would be appreciated :-) I think the current consensus is - we want to keep things open, but we don't want to act irresponsibly either.
    – Mark Cassidy Mod
    Commented Oct 18, 2016 at 19:55
  • Did you get anything on this Pieter? We will try and compile a Community Wiki summarising all the inputs gained on this post - an official statement from Sitecore on this matter would weigh heavily in that. At least that is the sense I get, from reading through all the comments here.
    – Mark Cassidy Mod
    Commented Oct 21, 2016 at 1:27
  • Just send a friendly reminder to get some official statement and guideline from the right department. I'll keep you posted. Commented Oct 28, 2016 at 8:12
5

I'm personally kind of surprised about the amount of people that are against discussing vulnerability details.

Firstly, hiding information -- especially about security vulnerabilities -- doesn't help anyone. There should be a free and open discussion so that not only can people learn what not to do in their own code base, but it allows people to reasonably test their systems for the vulnerability that has apparently been patched and similar vulnerabilities with their new set of working knowledge.

Secondly, while there is a good case for not providing a free, copy and paste exploit on SSE the fact of the matter is that it is not up to the community to prevent such solutions from being passed around. It's Sitecore's, the actual company, job to disclose vulnerabilities of this magnitude to its major partners and vendors in a quiet fashion first -- but this window needs to be incredibly small. They shouldn't give them weeks or months.

Once the vulnerability is publicly released and people with a decent enough skill can decompile the updated binaries, there is no point in silencing discussion around it. It's already public. It's pretty unlikely that anyone with the means and skills to carry out something nefarious is going to care about who is discussing it, nor will they need people to point them in the right direction. It's my belief that by taking such a stance, we're really harming the community as a whole.

I think Bruce Schneier sums this up in a very succinct fashion:

What we've learned during the past eight or so years is that full disclosure helps much more than it hurts.

[...]

This democratization is important. If a known vulnerability exists and you don't know about it, then you're making security decisions with substandard data. Word will eventually get out -- the Window of Exposure will grow -- but you have no control, or knowledge, of when or how. All you can do is hope that the bad guys don't find out before the good guys fix the problem. Full disclosure means that everyone gets the information at the same time, and everyone can act on it.

And detailed information is required. If a researcher just publishes vague statements about the vulnerability, then the vendor can claim that it's not real. If the researcher publishes scientific details without example code, then the vendor can claim that it's just theoretical. The only way to make vendors sit up and take notice is to publish details: both in human- and computer-readable form. (Microsoft is guilty of both of these practices, using their PR machine to deny and belittle vulnerabilities until they are demonstrated with actual code.) And demonstration code is the only way to verify that a vendor's vulnerability patch actually patched the vulnerability.

[...]

Full disclosure is essential if we are to continue to improve the security of our computers and networks.

From: https://www.schneier.com/crypto-gram/archives/2001/1115.html

I think Responsible Disclosure is reasonable, given limited windows. Responsible Disclosure is something that needs to happen between Sitecore and its sizable partners. However, the moment Sitecore publicly released the patch the timeline for Responsible Disclosure ended. The information is public. Hiding discussion about the issue hasn't historically mitigated exploits when the vulnerability is known and can easily be reconstructed from the publicly available patch.

By giving people all the necessary information about the vulnerability, including code, we give them the ability to not only understand the issue, but verify the patch works on their system, look for any similar exploits that exist either within Sitecore or the implementation, and also hopefully prevent anyone from making similar mistakes in the future.

Full Disclosure increases community knowledge and safety. Responsible Disclosure can do this in a reasonable way while alleviating certain fears about potential attacks. But Responsible Disclosure only works when the exploit is not public. The exploit is now public. We cannot reverse Sitecore's public announcement and we surely can't pretend that this is the only place people will discuss this issue in its various forms. So what does the community truly gain by preventing discussion and disclosure around the vulnerability on SSE?

11
  • All you can do is hope that the bad guys don't find out before the good guys fix the problem - You're quoting out of context. A fix has been provided, Sitecore are not claiming it is theoretical, since they are the ones providing the fix. No one is against discussing, just not the internals immediately.
    – jammykam
    Commented Oct 18, 2016 at 13:50
  • 2
    The entire statement is addressing multiple scenarios on handling vulnerabilities, so I don't think it's really out of context, that specific statement is just not applicable to the current situation. The whole statement in its entirety is relevant to how Sitecore handled it and how we're handling it on SSE, especially this: And demonstration code is the only way to verify that a vendor's vulnerability patch actually patched the vulnerability. I can remove the first paragraph just for the sake of being contextual, but I think it's relevant and important enough to include. Commented Oct 18, 2016 at 14:09
  • 1
    Yeah, I think the point here is that it's a healthy thing to discuss vulnerabilities in general. But providing details right after the vulnerability became public is bad from the ethical standpoint. Since they have provided a fix and notified everyone, there's not much else Sitecore can do. We as a community, on the other hand, should try to minimize the possibility that affected solutions get hacked before they have a chance to apply the fix. So my current mindset is that we should wait for at least a couple of weeks before discussing this vulnerability in detail. Commented Oct 18, 2016 at 14:09
  • Most bug bounty reports and blog posts include very detailed information about the vulnerability, what the issue was and how it could be exploited. They also include a timeline of responsible disclosure after the fact the security hole has been fixed. Taken in the context of something like Facebook that report could be the next day without consequence. I think it is reasonable and ethical as @DmytroShevchenko says to allow all those affected some time to patch their systems, given it is not "over the air" update.
    – jammykam
    Commented Oct 18, 2016 at 14:20
  • 1
    For me, by saying "here's a vulnerability", and then not providing details (code, break down, etc) that's not giving anyone the ability to verify the patch, nor is it giving them the required information about what's wrong with their system, while also inherently trusting the source of the vulnerability that they have in fact fixed it appropriately, and that there aren't similar exploits elsewhere within the system; in this case either from Sitecore or the implementation. I think there is an important difference between providing an executable for the exploit, and providing code. Commented Oct 18, 2016 at 14:22
  • Have you tried contacting Sitecore [Support] directly and asking them for this information?
    – jammykam
    Commented Oct 18, 2016 at 14:27
  • 3
    @jammykam Right, but we are the public. The exploit is now public. The timeline for responsible disclosure ended the moment Sitecore publicly released the fix. History has shown that you do not mitigate issues by not discussing details when the exploit is now known and can be used against anyone. If I find an exploit within Sitecore, I'm not going to immediately release all the details. I would do the ethical thing. I would notify Sitecore and give them a deadline on when it needs it be addressed, as is often the case when researchers find exploits. I think we're just past that IMO. Commented Oct 18, 2016 at 14:33
  • 1
    @jammykam I have not, nor do I have the personal ability to. But I don't think that's reasonable to assume everyone who needs that information should have to go that route. We're also trying to make that information available here, for everyone. Commented Oct 18, 2016 at 14:35
  • Well I can only provide you my opinion and my understanding of the issue. I can't really add any more than what has already been stated in the other answers, which I agree with.
    – jammykam
    Commented Oct 18, 2016 at 14:38
  • 1
    This is a really thought-provoking answer. I'm torn: I agree that we should share infor about what is fixed, but I also understand the caution raised by @jammykam. In the last few comments, opposing sides of the same issue were hit: whose responsibility was it to provide the structure for a "silent" release of this patch (reasonable disclosure, etc)? Justin says that it was Sitecore's prerogative and I somewhat agree, since it's their system. JammyKam says the community because Sitecore fell short this time. I agree with that too. I think that is the question that should be raised to Sitecore. Commented Oct 19, 2016 at 3:58
  • Didn't mean to put words in anyone's mouths - just ran out of characters for the comment lol. The point is that you both have very persuasive arguments and while I think that the answer may lay somewhere in the middle (hence my very shallow overview blog post describing what the security patch was for) I think that the final decision on this one should probably rest with Sitecore. Commented Oct 19, 2016 at 4:01
4

Here's what I think.

  • I believe that questions around Security Patches in general are completely on topic for this site
  • I do believe any professional should show some restraint in discussing the internal workings of any discovered or undiscovered vulnerability
  • I do believe any vulnerability less than 30 days old is off topic for discussion on this site
  • I do believe that any discussion around a vulnerability should never show a "box solution" for, how to exploit the vulnerability. It should remain vague.

In this instance; I think the real issue is the fact that the vulnerability is a 0 day vulnerability. One labelled "Critical", even.

I would refer to Responsible Disclosure principles and defer any questions on this particular patch to at least 30 days from now.

EDIT: Updated with the below

A very interesting discussion around this is also found here: https://security.stackexchange.com/a/6597

Quoting from an even longer article by Bruce Schneier: The section about Full Disclosure.

3

Security patches are publicly available, and if you download one and unzip two files you can look at everything included in it, including DLLs and configs. Once you have that, you can decompile and see what's in the DLL - Sitecore didn't obfuscate it. I'm pretty sure that the "bad guys" can figure this out.

My thoughts are that if Sitecore doesn't obfuscate then there shouldn't be a concern about the details being made public.

4
  • 1
    Technically it's against the License terms: 1.4 Restrictions on Use: ... Licensee shall not copy, in whole or in part, the Sitecore Software or Documentation, or *modify, disassemble, decompress, reverse compile, reverse assemble, reverse engineer,* or translate any portion of the Sitecore Software. Yes we all do it, myself included, so just pointing it out.
    – jammykam
    Commented Oct 18, 2016 at 12:36
  • True and I take your point, @jammykam. I'm just saying that a hacker isn't going to care about the license and they have as much access to decompile this as I do, since the patch is public and you don't need to even log in to download it. Commented Oct 18, 2016 at 12:50
  • 2
    Yes, agree with you. Each person has to make their own call on the info they are willing to provide, but see Mark's point about Responsible Disclosure. All security/bug reports I have seen follow that same pattern, esp with 0-days.
    – jammykam
    Commented Oct 18, 2016 at 13:03
  • @jammykam I see your point +1. I will have to think more on this and look a little more into it Commented Oct 18, 2016 at 13:05
1

My opinion is that we should update this page:

https://sitecore.stackexchange.com/help/on-topic

We should list the topics that are allowed and the topics that are explicitly forbidden.

One of the forbidden topics should be discussing the internals of security vulnerabilities that became public less than (for example) 2 weeks ago.

1
  • 2
    I agree, internals of very recent vulns should be off-topic Commented Oct 18, 2016 at 9:49
0

A process should probably be determined for when too many details on how to reproduce the exploit are provided by a user. They can of course edit the post to remove them, but they still remain in the post's history for others to find.

It would probably be wise to delete the post and then either repost an edit on behalf of the user, or ask them to repost.

While the site is in beta, 2000 rep is required to access moderator tools including viewing deleted posts. This goes up to 25000 when out of beta. Therefore some protection is provided.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .