Firefox [Tor] Browser 0day: Anti-Privacy Implantation at Mass Scale
https://hackernoon.com/tor-browser-exposed-anti-privacy-implantation-at-mass... https://blog.torproject.org/blog/tor-browser-605-released Introduction: The combination of chaining the vulnerabilities described below allows a malicious exit node operator or global adversary to conduct a silent remote code execution attack on all platforms of the Tor Browser. This attack is not limited to just being hypothetical in nature and evidence shows that this attack has already been possible for a number of years. The list of vulnerable deployments to this attack includes the native Tor Browser for Windows, Linux, OSX and also includes Tor Browser installations on dedicated operating systems such as Tails and Whonix. The entire security of the Tor Browser ecosystem relies on the integrity of a single TLS certificate that has already been previously compromised. Efforts to mitigate these types of risks through certificate pinning appear to not have been correctly implemented with regard to the extension update process and also appear to provide no protection. This attack enables arbitrary remote code execution against users accessing specific clearnet resources when used in combination with a targeting mechanism; such as by passively monitoring exit node traffic for traffic destined for specific clearnet resources. Additionally this attack enables an attacker to conduct exploitation at a massive scale against all Tor Browser users and to move towards implantation after selected criteria are met (such as an installed language pack, public IP address, DNS cache, stored cookie, stored web history, and etc). Quick financial estimates put the cost to launch such an attack at roughly $100,000 USD for maximum impact. To put in clearer perspective; this attack costs an attacker 0.06 USD per compromised machine given that 1.5 million users operate on Tor at any given time. Ultimately the combination of all vulnerabilities and the resources required to stage such an attack is well within the reach of a nation-state or criminal organization. Responsible Disclosure Attempts: This vulnerability was originally described publicly in concept before the initial confirmation of the feasibility of the attack. Reaction to the theoretical disclosure was mocked as non-credible by Micah Lee and Andrea Shepard (individuals associated with the Tor Project Incorporated).
On Fri, Sep 16, 2016 at 12:32:23PM -0400, grarpamp wrote:
https://hackernoon.com/tor-browser-exposed-anti-privacy-implantation-at-mass... https://blog.torproject.org/blog/tor-browser-605-released
Is Debian _still_ vulnerable to automatic updates, it used to be?: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820698;msg=5 Debian's Firefox/iceweasel in a VM still give warnings about autoupdates of addons when started from terminal (otherwise they are not visible ;) )
On Fri, Sep 16, 2016 at 1:18 PM, Georgi Guninski <guninski@guninski.com> wrote:
Is Debian _still_ vulnerable to automatic updates, it used to be?: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820698;msg=5 Debian's Firefox/iceweasel in a VM still give warnings about autoupdates of addons when started from terminal (otherwise they are not visible ;) )
Here's FreeBSD's take on the issue... https://lists.freebsd.org/pipermail/freebsd-announce/2016-August/001739.html Nevermind that they still [1] don't have their release iso's and everything else fully reproduceable and cryptographically traceable back to their source repository, in part because their silly choice of repo (svn) isn't capable of establishing cryptographic provenance over, and distribution of, the source, so unlike signable trees git or monotone there's a big gaping disconnect there. Though they are making good progress on reproduceability. Oh, and OpenBSD still uses cvs for code authenticity, lol. Don't mistake this to mean that Linux distroland and model is anything close to secure either. It's probably much worse. [1] They claim signed / hashed isos and packages, and server / filesystem / commiter / sysadmin security / integrity are backtraceable and sufficient. And that monotonically increasing numeric commit revID's and 'workflow' prevent using something like git. I claim baloney.
At least you can easily build your entire user land and kernel (and ports) on FreeBSD. It's very straight forward compared to Linux distros (Gentoo/arch some what excluded I guess). I suppose this isn't much consolation if you're worried about the upstream svn repo itself..... Generally I trust that svn updates are not pulling down back doored code. I don't have the time (or the capacity) to read though all of /usr/src.... Trying to use ports built from source along side prebuilt binaries from pkg is a complete fucking nightmare on FreeBSD. I routinely have to hack the pkg SQLite db file to make pkg audits reflect the actual state of my system. Need to invest some time in poudriere.... John
On Sep 16, 2016, at 2:29 PM, grarpamp <grarpamp@gmail.com> wrote:
On Fri, Sep 16, 2016 at 1:18 PM, Georgi Guninski <guninski@guninski.com> wrote: Is Debian _still_ vulnerable to automatic updates, it used to be?: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820698;msg=5 Debian's Firefox/iceweasel in a VM still give warnings about autoupdates of addons when started from terminal (otherwise they are not visible ;) )
Here's FreeBSD's take on the issue... https://lists.freebsd.org/pipermail/freebsd-announce/2016-August/001739.html
Nevermind that they still [1] don't have their release iso's and everything else fully reproduceable and cryptographically traceable back to their source repository, in part because their silly choice of repo (svn) isn't capable of establishing cryptographic provenance over, and distribution of, the source, so unlike signable trees git or monotone there's a big gaping disconnect there. Though they are making good progress on reproduceability.
Oh, and OpenBSD still uses cvs for code authenticity, lol.
Don't mistake this to mean that Linux distroland and model is anything close to secure either. It's probably much worse.
[1] They claim signed / hashed isos and packages, and server / filesystem / commiter / sysadmin security / integrity are backtraceable and sufficient. And that monotonically increasing numeric commit revID's and 'workflow' prevent using something like git. I claim baloney.
On Fri, Sep 16, 2016 at 2:56 PM, John Newman <jnn@synfin.org> wrote:
Generally I trust that svn updates are not pulling down back doored code. I don't have the time (or the capacity) to read though all of /usr/src....
Only about that in part, but also just taking random corrupted bits. If you're not wrapping everything in your toolchain in crypto, originating at and in the repo, the path the backdoored code takes to you is bound to take gain hits sooner or later. On the plus side, maybe those hits will neuter the backdoor sometime before the seas boil. But you get the point.
Trying to use ports built from source along side prebuilt binaries from pkg is a complete fucking nightmare on FreeBSD. I routinely have to hack the pkg SQLite db file to make pkg audits reflect the actual state of my system. Need to invest some time in poudriere....
If a given port doesn't have a package, maybe invest in committing the build bits to your OS of choice so that it does.
On Fri, Sep 16, 2016 at 03:12:23PM -0400, grarpamp wrote:
If a given port doesn't have a package, maybe invest in committing the build bits to your OS of choice so that it does.
Actually, I am talking about stuff out of /usr/ports. What has gotten my system kind of fucked up is changing default options (running make config in the port and tweaking something). After building and running make install it is "converted" to a pkg but it no longer matches up with the binary builds distributed by FreeBSD because I screwed with the options... Additionally, "pkg audit" gives me bizarre results sometimes, e.g. "perl5.16 is EOL"... well, yes perl5.16 is installed on my system, but so is perl5.20 (which is the default). And the problem is there is no longer a /usr/ports/lang/perl5.16 to run "make uninstall", and trying to remove it with "pkg remove perl5.16" attempts to wipe out ALL SORTS of stuff that has no actual dependency on this deprecated version of perl which I have chmod -x'd. So, I leave the mode 0000 /usr/local/bin/perl5.16 and delete the package entry for it out of /var/db/pkg/local.sqlite. Quite ugly I know! Anyway, its mainly a hobby server for me, so I don't mind just building everything from source. I have plans to start it over using poudriere from the beginning (this was the first time I have revisited FreeBSD in 10 years or so..). John
On Fri, Sep 16, 2016 at 02:56:11PM -0400, John Newman wrote:
At least you can easily build your entire user land and kernel (and ports) on FreeBSD. It's very straight forward compared to Linux distros (Gentoo/arch some what excluded I guess). I suppose this isn't much consolation if you're worried about the upstream svn repo itself.....
Git has built in svn support these days anyway - to claim svn is vital due to some workflow, is as grarpamp stated, total baloney. Attachment to svn is the grumpy old man yellin "get orf mah lawn" and the kid using git points to his hover board that he's standing on and smirks while saying "I'm not ON your lawn old man, I's floatin" then grabs his ball off the grass and zooms off over the hedge. Can understand that some folks don't want to break a trail on the bleeding edge, but git ain't a makerspace quad copter test bed any more, it's a highly polished retail product with zoom stripes on the side. 11 years - a long time for continually developed software..
On Sep 16, 2016, at 7:46 PM, Zenaan Harkness <zen@freedbms.net> wrote:
On Fri, Sep 16, 2016 at 02:56:11PM -0400, John Newman wrote:
At least you can easily build your entire user land and kernel (and ports) on FreeBSD. It's very straight forward compared to Linux distros (Gentoo/arch some what excluded I guess). I suppose this isn't much consolation if you're worried about the upstream svn repo itself.....
Git has built in svn support these days anyway - to claim svn is vital due to some workflow, is as grarpamp stated, total baloney.
Attachment to svn is the grumpy old man yellin "get orf mah lawn" and the kid using git points to his hover board that he's standing on and smirks while saying "I'm not ON your lawn old man, I's floatin" then grabs his ball off the grass and zooms off over the hedge.
Can understand that some folks don't want to break a trail on the bleeding edge, but git ain't a makerspace quad copter test bed any more, it's a highly polished retail product with zoom stripes on the side.
11 years - a long time for continually developed software..
I agree - but try telling that to the FreeBSD folks :P John
On Fri, Sep 16, 2016 at 02:29:53PM -0400, grarpamp wrote:
Nevermind that they still [1] don't have their release iso's and everything else fully reproduceable and cryptographically traceable back to their source repository, in part because their silly choice of repo (svn) isn't capable of establishing cryptographic provenance over, and distribution of, the source, so unlike signable trees git or monotone there's a big gaping disconnect there. Though they are making good progress on reproduceability.
Oh, and OpenBSD still uses cvs for code authenticity, lol.
Did all BSDs have sound integrity checks when updating or installing new stuff? About 8 years ago Freebsd installed ports and or packages fetching them from plain ftp, without integrity checks IIRC.
participants (4)
-
Georgi Guninski -
grarpamp -
John Newman -
Zenaan Harkness