[Pkg-anonymity-tools] torbrowser-launcher 0.2.0 - apparmor bug

[intrigeri]

Hi,

[sorry for the delay.. and don't expect me to get better any time soon.]

Micah Lee wrote (19 May 2015 21:00:43 GMT) :
> On 05/19/2015 01:00 PM, Holger Levsen wrote:
>> On Dienstag, 19. Mai 2015, intrigeri wrote:
>>> I've suggested upstream to simply give up confining that script:
>>> https://github.com/micahflee/torbrowser-launcher/issues/181#issuecomment-10
>>> 3414762
>>>
>>> Perhaps we can do that in Debian right now?
>> seems sensible to me, for the reasons you've given.
>>

> I've implemented this and pushed it to master. Just waiting on someone
> who isn't me to confirm that I it actually works before closing the
> issue [1].

> [1] https://github.com/micahflee/torbrowser-launcher/issues/181

In Debian we went ahead 2.5 months ago, and set
torbrowser.start-tor-browser and usr.bin.torbrowser-launcher to
confine mode, until you drop them entirely upstream. IIRC the initial
discussion was about start-tor-browser only, but since then we've seen
similar issues with the torbrowser-launcher profile, so I've disabled
it for similar reasons (not very useful security-wise, a pain to
maintain properly).

> Soon I can release 0.2.1 which will fix this issue.

Any news on this one?

> I also want to solve
> a future verification problem [2] in this release too though, and I'm
> waiting on hearing back from Mike Perry about his opinion on how to go
> about doing it. Maybe this list can help with the direction?

> Basically, right now TBL downloads sha256sums.txt and
> sha256sums.txt.asc, verifies the signature, then downloads the TBB
> binary, and makes sure its sha256 checksum matches what's in
> sha256sums.txt. But TBB is now codesigning Windows binaries, and
> sha256sums.txt includes the hashes of pre-codesigned .exe files, and so
> Windows users are getting confused. Because of this, the TBB people are
> renaming sha256sums.txt to sha256sums-unsigned-build.txt, and for now
> there's a temporary redirect so that TBL and other automatic downloaders
> will continue to work.

> So the two ways to fix this would be:

> 1) Download and verify the sig for sha256sums-unsigned-build.txt instead
> of sha256sums.txt. This should be fine for Linux, because there's no
> post-build codesigning process that modifies the Linux binaries.

> 2) Stop using the checksum file at all, and instead download and verify
> the sig for each individual binary, e.g.
> tor-browser-linux64-4.5.1_en-US.tar.xz and
> tor-browser-linux64-4.5.1_en-US.tar.xz.asc. This has the benefit of
> definitely working in the future, but like adrelanos points out in the
> bug, using a checksum file helps authenticate filenames, not just the
> content of the binaries.

> Does anyone prefer one to the other?

I lack info to judge if / how much going for (2) would decrease the
security provided by torbrowser-launcher, and lack time to look for it
myself. I'll just get the security analysis started:

The question essentially is: what does it take *currently* for an
attacker to do version rollback, package substitution or infinite
freeze attacks? And would going for (2) decrease that at all /
how much?

IIRC we get RecommendedVersions via HTTPS with some certificate
pinning, and from that we compute the URL to sha256sum.txt{,.asc},
etc., so an attacker who can break that HTTPS connection can do
version rollback and infinite freeze attacks already, right?

(Perhaps TBL protects somewhat against rollback attacks by comparing
the version that's in the authentified tarball, though?)

... once this analysis is completed, we'll have the data we need to
evaluate (2) vs. (1).

> [2] https://github.com/micahflee/torbrowser-launcher/issues/180

Cheers,
-- 
intrigeri