[liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud
Nadim Kobeissi
nadim at nadim.cc
Tue Aug 6 21:20:21 PDT 2013
On 2013-08-06, at 4:49 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> Nadim Kobeissi:
>> On 2013-08-06, at 1:23 PM, Jacob Appelbaum <jacob at appelbaum.net>
>> wrote:
>>
>>> Nadim Kobeissi:
>>>>
>>>> On 2013-08-06, at 12:55 PM, Jacob Appelbaum
>>>> <jacob at appelbaum.net> wrote:
>>>>
>>>>> Nadim Kobeissi:
>>>>>>
>>>>>> On 2013-08-06, at 11:46 AM, Al Billings
>>>>>> <albill at openbuddha.com> wrote:
>>>>>>
>>>>>>> Nadim you seem confused by how this works. Tor doesn't need
>>>>>>> to issue advisories for Firefox issues. We, at Mozilla,
>>>>>>> already issue them. Perhaps they can link to them clearly
>>>>>>> but if you want to know about security issues Mozilla fixes
>>>>>>> in Firefox, you're best served by reading Mozilla
>>>>>>> advisories. There's not much point in duplicating them on a
>>>>>>> second site. Tor would be better served by writing
>>>>>>> advisories for its own, unique, security fixes.
>>>>>>
>>>>>> Tor doesn't need to issue advisories for Firefox issues. Tor
>>>>>> needs to issue advisories for Tor Browser issues, and not
>>>>>> five weeks later when s**t hits the fan. I really don't think
>>>>>> one can reasonably disagree with the above statement. Tor
>>>>>> Browser is a Firefox fork.
>>>>>
>>>>> Should we issue a single advisory for each possible security
>>>>> issue that Firefox has already noted in their change log? Each
>>>>> confirmed security issue? Should we ask for a second CVE to
>>>>> cover each CVE they receive?
>>>>
>>>> What's the alternative, Jake?
>>>
>>> That was a list of choices and you didn't choose one. Please choose
>>> one or more - though not all of them make sense when put together.
>>> It was a question and well, your answer isn't much of an answer.
>>
>> Yes, to be absolutely clear, I think Tor should issue advisories for
>> confirmed security issues in Tor Browser, since Tor Browser is a fork
>> of Firefox and is independently maintained. This is exactly what Tor
>> did this time, except next time you shouldn't wait five weeks for the
>> situation to explode.
>>
>
> This is where the confusion comes into play, I think. Please note the
> advisory we released this week:
>
>
> https://lists.torproject.org/pipermail/tor-announce/2013-August/000089.html
>
> We specifically address the one thing we *know* that is being exploited
> and we note that there are other issues, though we don't go into depth
> as upgrading is the only path forward.
>
> Now note the Mozilla security issues for the Firefox ESR releases:
>
> https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html
>
> You're on the one hand saying that we did the right thing and on the
> other, you're saying that we should issue an advisory for *confirmed*
> security issues. Mozilla confirmed a handful. Doesn't that imply that
> our advisory should have covered every thing Firefox fixed between
> versions? And if so, should we note everything, even if it doesn't
> *appear* to be a security issue? Just in case?
>
> Now on the one hand, you're saying we waited five weeks - when in fact
> we didn't, we released an advisory within a day of discovering that TBB
> was being targeted, which is different from Firefox generally I might
> add. We did also note with the release of 3.0alpha2 that it included
> security and stability fixes as we often do when we bump Firefox.
>
> So clearly between "hey, upgrade" and "exploit discovered" there is a
> middle ground. I'm confused by the middle ground you have chosen. It
> doesn't seem that we should wait until exploits are in the wild to note
> the security features of new releases (which we didn't, but we didn't
> issue an advisory for every Firefox issue), and yet, if an exploit is
> discovered, we should post an advisory that specifically addresses what
> we know about it, no?
>
>>>
>>>> Wait until the NSA exploits an innumerable amount of Tor users
>>>> and then quickly write an advisory for a bug that was quietly
>>>> fixed without a warning from Tor five weeks but still exploited?
>>>
>>> This is not accurate. We heard about attempts at exploitation and
>>> within ~24hrs we released an advisory - we had already released
>>> fixed code a ~month before exploitation was found in the wild.
>>> Please do not mix up the time-line. To restate:
>>>
>>>
>>> 2.3.25-10 (released June 26 2013) 2.4.15-alpha-1 (released June 26
>>> 2013) 2.4.15-beta-1 (released July 8 2013) 3.0alpha2 (released June
>>> 30 2013)
>>>
>>>
>>> The exploit was found in the wild on last weekend, I learned about
>>> it on or around August 4th. Please note that our patched versions
>>> were released nearly a month before this was found in the wild.
>>> There is no reason to support the conclusion that we "silently"
>>> fixed anything in response to an exploit. Please consider that your
>>> statement is entirely unsupported by evidence, Nadim.
>>
>> I could be mistaken. Where's the advisory that was issued the day
>> after, that mentions that a critical Tor Browser vulnerability was
>> fixed?
>>
>
> Once we triaged the bug with Mozilla - both Tor and Mozilla posted updates:
>
>
> https://blog.mozilla.org/security/2013/08/04/investigating-security-vulnerability-report/
>
>
> https://blog.torproject.org/blog/tor-security-advisory-old-tor-browser-bundles-vulnerable
You will note that this was posted recently. However, 5 weeks ago, Mozilla posted a security advisory for Firefox and fixed the issue. Tor then updated the Tor Browser Bundle with the fix, 5 weeks ago, *without releasing a security advisory.* You released the security advisory after shit hit the fan, this week, which is *five weeks later*. This is the point you keep avoiding. The advisory you released this week should have been released 5 weeks ago for Tor Browser, on the day Mozilla released an advisory for Firefox, and on the day you updated Tor Browser.
I spoke with Roger and he in fact confirmed that no advisory was released by Tor five weeks ago when Tor fixed the vulnerability. Tor waited until the exploit was in the wild.
NK
>
> We even posted a blog before we had all the details:
>
>
> https://blog.torproject.org/blog/hidden-services-current-events-and-freedom-hosting
>
> We also noted on June 30th that 3.0alpha2 included Firefox security
> fixes. This wasn't an advisory, it was a release note.
>
>>>
>>>> Because that is exactly what happened this time. Tor can just go
>>>> on doing this again and again, or yes, you could issue
>>>> advisories. You are maintaining your own browser called Tor
>>>> Browser. Stop shifting blame onto Firefox. You're the guy who
>>>> told me to never shift blame when you have a security
>>>> vulnerability in the software you yourself are shipping. Practice
>>>> what you preach.
>>>>
>>>
>>> Your assessment of this situation is incorrect.
>>>
>>> We regularly release updates that include updates to included code
>>> and often, we make note of the fact that the upstream code has
>>> security fixes included. There is no blame shifting, only a
>>> question of how to best share that information in a way that users
>>> will understand. I have asked repeatedly for examples and for
>>> details of how to improve things - you seem only interested in
>>> slinging mud. Perhaps this isn't the most useful way forward?
>>
>> How am I only interested in slinging mud?! How are you even allowed
>> to adopt a tone like this while doing your job as an advocate for
>> Tor? I'm simply trying to advocate for Tor not waiting five weeks
>> before releasing an advisory next time! Comments like this are really
>> just not acceptable, Jake.
>>
>
> We didn't wait five weeks, we had an advisory out for the exploitation
> issue within a single day. And if you find the latest security advisory
> to be OK, I wonder then what you think about the other Mozilla security
> issues involved in the update? Shouldn't each one, by your line of
> argument, get their own advisory email and blog post?
>
> Rather than making this personal and talking about what my job is about,
> I'd appreciate it if you could focus on the discussion topic at hand. If
> you have specific improvements to the process, we're open to hearing
> them and please do feel free to cite your process, your example or
> another project that does it to your liking. That doesn't mean that
> we'll adopt it, it just means that we're open to listening, even if
> there is high tension between some of the people involved.
>
> Thanks again for helping to improve Tor Browser!
>
> All the best,
> Jacob
> --
> Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
More information about the liberationtech
mailing list