Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:48:25Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32562Allow ONION_CLIENT_AUTH_ADD credentials to be made permanent2020-06-13T15:48:25ZGeorge KadianakisAllow ONION_CLIENT_AUTH_ADD credentials to be made permanentThe Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.The Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31638config: Always check for valid function arguments at the start of each function2020-06-13T15:45:15Zteorconfig: Always check for valid function arguments at the start of each functionSome of the new and refactored config functions check if their arguments are NULL (or otherwise valid). Others don't.
We should consistently check for valid arguments at the start of every function. If there are any unusual validity con...Some of the new and refactored config functions check if their arguments are NULL (or otherwise valid). Others don't.
We should consistently check for valid arguments at the start of every function. If there are any unusual validity conditions, we should explain them in a function comment.
If we skip validation, we should explain why in a comment, where we would usually do validation.
I'm also open to general exceptions. I'm not sure if we have coding standards here. But it would be nice to catch as many future bugs as we can, as early as we can.Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31632hs-v3: Service doesn't re-upload descriptor on circuit failure2020-06-13T15:45:12ZDavid Gouletdgoulet@torproject.orghs-v3: Service doesn't re-upload descriptor on circuit failureI'm observing, quite often actually, a service posting its descriptor to an HSDir but the circuit collapses due to remote reason `CHANNEL_CLOSED`.
This is possible for many reasons where a link between two relays failed/disconnected/clo...I'm observing, quite often actually, a service posting its descriptor to an HSDir but the circuit collapses due to remote reason `CHANNEL_CLOSED`.
This is possible for many reasons where a link between two relays failed/disconnected/closed/...
However, we do not retry the upload after that which means that we can end up with HSDir(s) without our descriptor even though we think they are there.
Solution is unclear but it appears that we probably want to hook this case into `hs_circ_cleanup()` which is called from the mark for close function.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31631Write a test for round-trip encode/decode operations on configuration objects.2020-06-13T15:45:11ZNick MathewsonWrite a test for round-trip encode/decode operations on configuration objects.We should have tests to round-trip through torrc, state, and sr_disk_state objects. We should make sure that encoding a configuration object and then parsing it again gives us the same result.
We might be able to turn this into a fuzze...We should have tests to round-trip through torrc, state, and sr_disk_state objects. We should make sure that encoding a configuration object and then parsing it again gives us the same result.
We might be able to turn this into a fuzzer test.Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31609Make CIRCUIT_IS_ORIGIN() look at the base magic number2020-06-13T15:45:01ZDavid Gouletdgoulet@torproject.orgMake CIRCUIT_IS_ORIGIN() look at the base magic numberCurrently, `CIRCUIT_IS_ORIGIN()` actually looks at the purpose, not the base magic number:
```
#define CIRCUIT_IS_ORIGIN(c) (CIRCUIT_PURPOSE_IS_ORIGIN((c)->purpose))
```
We should move it to look at the `magic` like `CIRCUIT_IS_ORCIRC(...Currently, `CIRCUIT_IS_ORIGIN()` actually looks at the purpose, not the base magic number:
```
#define CIRCUIT_IS_ORIGIN(c) (CIRCUIT_PURPOSE_IS_ORIGIN((c)->purpose))
```
We should move it to look at the `magic` like `CIRCUIT_IS_ORCIRC()` is doing.
The reason is because I was adding tracing events to the circuit subsystem and I kept having state transition event with a circuit global identifier of 0 which can't be because that value is set just after allocation.
But at that point, the purpose has not been set so `CIRCUIT_IS_ORIGIN()` wasn't returning true.
Furthermore, this made me discover another issue documented in #31608 where if we do make this change, we _must_ fix this ticket else we have a NULL deref.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31608circuit_state_publish() never triggers when a new origin circuit is created2020-06-13T15:45:01ZDavid Gouletdgoulet@torproject.orgcircuit_state_publish() never triggers when a new origin circuit is createdIn `origin_circuit_init()`, we change the circuit state before allocating the `build_state` but also before a purpose is set.
This means that `circuit_state_publish()` located in `circuit_set_state()` is never called for a new circuit b...In `origin_circuit_init()`, we change the circuit state before allocating the `build_state` but also before a purpose is set.
This means that `circuit_state_publish()` located in `circuit_set_state()` is never called for a new circuit because `CIRCUIT_IS_ORIGIN()` doesn't return true.
Which in turn, by chance I believe, made this NULL deref on `build_state` to never happen.
This should be fixed regardless.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31544sr: Check why some sr_disk_state fields need to be cleared2020-06-13T15:44:46Zteorsr: Check why some sr_disk_state fields need to be clearedSplit off #31240:
teor: When we add fields, how will we make sure we remember to clear them all?
nickm: We don't need to do so in general, the manager will take care of it for us. This is only necessary for derived fields, and fields f...Split off #31240:
teor: When we add fields, how will we make sure we remember to clear them all?
nickm: We don't need to do so in general, the manager will take care of it for us. This is only necessary for derived fields, and fields for which the unit tests are expecting an unusual behavior, IIRC.
nickm: (I can dig deeper here; I forget the exact reason why this function is clearing these, but I think it is because of legacy cruft.)
teor: Yeah let's double-check what's going on here.
https://github.com/nmathewson/tor/pull/3#discussion_r317548828Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31530Shall we require STMT_BEGIN/STMT_END everywhere?2020-06-13T15:44:42ZNick MathewsonShall we require STMT_BEGIN/STMT_END everywhere?We use STMT_BEGIN/STMT_END in some places, and do...while(0) in others. Let's pick which we prefer, and make it universal.We use STMT_BEGIN/STMT_END in some places, and do...while(0) in others. Let's pick which we prefer, and make it universal.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31516config refactor: every function table entry should be documented and unit tested2020-06-13T15:44:36Zteorconfig refactor: every function table entry should be documented and unit testedWe've added a lot of function tables, but some of their entries are all NULL, everywhere in the code.
So even if it looks like we have 100% coverage, we're not testing these code paths.
Ideally, we should have non-trivial functions, wh...We've added a lot of function tables, but some of their entries are all NULL, everywhere in the code.
So even if it looks like we have 100% coverage, we're not testing these code paths.
Ideally, we should have non-trivial functions, which do the thing that the function table entry is mean to do.
Edited to add:
Also, function table types should be documented with the same level of detail as regular functions. Each argument should have a type, name?, and description.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31511config refactor: split mass change commits into automated and manual steps2020-06-13T15:44:36Zteorconfig refactor: split mass change commits into automated and manual stepsIn future, please split mass change commits into at least two commits:
* automated changes using sed or coccinelle scripts
* manual cleanup changes
This does not block reviews for code that is already in commits or branches. But it shou...In future, please split mass change commits into at least two commits:
* automated changes using sed or coccinelle scripts
* manual cleanup changes
This does not block reviews for code that is already in commits or branches. But it should block reviews for any new commits.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31509config refactor: make test-stem should pass2020-06-13T15:44:35Zteorconfig refactor: make test-stem should passStem should check a lot of useful option combinations.
But the stem CI job is current set to allow_failure, because of #29437.
So we should check that the stem CI job passes, or fails due to a timeout. Or we should run "make test-stem"...Stem should check a lot of useful option combinations.
But the stem CI job is current set to allow_failure, because of #29437.
So we should check that the stem CI job passes, or fails due to a timeout. Or we should run "make test-stem" manually on each PR.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31508config refactor: create simple summaries for each refactor step2020-06-13T15:44:34Zteorconfig refactor: create simple summaries for each refactor stepIt would be helpful to have a quick summary showing the ideal state, and where we are in the refactor.
For example, the #30914 original state was:
* confparse
* typed_var
And the final state was:
* confparse
* struct_var
* type...It would be helpful to have a quick summary showing the ideal state, and where we are in the refactor.
For example, the #30914 original state was:
* confparse
* typed_var
And the final state was:
* confparse
* struct_var
* typed_varTor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31502Revise authority and fallback code so that they use the same "defaults" logic...2020-06-13T15:44:33ZNick MathewsonRevise authority and fallback code so that they use the same "defaults" logic as other codeFor ages we've let "NULL" be the default set of authorities, and then added code to substitute "NULL" with the actual authorities.
Same with fallback directories.
We should fix that so that the real defaults are the "actual" defaults f...For ages we've let "NULL" be the default set of authorities, and then added code to substitute "NULL" with the actual authorities.
Same with fallback directories.
We should fix that so that the real defaults are the "actual" defaults from the POV of what counts as default in the code.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31390--enable-rust with pre-downloaded Rust dependencies fails: no .cargo-checksum...2020-06-13T15:44:14Zyurivict271--enable-rust with pre-downloaded Rust dependencies fails: no .cargo-checksum.json filesIn the FreeBSD port I am downloading the dependencies and supplying
digest-0.7.2 libc-0.2.39 directories as they appear on GitHub pointed by the TOR_RUST_DEPENDENCIES environment variable.
The build fails:
```
error: failed to load sou...In the FreeBSD port I am downloading the dependencies and supplying
digest-0.7.2 libc-0.2.39 directories as they appear on GitHub pointed by the TOR_RUST_DEPENDENCIES environment variable.
The build fails:
```
error: failed to load source for a dependency on `digest`
Caused by:
Unable to update registry `https://github.com/rust-lang/crates.io-index`
Caused by:
failed to update replaced source registry `https://github.com/rust-lang/crates.io-index`
Caused by:
failed to load checksum `.cargo-checksum.json` of libc v0.2.39
Caused by:
failed to read `/usr/ports/security/tor/work/tor-0.4.0.5/rs/libc-0.2.39/.cargo-checksum.json`
```
Is some command supposed to be run that would build .cargo-checksum.json ?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31371hs: Add DoS defense counter to DoS heartbeat message2020-06-13T15:44:09ZDavid Gouletdgoulet@torproject.orghs: Add DoS defense counter to DoS heartbeat messageNow that #15516 is merged, we'll soon enable those defenses and it would be nice to have the counter of how many introduction were rejected due to DoS defenses.Now that #15516 is merged, we'll soon enable those defenses and it would be nice to have the counter of how many introduction were rejected due to DoS defenses.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31188make[1]: don't know how to make ./src/rust/target/release/libtor_rust.a2020-06-13T15:43:41ZTracmake[1]: don't know how to make ./src/rust/target/release/libtor_rust.aHi,
I'm trying to add the option to build tor with Rust to pkgsrc. On NetBSD 9 (8.99.48) amd64, this fails at the moment:
...
CC src/trunnel/libor_trunnel_a-socks5.oCC src/trunnel/libor_trunnel_a-netinfo.oCC src/t...Hi,
I'm trying to add the option to build tor with Rust to pkgsrc. On NetBSD 9 (8.99.48) amd64, this fails at the moment:
...
CC src/trunnel/libor_trunnel_a-socks5.oCC src/trunnel/libor_trunnel_a-netinfo.oCC src/trunnel/libor_trunnel_a-circpad_negotiation.oAR src/trunnel/libor-trunnel.aCC src/lib/trace/trace.oAR src/lib/libtor-trace.a
make[1]: don't know how to make ./src/rust/target/release/libtor_rust.a. Stop
make[1]: stopped in /usr/work/pkgsrc-ng0/tor/work/tor-0.4.0.5
*** Error code 2
Stop.
make: stopped in /usr/work/pkgsrc-ng0/tor/work/tor-0.4.0.5
*** Error code 1
Stop.
make[1]: stopped in /usr/pkgsrc/pkgsrc-ng0/tor
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/pkgsrc-ng0/tor
rust and cargo are available in the build environment, and the crates are made available ahead of time and TOR_RUST_DEPENDENCIES points to the directory they are in.
Questions: to verify if I hit an error on tor's side or Rust specifics wrt NetBSD, and not on my side, do you support verbose builds?
If you have seen this kind of error before in to on other platforms, was there a resolution (I have seen 3 vaguely similar tickets).
Disclaimer: I'm a contributor to pkgsrc, but I'm not the pkgsrc maintainer for tor, so this is more of a personal exploration to see if I can propose it.
Thanks.
**Trac**:
**Username**: ng0Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31183Situational symlink attacks on ControlPortWriteToFile etc.2020-06-13T15:43:41ZGeorge KadianakisSituational symlink attacks on ControlPortWriteToFile etc.Here is a bug report from paldium on hackerone. It's basically a very situational and restricted local priviledge escalation against certain setups and threat models:
```
# Summary
It is possible to change permissions of files through ...Here is a bug report from paldium on hackerone. It's basically a very situational and restricted local priviledge escalation against certain setups and threat models:
```
# Summary
It is possible to change permissions of files through tor or
gain write access to newly created ones. The target file can be
chosen by a local attacker if an adjusted configuration is used.
#How to reproduce
- Given is a FreeBSD or Mac OS X system.
- Tor is configured with a torrc file containing this line:
ControlPortWriteToFile /tmp/control.txt
- Optionally (race condition) this line is included as well:
ControlPortFileGroupReadable 1
- /tmp is a directory with sticky bit, i.e. trwxrwxrwx
##or
- Given is a Unix-like (Linux) system.
- Tor is configured with a torrc file containing this line:
ControlPortWriteToFile /tmp/proof/control.txt
- Optionally (race condition) this line is included as well:
ControlPortFileGroupReadable 1
- /tmp/proof is writable by the local attacker
When tor starts, then it will eventually write all available control
ports into file configured by "ControlPortWriteToFile". This file is not
written directly into, but a temporary file is used (the extension
".tmp" is added to file name). If this file already exists, then it is
simply truncated.
See src/lib/fs/files.c start_writing_to_file for details, especially
line 321 and following.
The problem is that an attacker can simply create the temporary file
before tor gets the chance to. On Mac this attack works by default
against /tmp, but Linux has a protection against symlink attacks on
directories with sticky bit like /tmp or /var/tmp. Therefore it takes an
unusual configuration on Linux or a different (regular) directory.
Let the attacker create a file which tor, even with dropped privileges,
can write to:
`attacker$ install -m 666 /dev/null /tmp/control.txt.tmp`
The tor process will use this file without adjusting the permissions,
because O_CREAT was not actually performed. Instead, O_TRUNC simply
truncated the file to remove existing content.
Afterwards tor will write content to this file, which the attacker could
simply override at this point. But there is no real need to, because
the target file will still keep the permissions of this temporary file
after rename.
See src/lib/fs/files.c replace_file for details. Basically it's a
simple rename() call which therefore removes the target inode and
renames the temporary file to the target one (in this setup).
At this point, the first attack is finished. The file /tmp/control.txt
is under control of the attacker. If "ControlPortFileGroupReadable 1"
is not given, this exploit code works on Linux systems as well (you
can skip the proof/ part on Mac due to lack of /tmp protection):
```In torrc: ControlPortWriteToFile /tmp/proof/control.txt
attacker$ install -Dm 666 /dev/null /tmp/proof/control.txt.tmp
root$ tor -f torrc
attacker$ ls -l /tmp/proof/control.txt
-rw-rw-rw- 1 attacker attacker 0 Jun 24 22:59 /tmp/proof/control.txt```
##Second attack
The second attack uses a race condition. Because /tmp/control.txt is
under control of the attacker, the file can be deleted and replaced with
a symbolic link to a target which we want to get group read permissions
for. This is a possible scenario if "ControlPortFileGroupReadable 1" is
given.
In this case, chmod() is called in tor process. See
src/feature/control/control.c control_ports_write_to_file for more
details, especially line 149 for more details (chmod).
The system call chmod() uses a file path as an argument. There is no
guarantee that the file path still refers to the file which has been
created by the tor process. Furthermore, chmod() follows symbolic
links, therefore the referenced target file is adjusted by chmod.
This is obviously a race condition but can be used to gain read access
to files which -- even by configuration -- should be private to the
tor user.
The attacker still needs group-read permissions, otherwise the newly
revealed files still cannot be accessed.
##Example
`tor just renamed controlled /tmp/control.txt.tmp to /tmp/control.txt`
`attacker$ rm /tmp/control.txt`
`attacker$ ln -s /var/lib/tor /tmp/control.txt`
`tor calls chmod on /tmp/control.txt and therefore on /var/lib/tor`
The attacker, if part of tor's group, can access /var/lib/tor now as well
(only read, but hierarchy is known through other tor installations)
#Solution
Use fchmod() on a file which has been opened with open() and O_NOFOLLOW
to prevent changing any files which have been reached through symbolic
links. Preventing symbolic links is already a great deal in file
src/lib/fs/dir.c check_private_dir, line 85. Could be implemented as
tor_chmod() to fix other chmod() calles in the code as well.
Use mkstemp() to atomically create a temporary file which has the
guaranteed permission 600 and owned by the tor user.
## Impact
A local attacker can modify the content of files which are considered trusted by dependent tools, e.g. the control port file.
Also a local attacker can extend privileges of files which are supposed to be private to the tor user and not readable by the group.
Timeline:
2019-06-25 10:24:59 +0000: @paldium (comment)
To clarify one aspesct about attack 1: Of course it is not a tor issue if someone creates a world writable directory and lets tor create files in there. Everyone could simply override the resulting file and tor will never be able to prevent that. Therefore, the rename()-issue is a non-issue on Linux. But as a user I would expect that temporary files within /tmp with sticky bits are properly handled.
But attack 2 (race condition) should even be prevented in a world writable directory (or writable by a possibly malicious user). Therefore I consider attack 2 on Linux to be unlikely but plausible.
I would like to add a patch to this, but I am not sure how you want to handle file permissions.
The nicest approach would be to supply the permissions to the function which creates the file, but that would be a no-op on Windows.
Otherwise tor_chmod could open() the file and at least prevent symbolic link attacks. Yet, files could still be modified which are not the ones we created.
As this is a design decision, I haven't started writing a patch because I do not know which one you would prefer.
```
Here is some further information:
```
ControlPortWriteFile is one example. The same attack scenarios are true for:
- ExtORPortCookieAuthFileGroupReadable 1
- CookieAuthFileGroupReadable 1
- DataDirectoryGroupReadable 1
- CacheDirectoryGroupReadable 1
- KeyDirectoryGroupReadable 1
```
Here is some of my analysis for attack scenarios:
```
Hello @paldium,
thanks for submitting this report.
Here is the best attacks we could find given the bugs you gave us:
Attack 1) The most realistic attack scenario I could think of is a system where the attacker is a local user who cannot establish outgoing connections, but is able to overwrite the ControlPortWriteToFile file, and replaces it with an attacker controlled IP:PORT, and then a controller program connects to the evil IP:PORT thereby deanonymizing the user. This seems to be a very artificial scenario, which assumes a particular threat model, and a tor with specific configuration parameters, and a very specific system,.
Attack 2) The most realistic attack scenario here would be the attacker using this "read anything controlled by Tor" race condition attack to learn the private keys of an onion service that are on the same system but not able to read them... I'm actually not sure if that would work, but I think it's possible. This also assumes a particular threat-model, a multi-user system, and specific configuration parameters.
@paldium, would it be possible to outline the various solutions we have for fixing this issue?I don't think specifying the permissions in the torrc is a nice thing from a UX perspective. Perhaps not following symlinks is a start but not the whole thing? Maybe we should just abort if there is a dangerous configuration? I wonder how prevalent this is.
```
and here is suggestions on patching:
```
Hi @asn,
I agree here, the attack is impossible against default setups and takes quite specific steps to be exploitable.
To fix this vulnerability at its root, I recommend to adjust the function `start_writing_to_file` in `src/lib/fs/files.c`. The system call `mkstemp` (included in POSIX) guarantees to create a unique file name for the (optional) temporary file. This way, an attacker cannot prepare a file before tor tries to create it. In case of conflict, mkstemp iterates through a huge pool of possible names and if all fail, it returns -1.
It must be checked if mkstemp is a viable option on all target systems, especially Windows. But it's POSIX, so it should work.
The attached patch performs these changes, but breaks a test which would be redundant then (it fails because it tries to create a temporary file beforehand, which `mkstemp` successfully prevents).
###Next improvement to consider (for attack 2):
As far as I understand the code, possible modes for files are:
- 0600 (default)
- 0640 (if configuration requests group-writable files, non-Windows systems only)
- 0400 (tor-gencert, which is not expected to run on Windows according to manual page)
If the special case 0400 is handled in tor-gencert directly, the functions in `src/lib/fs/files.c` can be further reduced in their feature set: Just add a "group readable" attribute to these functions and remove the explicit `mode` (if present):
- start_writing_to_stdio_file
- start_writing_to_file
- write_str_to_file
- write_bytes_to_file
All these functions would use 0600 by default and only support 0640 if the boolean "group readable" flag is set to true -- and that will only happen on non-Windows systems.
With these changes in place, the remaining `chmod` calls (except for the control socket) can be removed and that will also fix the second attack (and gives full atomic control to the newly introduced `fchmod` call):
###Before:
```
if (write_str_to_file(options->ControlPortWriteToFile, joined, 0) < 0) {
log_warn(LD_CONTROL, "Writing %s failed: %s",
options->ControlPortWriteToFile, strerror(errno));
}
#ifndef _WIN32
if (options->ControlPortFileGroupReadable) {
if (chmod(options->ControlPortWriteToFile, 0640)) {
log_warn(LD_FS,"Unable to make %s group-readable.",
options->ControlPortWriteToFile);
}
}
#endif /* !defined(_WIN32) */
```
###After:
```
if (write_str_to_file(options->ControlPortWriteToFile,
options->ControlPortFileGroupReadable, joined, 0) < 0) {
log_warn(LD_CONTROL, "Writing %s failed: %s",
options->ControlPortWriteToFile, strerror(errno));
}
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31178Scripts to help with backport branches2020-06-13T15:43:38ZNick MathewsonScripts to help with backport branchesTeor mentioned wanting to create a helper script for use when backporting branches to older versions of Tor. It would behave like "merge-forward", but instead create a set of candidate branches -- and maybe pull requests for those branc...Teor mentioned wanting to create a helper script for use when backporting branches to older versions of Tor. It would behave like "merge-forward", but instead create a set of candidate branches -- and maybe pull requests for those branches too.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31156Add support of TBytes keyword to torrc for AccountingMax setting (and maybe o...2020-06-13T15:43:35ZTracAdd support of TBytes keyword to torrc for AccountingMax setting (and maybe others)Happening on Debian 9 with Tor 0.2.9.16 from the standard apt repo.
(Sorry, if this is already resolved in newer versions. In that case just close and ignore.)
Syslog output:
```
Jul 14 10:50:38 systemd[1]: Starting Anonymizing overla...Happening on Debian 9 with Tor 0.2.9.16 from the standard apt repo.
(Sorry, if this is already resolved in newer versions. In that case just close and ignore.)
Syslog output:
```
Jul 14 10:50:38 systemd[1]: Starting Anonymizing overlay network for TCP...
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.082 [notice] Tor 0.2.9.16 (git-9ef571339967c1e5) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0k and Zlib 1.2.8.
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.082 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.082 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.082 [notice] Read configuration file "/etc/tor/torrc".
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.085 [warn] Unknown unit 'TBytes'.
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.085 [warn] Failed to parse/validate config: Value 'AccountingMax 5 TBytes' is malformed or out of bounds.
Jul 14 10:50:39 tor[530]: Jul 14 10:50:39.085 [err] Reading config failed--see warnings above.
Jul 14 10:50:39 systemd[1]: tor@default.service: Control process exited, code=exited status=1
Jul 14 10:50:39 systemd[1]: Failed to start Anonymizing overlay network for TCP.
```
Additionally, please note that /var/tor/log didn't give any hint of this, instead it went to syslog. Suboptimal.
**Trac**:
**Username**: tlaTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31149Tor is stuck at "Loading Network Status"2020-06-13T15:43:34ZTracTor is stuck at "Loading Network Status"Tor Version: 8.5.4
Operating System: Windows 7
This is the Log I get after clicking:https://paste2.org/mUggK824
**Trac**:
**Username**: bornadxTor Version: 8.5.4
Operating System: Windows 7
This is the Log I get after clicking:https://paste2.org/mUggK824
**Trac**:
**Username**: bornadxTor: unspecified