Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:48:43Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32629Re-enable 1 or 2 more macOS jobs in Travis2020-06-13T15:48:43ZteorRe-enable 1 or 2 more macOS jobs in TravisReverts #32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Reverts #32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32500consider clang -std=gnu99 in Travis for better C99 portability2020-06-13T15:48:15ZTaylor Yuconsider clang -std=gnu99 in Travis for better C99 portabilityIn #32495, we discovered that `-Wtypedef-redefinition` doesn't seem to work on clang unless `-std=gnu99` or similar is used. (typedef redefinitions are apparently allowed in C11) It does seem to work on FreeBSD's cc for some reason, but ...In #32495, we discovered that `-Wtypedef-redefinition` doesn't seem to work on clang unless `-std=gnu99` or similar is used. (typedef redefinitions are apparently allowed in C11) It does seem to work on FreeBSD's cc for some reason, but we don't use FreeBSD in Travis.
We should consider using something like `-std=gnu99` in our Travis configuration for clang, so we can catch additional instances of this sort of portability problem earlier.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32260Backport "Travis: Use Ubuntu Bionic, but keep Trusty for chutney"2020-06-13T15:47:26ZteorBackport "Travis: Use Ubuntu Bionic, but keep Trusty for chutney"We should keep the build images consistent across releases.We should keep the build images consistent across releases.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32241Travis: Use a newer macOS image2020-06-13T15:47:22ZteorTravis: Use a newer macOS imageI tried some newer images, here's what I found:
Xcode 10.1:
* https://github.com/teor2345/tor/tree/macos_image_10_1
* build took longer than 50 minutes
Xcode 10.3:
* https://github.com/teor2345/tor/tree/macos_image_10_3
* build took 19...I tried some newer images, here's what I found:
Xcode 10.1:
* https://github.com/teor2345/tor/tree/macos_image_10_1
* build took longer than 50 minutes
Xcode 10.3:
* https://github.com/teor2345/tor/tree/macos_image_10_3
* build took 19 minutes, vs 9 minutes for the current image
Xcode 11.2:
* https://github.com/teor2345/tor/tree/macos_image_11_2
* build took 12 minutes, vs 9 minutes for the current image
Let's revisit in a few months.
We could try older images, and see if they are faster. But I don't think macOS is limiting our builds right now.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32240Tor Travis: Make chutney work on Xenial and Bionic images2020-06-13T15:47:22ZteorTor Travis: Make chutney work on Xenial and Bionic imagesWe get weird permissions errors like this:
```
FAIL: basic-min
Detail: chutney/tools/warnings.sh /home/travis/build/teor2345/tor/chutney/net/nodes.1571845015
Warning: Can't create/check datadirectory /home/travis/build/teor2345/tor/chutn...We get weird permissions errors like this:
```
FAIL: basic-min
Detail: chutney/tools/warnings.sh /home/travis/build/teor2345/tor/chutney/net/nodes.1571845015
Warning: Can't create/check datadirectory /home/travis/build/teor2345/tor/chutney/net/nodes/002r Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/000a/key-pinning-journal" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/001a/key-pinning-journal" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-certs": Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-consensus" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-descriptors" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-extrainfo" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-microdesc-consensus" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-microdescs" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-microdescs.new": Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/unverified-consensus" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/unverified-microdesc-consensus" for mmap(): Permission denied Number: 1
Warning: Directory /home/travis/build/teor2345/tor/chutney/net/nodes/002r cannot be read: Permission denied Number: 1
Warning: Error initializing keys; exiting Number: 1
Warning: Error loading key-pinning journal: Permission denied Number: 2
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31673Deprecated use of <sys/sysctl.h>2020-06-13T15:45:23ZDavid Gouletdgoulet@torproject.orgDeprecated use of <sys/sysctl.h>I've been getting warnings since couple days ago:
```
/usr/include/x86_64-linux-gnu/sys/sysctl.h:21:2: warning: #warning "The <sys/sysctl.h> header is deprecated and will be removed." [-Wcpp]
21 | #warning "The <sys/sysctl.h> header ...I've been getting warnings since couple days ago:
```
/usr/include/x86_64-linux-gnu/sys/sysctl.h:21:2: warning: #warning "The <sys/sysctl.h> header is deprecated and will be removed." [-Wcpp]
21 | #warning "The <sys/sysctl.h> header is deprecated and will be removed."
```
It is annoying with `enable-gcc-warnings` since it errors.
I've removed that include and tor builds fine so, as nickm suggested on IRC, right solution here is to not include on Linux/Win32 instead of `#ifdef HAVE_SYS_SYSCTL_H`.
I would recommend a backport since if this becomes a problem to build tor in the future.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31406new ip-address for tor.dizum.com (auth-dir)2020-06-13T15:44:16ZAlex de Joodenew ip-address for tor.dizum.com (auth-dir)```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Guys,
tor.dizum.com has changed it's IP address. As tor.dizum.com is a directory server, it's ip address is hardcoded in the source code.
Please update the ip.
OLD: 194.109.206.212...```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Guys,
tor.dizum.com has changed it's IP address. As tor.dizum.com is a directory server, it's ip address is hardcoded in the source code.
Please update the ip.
OLD: 194.109.206.212
NEW: 45.66.33.45
You can verify and validate this change by either
1) retrieving the ip for tor.dizum.com.
2) contact alex, by email or by phone or on irc to verify this change.
3) you could read the announcement at the dir-auth list.
-----BEGIN PGP SIGNATURE-----
Version: BCPG v1.47
iGYEARECACYFAl1RuckfHEFsZXggZGUgSm9vZGUgPGFsZXhAaWRnYXJhLm5sPgAK
CRB4AD5zEX0r0DQsAJwN+/zRHTRgIiiXps8Lw0NieQgFpACgoz/YHdlt/X2YMQQL
bpY/OwGavRE=
=SFAn
-----END PGP SIGNATURE-----
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31374Appveyor: cast between incompatible function types in compat_time2020-06-13T15:44:11ZteorAppveyor: cast between incompatible function types in compat_timeThe latest Appveyor compiler complains:
{{{
../src/lib/time/compat_time.c:522:25: error: cast between incompatible function types from 'FARPROC' to 'ULONGLONG (__attribute__((stdcall)) *)(void)' [-Werror=cast-function-type]
522 | ...The latest Appveyor compiler complains:
{{{
../src/lib/time/compat_time.c:522:25: error: cast between incompatible function types from 'FARPROC' to 'ULONGLONG (__attribute__((stdcall)) *)(void)' [-Werror=cast-function-type]
522 | GetTickCount64_fn = (GetTickCount64_fn_t)
| ^
}}}
This issue is like #27465:
GetProcAddress() returns FARPROC, which is (long long int(*)()) on
64-bit Windows:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx
But GetTickCount64() is (long long unsigned int(*)()), on both 32-bit
and 64-bit Windows:
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount64
So gcc 8 issues a spurious "incompatible function pointer" warning
about the cast to GetTickCount64_fn_t.
Silence this warning by casting to a void function pointer, before
the cast to GetTickCount64_fn_t.
Fixes bug NNNNN; bugfix on 0.2.9.1-alpha.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31372Appveyor and Travis should use "make -k"2020-06-13T15:44:10ZNick MathewsonAppveyor and Travis should use "make -k"Right now our .appveyor.yml and .travis.yml are not using the "-k" make flag. That means that once it encounters an error, it stops building. In general, we would prefer our CI to keep trying to build for a long as it can, so that we c...Right now our .appveyor.yml and .travis.yml are not using the "-k" make flag. That means that once it encounters an error, it stops building. In general, we would prefer our CI to keep trying to build for a long as it can, so that we can see all of the warnings and errors that are produced. This will help us save round trips between the developer and the CI process.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31343appveyor: labs(time_t) is not allowed2020-06-13T15:44:03ZNick Mathewsonappveyor: labs(time_t) is not allowedMike points out that appveyor is failing with
```
../src/core/or/channeltls.c:1768:7: error: absolute value function 'labs' given an argument of type 'time_t' {aka 'long long int'} but has parameter of type 'long int' which may cause tr...Mike points out that appveyor is failing with
```
../src/core/or/channeltls.c:1768:7: error: absolute value function 'labs' given an argument of type 'time_t' {aka 'long long int'} but has parameter of type 'long int' which may cause truncation of value [-Werror=absolute-value]
1768 | if (labs(now - chan->conn->handshake_state->sent_versions_at) < 180) {
| ^~~~
```
That code has been there for ages, though. Looks like this is a new compiler warning rather than a new bug. It is a c issue, though, anywhere that time_t is bigger than long.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31107channel: channel_tls_handle_cell() CELL_VERSIONS code reached2020-06-13T15:43:29ZDavid Gouletdgoulet@torproject.orgchannel: channel_tls_handle_cell() CELL_VERSIONS code reachedRelay operator reported this 2 days ago:
https://lists.torproject.org/pipermail/tor-relays/2019-July/017486.html
This code has been reached in `channel_tls_handle_cell()`:
```
case CELL_VERSIONS:
tor_fragile_assert();
...Relay operator reported this 2 days ago:
https://lists.torproject.org/pipermail/tor-relays/2019-July/017486.html
This code has been reached in `channel_tls_handle_cell()`:
```
case CELL_VERSIONS:
tor_fragile_assert();
break;
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31089Consider using data-URI to embed how_tor_works_thumb.png image into tor-exit-...2020-06-13T15:43:25Zrl1987Consider using data-URI to embed how_tor_works_thumb.png image into tor-exit-notice.htmlWe can only serve a single HTML file with `DirPortFrontPage` configuration option. Currently we provide an exit notice file in tor-exit-notice.html, which embeds an image with basic Tor network schematics from Tor website. We may want to...We can only serve a single HTML file with `DirPortFrontPage` configuration option. Currently we provide an exit notice file in tor-exit-notice.html, which embeds an image with basic Tor network schematics from Tor website. We may want to use data-URI format (as described in RFC 2397) to hardcode this image into HTML and avoid loading it from external webserver.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31001Undefined behavior in tor_vasprintf()2020-06-13T15:43:04ZGeorge KadianakisUndefined behavior in tor_vasprintf()```
Overflowing a signed integer in C is an undefined behaviour.
It is possible to trigger this undefined behaviour in tor_asprintf on
Windows or systems lacking vasprintf.
On these systems, eiter _vscprintf or vsnprintf is called to re...```
Overflowing a signed integer in C is an undefined behaviour.
It is possible to trigger this undefined behaviour in tor_asprintf on
Windows or systems lacking vasprintf.
On these systems, eiter _vscprintf or vsnprintf is called to retrieve
the required amount of bytes to hold the string. These functions can
return INT_MAX. The easiest way to recreate this is the use of a
specially crafted configuration file, e.g. containing the line:
FirewallPorts AAAAA<in total 2147483610 As>
This line triggers the needed tor_asprintf call which eventually
leads to an INT_MAX return value from _vscprintf or vsnprintf.
The needed byte for \0 is added to the result, triggering the
overflow and therefore the undefined behaviour.
Casting the value to size_t before addition fixes the behaviour.
```Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30860Add a chutney job that runs on macOS, so that IPv6 chutney tests work2020-06-13T15:46:04ZteorAdd a chutney job that runs on macOS, so that IPv6 chutney tests workTravis Linux doesn't support IPv6, so we should add a macOS chutney job to Tor's CI.
If that's too slow, we can:
* add the chutney tests to the end of an existing macOS job
* change the chutney job to macOS
Remember: each build has a l...Travis Linux doesn't support IPv6, so we should add a macOS chutney job to Tor's CI.
If that's too slow, we can:
* add the chutney tests to the end of an existing macOS job
* change the chutney job to macOS
Remember: each build has a limit of 2 concurrent macOS jobs.
We can do this task after #29280 merges.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30781Stop crashing when encountering an unknown router annotation2020-06-13T15:42:13ZteorStop crashing when encountering an unknown router annotationI think this bug can only be triggered by modifying a local file.
This bug was introduced in commit b5c8a8ae53 in 0.2.0.8-alpha.I think this bug can only be triggered by modifying a local file.
This bug was introduced in commit b5c8a8ae53 in 0.2.0.8-alpha.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30561Fixed tor_vasprintf on systems without vasprintf.2020-06-13T15:41:37ZTracFixed tor_vasprintf on systems without vasprintf.If tor is compiled on a system with neither vasprintf nor _vscprintf,
the fallback implementation exposes a logic flaw which prevents
proper usage of strings longer than 127 characters:
* tor_vsnprintf returns -1 if supplied buffer is n...If tor is compiled on a system with neither vasprintf nor _vscprintf,
the fallback implementation exposes a logic flaw which prevents
proper usage of strings longer than 127 characters:
* tor_vsnprintf returns -1 if supplied buffer is not large enough,
but tor_vasprintf uses this function to retrieve required length
* the result of tor_vsnprintf is not properly checked for negative
return values
Both aspects together could in theory lead to exposure of uninitialized
stack memory in the resulting string. This requires an invalid format
string or data that exceeds integer limitations.
Fortunately tor is not even able to run with this implementation because
it runs into asserts early on during startup. Also the unit tests fail
during a "make check" run.
At this point it would make sense to check if support for these systems is still a desired option. It seems that nobody noticed lack of support for at least a year.
**Trac**:
**Username**: paldiumTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30522Update to May GeoIP2 database2020-06-13T15:41:33ZKarsten LoesingUpdate to May GeoIP2 database[My geoip-2019-05-13 branch](https://gitweb.torproject.org/user/karsten/tor.git/log/?h=geoip-2019-05-13) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other b...[My geoip-2019-05-13 branch](https://gitweb.torproject.org/user/karsten/tor.git/log/?h=geoip-2019-05-13) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branches that are still maintained.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30213Remove sudo: false from Travis2020-06-13T15:40:50ZteorRemove sudo: false from TravisTravis has made all of its builders sudo: true, so we can remove the sudo block, and the exclude: sudo blocks.Travis has made all of its builders sudo: true, so we can remove the sudo block, and the exclude: sudo blocks.Tor: 0.2.9.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/30184release-0.2.9 doesn't compile on old rhel2020-06-13T16:15:53ZRoger Dingledinerelease-0.2.9 doesn't compile on old rhelOn rhel6, building release-0.2.9 (git commit ca008906), I get
```
CC src/or/src_or_libtor_testing_a-rephist.o
src/or/rephist.c:91: error: redefinition of typedef ‘bw_array_t’
src/or/rephist.h:120: note: previous declaration of ‘bw_...On rhel6, building release-0.2.9 (git commit ca008906), I get
```
CC src/or/src_or_libtor_testing_a-rephist.o
src/or/rephist.c:91: error: redefinition of typedef ‘bw_array_t’
src/or/rephist.h:120: note: previous declaration of ‘bw_array_t’ was here
make[1]: *** [src/or/src_or_libtor_testing_a-rephist.o] Error 1
```
Looks like when we backported some stuff, we didn't backport all of the subsequent fixes on the stuff.
Here is a fix that lets it compile again (there could for sure be a better fix than this):
```
index dc86fad..d8f7eb2 100644
--- a/src/or/rephist.c
+++ b/src/or/rephist.c
@@ -88,7 +88,6 @@
static void bw_arrays_init(void);
static void predicted_ports_init(void);
-typedef struct bw_array_t bw_array_t;
STATIC uint64_t find_largest_max(bw_array_t *b);
STATIC void commit_max(bw_array_t *b);
STATIC void advance_obs(bw_array_t *b);
diff --git a/src/or/rephist.h b/src/or/rephist.h
index c464b34..072987f 100644
--- a/src/or/rephist.h
+++ b/src/or/rephist.h
@@ -114,10 +114,10 @@ void rep_hist_log_link_protocol_counts(void);
extern uint64_t rephist_total_alloc;
extern uint32_t rephist_total_num;
+typedef struct bw_array_t bw_array_t;
#ifdef TOR_UNIT_TESTS
extern int onion_handshakes_requested[MAX_ONION_HANDSHAKE_TYPE+1];
extern int onion_handshakes_assigned[MAX_ONION_HANDSHAKE_TYPE+1];
-typedef struct bw_array_t bw_array_t;
extern bw_array_t *write_array;
#endif
```
(My bwauth still runs on 0.2.9, since I'm under the impression that's the last version that works well with bwauths. That's how I noticed.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30041OOB access with huge buffers (src/lib/buf/buffers.c)2020-06-13T15:40:19ZGeorge KadianakisOOB access with huge buffers (src/lib/buf/buffers.c)Here is an out-of-bounds read bug found by paldium in hackerone. It's a low-severity bug because it can only be used for DoS, and requires transfer of more than INT_MAX bytes through a connection.
We should backport to 029 and forward a...Here is an out-of-bounds read bug found by paldium in hackerone. It's a low-severity bug because it can only be used for DoS, and requires transfer of more than INT_MAX bytes through a connection.
We should backport to 029 and forward anyhow.
```
# Summary
It is possible to trigger out of boundary accesses with buffers if their content exceeds INT_MAX bytes. See my first patch (0001) how to trigger the issue through unit tests, as this is the easiest way to see what happens. It will result in an out of boundary read. A 64 bit system with at least 5 GB is required for this unit test though!
# Explanation
A buffer consists of one or multiple chunks, which actually contain the data. A chunk contains a memory region and a data pointer. The data pointer points somewhere into the memory, where the actual user data is stored.
Even though a chunk is free to be larger than INT_MAX, it cannot be advised to use such chunks. Whenever a function performs searches or lookups, it is bound to "int" due to buf_pos_t. Many functions properly check that INT_MAX is not exceeded and throw assertions, but unfortunately not all...
Keeping that in mind, I was able to perform a sequence of actions that in fact create chunks with a data length greater than INT_MAX. The int variable "pos" will eventually overflow and access memory far ahead from reserved user data, effectively performing an out of boundary access.
# Exploitation
Generally this is a defensive coding measure to make sure that buffers are safe.
It should be possible to trigger a huge buffer in src/core/mainloop/connection.c. In function connection_buf_read_from_socket a linked connection (directory authentication, as far as I can tell) is joined into the connection buffer with buf_move_to_buf.
The return value of buf_move_to_buf is not properly checked, which means that excessively large data returned from the linked connection can slowly increase the value of "max_to_read" which means that more and more data can be stored in the connection.
Should it eventually overflow INT_MAX (granted, this takes a LOOONG time), the integer calculation will corrupt the buffer, leading to out of boundary operations.
# Patch
To prevent this issue, both patches (0002 to fix buffers and 0003 to check for error return value) must be applied.
## Impact
Heap data is corrupted and out of boundary read access occur. It will be very hard to extract data with that, because it would be a blind memory check -- and will most likely directly cause a segmentation fault.
Most likely attack vector is therefore denial of service.
```Tor: 0.2.9.x-final