Tor Browser issueshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues2022-01-11T19:32:14Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20439The firefox binary in Tor Browser on OSX is not PIE2022-01-11T19:32:14ZboklmThe firefox binary in Tor Browser on OSX is not PIE`otool -hv` says that the firefox binary from Tor Browser on OSX is not PIE:
```
$ otool -hv firefox
firefox:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 ...`otool -hv` says that the firefox binary from Tor Browser on OSX is not PIE:
```
$ otool -hv firefox
firefox:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 22 2752 NOUNDEFS DYLDLINK TWOLEVEL BINDS_TO_WEAK
```
While on the firefox binary from Mozilla, it says this:
```
$ otool -hv /Volumes/Firefox/Firefox.app/Contents/MacOS/firefox
/Volumes/Firefox/Firefox.app/Contents/MacOS/firefox:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 22 2744 NOUNDEFS DYLDLINK TWOLEVEL BINDS_TO_WEAK PIE
```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20377Tor Browser crashes when certain prefs are forced via autoconfig.js.2022-01-11T19:32:14ZYawning AngelTor Browser crashes when certain prefs are forced via autoconfig.js.Firefox has a mechanism for overriding preferences, that would be useful for me to set sandboxed Tor Browser specific prefs, without resorting to the kludgy hack that I do now with writing out a `prefs.js` file.
https://developer.mozill...Firefox has a mechanism for overriding preferences, that would be useful for me to set sandboxed Tor Browser specific prefs, without resorting to the kludgy hack that I do now with writing out a `prefs.js` file.
https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment
Tor Browser 6.0.5 appears to crash when `lockPref("extensions.update.enabled", false);` is including in the autoconfig.js file, though other prefs that I have tried appear to work fine.
Minor for me since there are other ways I can do this.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20352Integrate sandboxed Tor Browser into our gitian build system2022-01-11T19:32:14ZGeorg KoppenIntegrate sandboxed Tor Browser into our gitian build systemWe should write a descriptor for building the sandbox code inside our Gitian environment.We should write a descriptor for building the sandbox code inside our Gitian environment.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20326Tor Browser forgets HTTPS sometimes2022-06-18T03:35:15ZbugzillaTor Browser forgets HTTPS sometimesFound on BMO. The reason is unknown. To see how it looks like, someone can use https://www.fxsitecompat.com/en-CA/index.xml, but that seems to be another bug (and not one ;)
Page Info looks like this:
![HTTPSwoHTTPS.png](uploads/HTTPSwoH...Found on BMO. The reason is unknown. To see how it looks like, someone can use https://www.fxsitecompat.com/en-CA/index.xml, but that seems to be another bug (and not one ;)
Page Info looks like this:
![HTTPSwoHTTPS.png](uploads/HTTPSwoHTTPS.png)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20304SOCKS socket does not support spaces and other special characters2022-01-11T19:32:14ZMark SmithSOCKS socket does not support spaces and other special charactersWhile working on legacy/trac#20111, Kathy and I found a bug in Firefox's SOCKS socket support: special characters, including spaces, are not decoded before the configured path is placed inside a Unix domain sockaddr. This causes the SOCK...While working on legacy/trac#20111, Kathy and I found a bug in Firefox's SOCKS socket support: special characters, including spaces, are not decoded before the configured path is placed inside a Unix domain sockaddr. This causes the SOCKS connection to not work at all when a Unix domain socket is used with a path that contains spaces (or other URL-special characters).
We are working on a patch which we will also want to uplift to Firefox. I will file a Firefox bug later.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20283Tor Browser should run without a `/proc` filesystem.2022-01-11T19:32:14ZYawning AngelTor Browser should run without a `/proc` filesystem.Currently Tor Browser crashes immediately on startup if a proc filesystem is not mounted on `/proc`. This also affects the upstream firefox code, so it technically is a Mozilla bug.
```
too much recursion
Segmentation fault (core dumpe...Currently Tor Browser crashes immediately on startup if a proc filesystem is not mounted on `/proc`. This also affects the upstream firefox code, so it technically is a Mozilla bug.
```
too much recursion
Segmentation fault (core dumped)
```
`/proc` contains a large amount of information about the host system that can be used to fingerprint/identify users and additionally historically has been the source or part of many kernel security problems.
While this problem can be mitigated by a MAC system (eg: AppArmor) to constrain what Firefox can access under `/proc`, the ideal fix is for Firefox to support running without `/proc`, while degrading gracefully (there is no truly ubiquitous MAC system available on all common Linux distributions by default, and the problem is severe enough that it should be resolved correctly).richardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20240Set ASan verbosity on --debug (hardened browser)2022-01-11T19:32:14ZcypherpunksSet ASan verbosity on --debug (hardened browser)start-tor-browser supports --debug/--verbose. Please set "verbosity" in $ASAN_OPTIONS when it's used, given the history of problems with that feature.
related: legacy/trac#20238, legacy/trac#20237, legacy/trac#19851start-tor-browser supports --debug/--verbose. Please set "verbosity" in $ASAN_OPTIONS when it's used, given the history of problems with that feature.
related: legacy/trac#20238, legacy/trac#20237, legacy/trac#19851https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20238Hardened browser should have a way to disable ASan2022-01-11T19:32:14ZcypherpunksHardened browser should have a way to disable ASanI've been hit twice recently by Address Sanitizer bugs (legacy/trac#20237, legacy/trac#19851). It's always a huge pain to figure out what's happening, and then to work around it. I had to grab an old glibc and hack around with $LD_PRELOA...I've been hit twice recently by Address Sanitizer bugs (legacy/trac#20237, legacy/trac#19851). It's always a huge pain to figure out what's happening, and then to work around it. I had to grab an old glibc and hack around with $LD_PRELOAD for one, screw around with ulimits for the other. And I need to boot a Tails VM to get a working browser to search for the error messages (which aren't even printed by default), and then copy/paste is difficult.
start-tor-browser should have a documented option to disable ASan. And the script shouldn't just clobber ASAN_OPTIONS if it's set, because that just complicates debugging (prepend/append your string instead).https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20221Hardened Tor Browser does not produce stack traces.2022-01-11T19:32:14ZMike PerryHardened Tor Browser does not produce stack traces.In legacy/trac#19515 and other bugs, we seem not to be getting full stack traces for issues.
It is common just to get: "==537696==AddressSanitizer: while reporting a bug found another one. Ignoring." or similar, rather than something th...In legacy/trac#19515 and other bugs, we seem not to be getting full stack traces for issues.
It is common just to get: "==537696==AddressSanitizer: while reporting a bug found another one. Ignoring." or similar, rather than something that could be converted with the symbolizer as per https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#ConvertASansstacktracemessage.
As per https://github.com/google/sanitizers/issues/391, it sounds like we may just need to add fast_unwind_on_fatal=1 to our ASAN_OPTIONS? Or maybe we need to update/switch to the latest stack unwinder: https://code.google.com/p/chromium/issues/detail?id=490275
I think it is pretty important to get this working, as I've experienced a couple crashes I couldn't do anything about. The ability to get valid crash report data from the wild from our hardened builds is extremely valuable.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20146Firefox bug - (CVE-2016-5284) ESR-45/Tor Browser certificate pinning bypass f...2022-06-18T03:12:25ZTracFirefox bug - (CVE-2016-5284) ESR-45/Tor Browser certificate pinning bypass for addons.mozilla.org and other built-in sites**A. SHORT BACKGROUND**
As originally reported by [@movrcx](https://twitter.com/movrcx/status/775817737574633472) and subsequently analyzed by [Ryan Duff](http://seclists.org/dailydave/2016/q3/51), Mozilla Firefox ESR 45 (upon which Tor...**A. SHORT BACKGROUND**
As originally reported by [@movrcx](https://twitter.com/movrcx/status/775817737574633472) and subsequently analyzed by [Ryan Duff](http://seclists.org/dailydave/2016/q3/51), Mozilla Firefox ESR 45 (upon which Tor Browser 6.0.4 is built) does not currently honor its static certificate pinning.
In theory, TLS connections to Mozilla AUS and AMO servers (e.g. [*.]addons.mozilla.org, aus4.mozilla.org, aus5.mozilla.org) and other built-in sites are validated by ensuring:
1. a chain can be constructed from the server-provided certificate to a trusted root certificate; and
1. the constructed trusted certificate chain matches the pinset (either dynamically provided via HPKP _Public-Key-Pins_ headers or hard-coded in static lists).
In particular, Mozilla's AUS and AMO servers don't currently emit HPKP headers so they're checked against built-in static pins.
**B. PROBLEM**
Here's the rub:
* Firefox static pins have a 90-day lifetime after which they're no longer binding
* Mozilla's automated static pin expiry extension process [appears to be broken](https://bugzilla.mozilla.org/show_bug.cgi?id=1303127)
As a result ESR 45.3 static pins expired on September 3, 2016.
_Whoa! What does this all mean?_
In short, since September 3, 2016, anyone using ESR 45.3/TBB 6.0.4 (or earlier) is vulnerable to MiTM attacks from adversaries in possession of certificates that properly validate through to Firefox's trusted root store (__no pinning enforced__). In other words, of the two conditions mentioned above, only the first needs to be met.
Such an adversary could, in theory, have an [*.]addons.mozilla.org certificate and use it to deliver malicious payloads via crafted add-on updates (e.g. NoScript).
_Note_: It should be mentioned that though the second condition is not being enforced, the first condition is not trivially met. However, it's hurdle that's certainly within the reach of sophisticated adversaries such as state-level actors.
**C. RECOMMENDATION**
Mozilla's decision to cap static pin lifetimes at 90 days is to prevent sites from blacklisting themselves (balancing security and usability). Tor Browser, on the other hand, is security infrastructure above all else.
For this reason, it is recommended the Tor Browser do away with expiration checks altogether (see patch below). This will ensure built-in static pins are always honored and not bypassed.
Tor Browser users who update regularly (a practice that should be encouraged independently of this issue) should never find themselves with stale pinsets anyways.
```
--- a/security/manager/ssl/PublicKeyPinningService.cpp
+++ b/security/manager/ssl/PublicKeyPinningService.cpp
@@ -254,10 +254,6 @@ FindPinningInformation(const char* hostn
}
if (foundEntry && foundEntry->pinset) {
- if (time > TimeFromEpochInSeconds(kPreloadPKPinsExpirationTime /
- PR_USEC_PER_SEC)) {
- return NS_OK;
- }
staticFingerprints = foundEntry;
}
return NS_OK;
```
**D. OTHER**
It is further recommended the Tor Browser team review the Firefox update process to ensure it is consistent with Tor's increased security requirements.
**Trac**:
**Username**: manchahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20111use Unix domain sockets for SOCKS port by default2023-07-03T16:25:44ZMark Smithuse Unix domain sockets for SOCKS port by defaultWe should use Unix domain sockets by default in Tor Browser. The patch for legacy/trac#14272 takes care of doing that for the control port (via the extensions.torlauncher.control_port_use_socket = true default preference). For the SOCKS ...We should use Unix domain sockets by default in Tor Browser. The patch for legacy/trac#14272 takes care of doing that for the control port (via the extensions.torlauncher.control_port_use_socket = true default preference). For the SOCKS port we need additional changes in tor-browser and builders/tor-browser-bundle at least.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20083`app.update.enabled` should remove updater UI elements when set to false.2022-01-11T19:32:14ZYawning Angel`app.update.enabled` should remove updater UI elements when set to false.I have a use case that requires setting `app.update.enabled` to false.
This mostly works as I expect, however the UI element for forcing a manual update check in the `Help->About Tor Browser` dialog still remains visible and functional....I have a use case that requires setting `app.update.enabled` to false.
This mostly works as I expect, however the UI element for forcing a manual update check in the `Help->About Tor Browser` dialog still remains visible and functional. If the updater is disabled, the UI elements associated with it should be hidden.
On a side note, it would be nice if the built in updater could be force disabled at launch time via an env var as well, for those most special of snowflakes.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19907NoScript could not be verified and gets disabled after restart2022-01-11T19:32:13ZGeorg KoppenNoScript could not be verified and gets disabled after restartWe have at least two bug reports about NoScript getting disabled (presumably after an extension update happened) because it could not get verified. It might be related to legacy/trac#19491 but that is not known.We have at least two bug reports about NoScript getting disabled (presumably after an extension update happened) because it could not get verified. It might be related to legacy/trac#19491 but that is not known.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19851Hardened tor browser 6.5a2 fails to launch with AddressSanitizer CHECK failed2022-01-11T19:32:13ZTracHardened tor browser 6.5a2 fails to launch with AddressSanitizer CHECK failedSimilar to https://trac.torproject.org/projects/tor/ticket/19040
Starting with --verbose flag outputs
Launching './Browser/start-tor-browser --detach --verbose'...
==19866==AddressSanitizer CHECK failed: ../../.././libsanitizer/asan/a...Similar to https://trac.torproject.org/projects/tor/ticket/19040
Starting with --verbose flag outputs
Launching './Browser/start-tor-browser --detach --verbose'...
==19866==AddressSanitizer CHECK failed: ../../.././libsanitizer/asan/asan_rtl.cc:556 "((!asan_init_is_running && "ASan init calls itself!")) != (0)" (0x0, 0x0)
<empty stack>
I presume like the other bug tracker this is due to the recent update to glibc 2.24, though I can't find any information on how to rectify it.
OS: Arch Linux 4.6.4-1-ARCH
glibc: 2.24-1
**Trac**:
**Username**: NextHendrixhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850Disable Plaintext HTTP Clearnet Connections2023-10-04T03:24:25ZTracDisable Plaintext HTTP Clearnet ConnectionsI think that the Tor Browser Bundle should aim to disable allowing connections to plaintext HTTP websites out the box by the end of the year 2016.
Content injection into MITM'd clearnet HTTP connections is the number one security threat...I think that the Tor Browser Bundle should aim to disable allowing connections to plaintext HTTP websites out the box by the end of the year 2016.
Content injection into MITM'd clearnet HTTP connections is the number one security threat to Tor users. It's incredibly easy to do and I'm certain that it happens all the time. (You can reproduce this easily by going to http://example.com in the latest TBB. https://example.com is completely valid, but the connection to the plaintext version is made).
Even without direct content injection, it's the obvious weak point in the overall privacy that Tor provides for a common TBB user.
It's 2016 - the vast majority of websites now serve pages over SSL. Thanks to projects like Let's Encrypt, it's now completely easy and free to run SSL out of the box with any important web server software package - there's really no excuse not to be running HTTPS.
Rather than making this change immediately, we could announce the intention to release the change by the end of the year, thereby giving any stragglers time to add SSL to their websites. We could look at how browsers like Chrome and Firefox degrade deprecated TLS ciphers in successive releases as an example - first a visual indication, then a confirmation warning, then a total block.
What do you think?
**Trac**:
**Username**: miserlou2Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19733GETINFO response parser doesn't handle AF_UNIX entries.2022-01-11T19:32:13ZYawning AngelGETINFO response parser doesn't handle AF_UNIX entries.torbutton issues a `GETINFO` command to validate the configured socks port, but the response parser doesn't handle `AF_UNIX` entries.
```
[07-21 19:17:44] Torbutton WARN: unexpected tor response: net/listeners/socks="127.0.0.1:9050" "un...torbutton issues a `GETINFO` command to validate the configured socks port, but the response parser doesn't handle `AF_UNIX` entries.
```
[07-21 19:17:44] Torbutton WARN: unexpected tor response: net/listeners/socks="127.0.0.1:9050" "unix:/var/run/tor/socks"
```
This currently doesn't matter because the number of people using an `AF_UNIX` capable Tor Browser is ~1, but it is something to note for the future sandboxing efforts.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19722Compile tor with selfrando2022-01-11T19:32:38ZGeorg KoppenCompile tor with selfrandoSelfrando is no browser/Firefox specific technique. We should make sure tor benefits from it as well.Selfrando is no browser/Firefox specific technique. We should make sure tor benefits from it as well.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19280Replace or fork NoScript in the Tor Browser2022-06-18T01:51:49ZTracReplace or fork NoScript in the Tor BrowserI think NoScript is not a fitting addition to the Tor Browser, especially as it is gets known for shady practice and the way it is used (basically disabled) it won't help that much anyway.
See following:
https://liltinkerer.surge.sh/nos...I think NoScript is not a fitting addition to the Tor Browser, especially as it is gets known for shady practice and the way it is used (basically disabled) it won't help that much anyway.
See following:
https://liltinkerer.surge.sh/noscript.html (recent)
https://adblockplus.org/blog/attention-noscript-users
Is there any guarantee that it won't inject malicious ads in the Tor browsing experience? Does the Tor browser have its own fork maybe?
**Trac**:
**Username**: herbsthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19164Backport - Remove support for SHA-1 HPKP pins2022-01-11T19:32:38ZbugzillaBackport - Remove support for SHA-1 HPKP pinshttps://bugzilla.mozilla.org/show_bug.cgi?id=1233328https://bugzilla.mozilla.org/show_bug.cgi?id=1233328https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18406Update Tor Browser release documentation to check for properly signed MAR files2022-01-11T19:32:38ZGeorg KoppenUpdate Tor Browser release documentation to check for properly signed MAR filesWe should update our release documentation to make sure our MAR files are signed properly before generating the update response files.We should update our release documentation to make sure our MAR files are signed properly before generating the update response files.Georg KoppenGeorg Koppen