The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:54:51Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24407No warning when IPv6 port is not reachable2020-06-27T13:54:51ZTracNo warning when IPv6 port is not reachableCase:
Running relay on IPv4. All checks ok, running good.
Stop relay, add ORPort for IPv6.
Restart. Checks look ok, circuits are built up.
After a while, no new users are added, but circuits disappear and relay is reported as off line i...Case:
Running relay on IPv4. All checks ok, running good.
Stop relay, add ORPort for IPv6.
Restart. Checks look ok, circuits are built up.
After a while, no new users are added, but circuits disappear and relay is reported as off line in atlas. This lasted for over a day.
Reason: IPv6 port was blocked by firewall. This was not reported in the error logs (but was tested, hence the relay being reported offline).
Unblock IPv6 port places the relay 'online' again, and all works well.
Request: report on IPv6 port not reachable. This would have saved quite some time and searching.
Question/discussion: should a relay go offline when IPv4 works, but only IPv6 has problems? And what happens if IPv4 is taken off completely?
**Trac**:
**Username**: MikeEUhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24406Implement IPv6 ORPort reachability fallback2020-07-28T16:03:17ZteorImplement IPv6 ORPort reachability fallbackImplement the IPv6 ORPort reachability fallback from legacy/trac#24404.Implement the IPv6 ORPort reachability fallback from legacy/trac#24404.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24405Implement relay IPv6 extends with proposed protover2020-07-28T16:02:57ZteorImplement relay IPv6 extends with proposed protoverMake relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)
Make these relays declare t...Make relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)
Make these relays declare the protover from legacy/trac#24404.
Make them implement the IPv4/IPv6 Extend behviour from legacy/trac#24404.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24404Propose a relay protover that allows IPv6 extends2020-06-27T13:54:52ZteorPropose a relay protover that allows IPv6 extendsWrite a proposal for a relay protover, in which relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may ...Write a proposal for a relay protover, in which relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.)Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24403Propose and implement IPv6 ORPort reachability checks on relays2020-06-27T13:54:52ZteorPropose and implement IPv6 ORPort reachability checks on relaysThis is the top-level task for relay IPv6 ORPort reachability checks.
See:
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features#ReachabilityChecks
Check the child tickets for details.This is the top-level task for relay IPv6 ORPort reachability checks.
See:
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features#ReachabilityChecks
Check the child tickets for details.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/24402Make numbers in Guard and Exit column clickable (aggregated view)2020-06-27T14:25:03ZcypherpunksMake numbers in Guard and Exit column clickable (aggregated view)Make numbers in Guard and Exit column clickable to show the respective relays.
this adds flag:exit or flag:guard to the search termMake numbers in Guard and Exit column clickable to show the respective relays.
this adds flag:exit or flag:guard to the search termirlirlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24400Seccomp filter incorrectly tries to act on strings, allowing sandbox bypass2020-07-28T16:02:35ZSebastian HahnSeccomp filter incorrectly tries to act on strings, allowing sandbox bypassI am filing this on behalf of cypherpunks who cannot use our trac because of its javascript requirements for posting some stuff.
Currently, the Tor seccomp sandbox attempts to whitelist internal strings. This is a bug, because seccomp i...I am filing this on behalf of cypherpunks who cannot use our trac because of its javascript requirements for posting some stuff.
Currently, the Tor seccomp sandbox attempts to whitelist internal strings. This is a bug, because seccomp is incapable of whitelisting memory contents, only register contents (i.e. the pointer itself). That is, when you call `open(path, mode)`, the first argument is actually an address, such as `0x368a227dec3`. When you attempt to use the seccomp filter to whitelist this, you are not whitelisting the string, only the pointer to the string. The only reason it works is because compilers deduplicate identical strings, allowing two strings that are the same (e.g. the string given to seccomp for whitelisting, and the string being given to a syscall) point to the same location in `.rodata`.
**A demonstration showing deduplication:**
```
cat $ hello.c
#include <stdio.h>
void main(int argc, char *argv[])
{
char *s1 = "Hello, world!";
char *s2 = "Hello, world!";
char *s3 = argv[1];
printf("%p\t%s\n%p\t%s\n%p\t%s\n", s1, s1, s2, s2, s3, s3);
}
$ gcc hello.c
$ ./a.out "Hello, world!"
0x64a4b457b4 Hello, world!
0x64a4b457b4 Hello, world!
0x3eb7d22b37d Hello, world!
$ readelf -x .rodata a.out
Hex dump of section '.rodata':
0x000007b0 01000200 48656c6c 6f2c2077 6f726c64 ....Hello, world
0x000007c0 21002570 0925730a 25700925 730a2570 !.%p.%s.%p.%s.%p
0x000007d0 0925730a 00 .%s..
```
Despite the strings being identical in all cases, only the first two, which were defined internally, point to the same data. Only when the string is accessed at runtime does the value change. This means that hardcoding a string with a seccomp sandbox may seem to work, but provides no protection, as all an attacker would have to do is write their own strings to those addresses (changing the permissions of `.rodata` first if it is stored there).
**A demonstration which shows how a whitelisted string can be bypassed:**
```
$ cat seccomp.c
#include <seccomp.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
void main(void)
{
char *s = malloc(14);
memcpy(s, "Hello, world!\n", 14);
scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_TRAP);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
SCMP_A1(SCMP_CMP_EQ, (scmp_datum_t)s));
seccomp_load(ctx);
write(1, s, 14);
memcpy(s, "Hallo, world!\n", 14);
write(1, s, 14);
}
$ gcc seccomp.c -lseccomp
$ ./a.out
Hello, world!
Hallo, world!
```
See "Why does seccomp-filter is not enough?" [sic] from https://lwn.net/Articles/698226/, which explains why an LSM (currently in development) is required to provide seccomp with the ability to filter paths and other memory-resident values:
>A seccomp filter can access to raw syscall arguments which means that it is not
>possible to filter according to pointed data as a file path. As demonstrated
>the first version of this patch series, filtering at the syscall level is
>complicated (e.g. need to take care of race conditions). This is mainly because
>the access control checkpoints of the kernel are not at this high-level but
>more underneath, at LSM hooks level. The LSM hooks are designed to handle this
>kind of checks. This series use this approach to leverage the ability of
>unprivileged users to limit themselves.
It may seem like it would be enough to ensure the buffers are read-only and disallow `mprotect()` accessing that address. Unfortunately, other syscalls like `brk()` can bypass this. In the end, it's extremely difficult to ensure that a memory region cannot be written to by malicious code without disabling virtually all memory-related syscalls.
The entirety of `src/common/sandbox.c:sandbox_intern_string` is poorly thought out and relies on incorrect and dangerous assumptions. This results in 6 syscalls so far which devs believe to be filtered but which in fact can be bypassed:
* chown - pathname argument
* chmod - pathname argument
* open - pathname argument
* openat - pathname argument
* rename - oldpath and newpath arguments
* stat64 - pathname argument
The solution is to use the syscalls before enabling the sandbox, or whitelisting them (excluding arguments in memory) and eventually blacklisting them in a stage 2 sandbox.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/24398Plugin-container exhausts memory leading to thrash and/or crash on Linux2020-06-27T14:36:38ZGeorg KoppenPlugin-container exhausts memory leading to thrash and/or crash on LinuxWe got a nice bugreport from a cypherpunk on our tbb-dev mailing list (https://lists.torproject.org/pipermail/tbb-dev/2017-November/000673.html) with a patch up for review (which I'll attach in a minute) (the problem seems to be caused b...We got a nice bugreport from a cypherpunk on our tbb-dev mailing list (https://lists.torproject.org/pipermail/tbb-dev/2017-November/000673.html) with a patch up for review (which I'll attach in a minute) (the problem seems to be caused by our workaround for legacy/trac#24052):
```
STR
---
1. Run one of the platforms affected by the recent "tormoil" vulnerability (I
tested this on a GNU/Linux distro).
2. Under Tor Browser 7.0.10's installation directory, create
`Browser/TorBrowser/Data/Browser/profile.default/chrome/userContent.css`
with the following content (you can use whatever you want here, just adjust
the next steps accordingly):
body {
background-color: blue !important;
color: white !important;
}
3. Start Tor Browser.
4. Confirm that the content background looks blue.
5. Right click the blue background on an empty spot (body element) and choose
"Inspect Element".
6. Wait until the Inspector window shows up. Observe memory consumption of
process "plugin-container" continually rise.
Analysis
--------
I think this regression is caused by the workaround [0] for the recent critical
vulnerability [1], but it has exposed what looks to me (not being privy to the
details of "tormoil") like another bug, this one in javascript code.
0: https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.0esr-7.0-1&id=643117230bb3402c997f065980db1eec19c7a6ed
1: https://trac.torproject.org/projects/tor/ticket/24052
`newChannelForURL` in DevToolsUtils.js (packed inside
`Browser/browser/omni.ja`) will recursively call itself when
`NetUtil.newChannel` raises an exception, prepending "file://" to the input
URL:
/**
* Opens a channel for given URL. Tries a bit harder than NetUtil.newChannel.
*
* @param {String} url - The URL to open a channel for.
* @param {Object} options - The options object passed to @method fetch.
* @return {nsIChannel} - The newly created channel. Throws on failure.
*/
function newChannelForURL(url, { policy, window, principal }) {
var securityFlags = Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL;
let uri;
try {
uri = Services.io.newURI(url, null, null);
} catch (e) {
// In the xpcshell tests, the script url is the absolute path of the test
// file, which will make a malformed URI error be thrown. Add the file
// scheme to see if it helps.
uri = Services.io.newURI("file://" + url, null, null);
}
[...]
try {
return NetUtil.newChannel(channelOptions);
} catch (e) {
// In xpcshell tests on Windows, nsExternalProtocolHandler::NewChannel()
// can throw NS_ERROR_UNKNOWN_PROTOCOL if the external protocol isn't
// supported by Windows, so we also need to handle the exception here if
// parsing the URL above doesn't throw.
return newChannelForURL("file://" + url, { policy, window, principal });
}
}
With the mentioned patch, the call to `NetUtil.newChannel` raises an
exception. This results in infinite recursion coupled with rapid (though
linear) memory consumption. Thus, `plugin-container` will, in just a few
seconds, exhaust all available memory.
Partial fix
-----------
AFAICT, the current patch for "tormoil" is just a hurried stop-gap workaround
and as such it is acceptable, and somewhat expected, for it to cause other,
less severe, kinds of breakage. However, ISTM that the code in
`newChannelForURL` is buggy regardless: the recursion has no (evident)
termination condition.
The comment before the recursive call says that it is needed due to some tests
for which `newChannel` can raise `NS_ERROR_UNKNOWN_PROTOCOL`. So maybe it
should only catch the exception (and make the recursive call) if the error is
that one and `url` does not already start with "file://". The attached patch
does this. It does not fix the regression (the Developer Toolbox still fails
to show the appropriate styles and stylesheets), but at least fixes the DoS
caused by the runaway memory allocation.
```https://gitlab.torproject.org/tpo/core/tor/-/issues/24397Tor: The second generation onion router – annotated version ...2020-06-27T13:54:52ZcypherpunksTor: The second generation onion router – annotated version ...https://news.ycombinator.com/item?id=11022315https://news.ycombinator.com/item?id=11022315https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/24395Make exit_address IPs RelaySearch URLs2020-06-27T14:25:03ZcypherpunksMake exit_address IPs RelaySearch URLsIt would be very handy if every item in the exit_addresses would be a clickable RelaySearch URL searching the given IPIt would be very handy if every item in the exit_addresses would be a clickable RelaySearch URL searching the given IPirlirlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24394add ipv6 dirauth address2020-06-27T13:54:52ZStefani Banerianadd ipv6 dirauth address
bastet added to dirauth in oct 2017 has ipv6 addr
2620:13:4000:6000::1000:118
per request of dirauth list message
bastet added to dirauth in oct 2017 has ipv6 addr
2620:13:4000:6000::1000:118
per request of dirauth list messageTor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24393Clients should check IPv4 and IPv6 subnets when choosing circuit paths2021-08-23T15:17:07ZteorClients should check IPv4 and IPv6 subnets when choosing circuit pathsCurrently, clients only check IPv4 subnets when choosing circuit paths. But they should probably also check IPv6 subnets as well.
Once legacy/trac#15518 is fixed, we can make them check both.Currently, clients only check IPv4 subnets when choosing circuit paths. But they should probably also check IPv6 subnets as well.
Once legacy/trac#15518 is fixed, we can make them check both.Tor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24392Ignore cached bridge descriptors until we check if they are running2020-06-27T13:54:52ZteorIgnore cached bridge descriptors until we check if they are runningSplit off legacy/trac#24367:
[An] underlying issue here is that every use of any_bridge_descriptors_known() in tor is wrong. Instead, we want to know if num_bridges_usable() > 0.
This is a bug introduced in commit 93a8ed3 in 0.3.2.1-al...Split off legacy/trac#24367:
[An] underlying issue here is that every use of any_bridge_descriptors_known() in tor is wrong. Instead, we want to know if num_bridges_usable() > 0.
This is a bug introduced in commit 93a8ed3 in 0.3.2.1-alpha by legacy/trac#23347. But it was also a bug in commit eca2a30 in 0.2.0.3-alpha, but we've never encountered it before, because we always retried our bridges immediately (and far too often).
My branch bug24367 at https://github.com/teor2345/tor.git passes all of make test-network, but fails some of the guard and microdesc unit tests. This probably means the unit tests were relying on the buggy behaviour, and need to be changed. I might need nickm or asn to help me fix the unit tests, because they wrote them.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/tpo/web/blog/-/issues/24390Blog issue2020-06-27T14:30:00ZTracBlog issueIt says.
Browser is likely to skip this alpha, and pick up the next one, which should be out in early **November**.
But it is past early November.
[tor-0325-alpha-released](https://blog.torproject.org/tor-0325-alpha-released)
**Trac*...It says.
Browser is likely to skip this alpha, and pick up the next one, which should be out in early **November**.
But it is past early November.
[tor-0325-alpha-released](https://blog.torproject.org/tor-0325-alpha-released)
**Trac**:
**Username**: DbryrtfbcbhgfHiroHirohttps://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/24388Add unreachable or addresses to details view and a synthetic flag2020-06-27T14:25:03ZirlAdd unreachable or addresses to details view and a synthetic flagThis originally came up in legacy/trac#10401 for IPv6, but as it's possible that IPv4 ports may also be unreachable, this should be addressed seperately.This originally came up in legacy/trac#10401 for IPv6, but as it's possible that IPv4 ports may also be unreachable, this should be addressed seperately.irlirlhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/24387Update tor-browser.git/.mozconfig-mac for rbm builds2022-08-03T11:51:42ZboklmUpdate tor-browser.git/.mozconfig-mac for rbm buildsThe osx64 build with rbm is using `tor-browser-build/projects/firefox/mozconfig-osx-x86_64` which is different from `tor-browser.git/.mozconfig-mac`. We should merge those changes to `tor-browser.git/.mozconfig-mac` to be able to use tha...The osx64 build with rbm is using `tor-browser-build/projects/firefox/mozconfig-osx-x86_64` which is different from `tor-browser.git/.mozconfig-mac`. We should merge those changes to `tor-browser.git/.mozconfig-mac` to be able to use that mozconfig file.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/24386Check if projects/firefox/mozconfig-linux-i686 changes are needed2020-06-27T14:36:38ZboklmCheck if projects/firefox/mozconfig-linux-i686 changes are neededThe file `tor-browser-build.git/projects/firefox/mozconfig-linux-x86_64` is identical to `tor-browser.git/.mozconfig`.
The `mozconfig-linux-i686` file however includes the following changes:
```
$ diff projects/firefox/mozconfig-linux-x...The file `tor-browser-build.git/projects/firefox/mozconfig-linux-x86_64` is identical to `tor-browser.git/.mozconfig`.
The `mozconfig-linux-i686` file however includes the following changes:
```
$ diff projects/firefox/mozconfig-linux-x86_64 projects/firefox/mozconfig-linux-i686
7a8,15
> export CFLAGS=-m32
> export CXXFLAGS=-m32
> export LDFLAGS=-m32
> export XLDOPTS=-m32
> export ASFLAGS=-m32
>
> ac_add_options --host=i686-linux-gnu
>
```
We should check whether those changes are necessary, or if they can be moved outside of the mozconfig file so that we can use `tor-browser.git/.mozconfig` for the linux32 builds.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/24385Add Windows 64 mozconfig file to tor-browser.git2022-06-09T13:48:06ZboklmAdd Windows 64 mozconfig file to tor-browser.gitIn `tor-browser-build.git/projects/firefox/mozconfig-windows-x86_64` we have a mozconfig file that is used for the Windows 64 builds. We should add it to `tor-browser.git`, maybe as `.mozconfig-mingw-windows64`, before removing it from `...In `tor-browser-build.git/projects/firefox/mozconfig-windows-x86_64` we have a mozconfig file that is used for the Windows 64 builds. We should add it to `tor-browser.git`, maybe as `.mozconfig-mingw-windows64`, before removing it from `tor-browser-build`.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/24384Decode percent-encoded characters in qualified search terms2021-06-15T10:30:42ZKarsten LoesingDecode percent-encoded characters in qualified search termsFrom legacy/trac#24311: "Second, Oniono does not decode percent-encoded characters in qualified search terms, even though it probably should do that. That means that even if Atlas sent over a query like `https://onionoo.torproject.org/s...From legacy/trac#24311: "Second, Oniono does not decode percent-encoded characters in qualified search terms, even though it probably should do that. That means that even if Atlas sent over a query like `https://onionoo.torproject.org/summary?search=contact:%3Cnone%3E`, Onionoo wouldn't decode it. It would just return an empty result set, because there are no contact lines with `%3Cnone%3E`. That's different from the `contact` parameter which is decoded correctly."Onionoo 2.0.0irlirlhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/24383Window rounding is broken on Debian 9 live with mutter2022-06-23T02:16:48ZGeorg KoppenWindow rounding is broken on Debian 9 live with mutterA report on the blog (https://blog.torproject.org/comment/272689#comment-272689) mentions that the rounding of the browser window is broken with Debian 9 live using mutter. The reported screen dimensions 915x539 using an old Toshiba sate...A report on the blog (https://blog.torproject.org/comment/272689#comment-272689) mentions that the rounding of the browser window is broken with Debian 9 live using mutter. The reported screen dimensions 915x539 using an old Toshiba satellite.