This is experimental and probably will break some platforms

We already fixed these in #40099 and #40125.

This patch fixes #40126.  Bugfix on 0.2.8.1-alpha.

The rend_cache/entry_free was missing the rend cache allocation increment
before freeing the object.

Without it, it had an underflow bug:

  Sep 17 08:40:13.845 [warn] rend_cache_decrement_allocation(): Bug: Underflow
  in rend_cache_decrement_allocation (on Tor 0.4.5.0-alpha-dev
  7eef9ced)

Fixes #40125

Signed-off-by: David Goulet <dgoulet@torproject.org>

Nick Mathewson authored 4 years ago and David Goulet committed 4 years ago

Coverity's first complaint was that we didn't check the return
values from chmod.  That's easily fixed.

Coverity's second complaint was that there were code paths where we pass
NULL to chmod.  For example, if this line failed, we'd "goto done",
and then pass NULL to chmod.
  tt_ptr_op(dirname, OP_NE, NULL);

Closes #40103.  Bug not in any released Tor.

"ours" to avoid version bump

"ours" to avoid version bump.

Alexander Hansen Færøy authored 4 years ago and David Goulet committed 4 years ago

This patch disables the glob() support in the path library if glob() is
unavailable at build-time. This currently happens with the Android NDK
used for Tor Browser.

See: https://bugs.torproject.org/tpo/core/tor/40114

tl;dr We were not counting cells flying from the client to the service, but we
were counting cells flying from the service to the client.

When a rendezvous cell arrives from the client to the RP, the RP forwards it to
the service.

For this to happen, the cell first passes through command_process_relay_cell()
which normally does the statistics counting. However because the `rend_circ`
circuit was not flagged with `circuit_carries_hs_traffic_stats` in
rend_mid_rendezvous(), the cell is not counted there.

Then the cell goes to circuit_receive_relay_cell() which has a special code
block based on `rend_splice` specifically for rendezvous cells, and the cell
gets directly passed to `rend_circ` via a direct call to
circuit_receive_relay_cell(). The cell never passes through
command_process_relay_cell() ever again and hence is never counted by our
rephist module.

The fix here is to flag the `rend_circ` circuit with
`circuit_carries_hs_traffic_stats` so that the cell is counted as soon as it
hits command_process_relay_cell().

Furthermore we avoid double-counting cells since the special code block of
circuit_receive_relay_cell() makes us count rendezvous cells only as they enter
the RP and not as they exit it.

Fixes #40117.

David Goulet authored 4 years ago and Alexander Hansen Færøy committed 4 years ago

When accessing the last_resolved_address cache we always need to convert the
AF family value to an index value else we are out of bound and thus
overflowing if we write to it.

This fix is on code that has not been released.

GeKo reported the following libasan crash using Tor Browser alpha with tor
0.4.5.0-alpha-dev (3c884bc9):

==4240==ERROR: AddressSanitizer: global-buffer-overflow on address
0x55888490e388 at pc 0x5588842cc216 bp 0x7ffc8c421b00 sp 0x7ffc8c421af8
READ of size 2 at 0x55888490e388 thread T0
    #0 0x5588842cc215 in tor_addr_compare_masked
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x5a6215)
    #1 0x558884203210 in is_local_to_resolve_addr
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x4dd210)
    #2 0x558883f7e252 in channel_tls_connect
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x258252)
    #3 0x558883f87ff7 in channel_connect_for_circuit
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x261ff7)
    #4 0x558883f8bc90 in circuit_handle_first_hop
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x265c90)
    #5 0x558883f8c891 in circuit_establish_circuit
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x266891)
    #6 0x558883fc3bbc in circuit_launch_by_extend_info
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x29dbbc)
    #7 0x558883fc5900
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x29f900)
    #8 0x558883fc6988 in connection_ap_handshake_attach_circuit
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x2a0988)
    #9 0x558883fd0d3f in connection_ap_attach_pending
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x2aad3f)
    #10 0x7f4d50110885  (TorBrowser/Tor/libevent-2.1.so.7+0x22885)
    #11 0x7f4d501110de in event_base_loop
(TorBrowser/Tor/libevent-2.1.so.7+0x230de)
    #12 0x558883f69b3c in do_main_loop
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x243b3c)
    #13 0x558883f3f70c in tor_run_main
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x21970c)
    #14 0x558883f3c2f7 in tor_main
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x2162f7)
    #15 0x558883f3531b in main
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x20f31b)
    #16 0x7f4d4f76acc9 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x26cc9)
    #17 0x558883f3ba00
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x215a00)

0x55888490e388 is located 24 bytes to the left of global variable
'state_mgr' defined in 'src/app/config/statefile.c:184:22'
(0x55888490e3a0) of size 8
0x55888490e388 is located 32 bytes to the right of global variable
'global_state' defined in 'src/app/config/statefile.c:204:20'
(0x55888490e360) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow
(/home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_en-US/Browser/TorBrowser/Tor/tor+0x5a6215)
in tor_addr_compare_masked
Shadow bytes around the buggy address:
  0x0ab190919c20: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x0ab190919c30: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 03 f9 f9 f9
  0x0ab190919c40: f9 f9 f9 f9 03 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0ab190919c50: 00 00 00 04 f9 f9 f9 f9 00 00 00 00 00 00 00 04
  0x0ab190919c60: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
=>0x0ab190919c70: f9[f9]f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0ab190919c80: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x0ab190919c90: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x0ab190919ca0: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0ab190919cb0: 01 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x0ab190919cc0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==4240==ABORTING

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

Previously, we would treat *any* incoming circuit on a non-local
channel as meaning that our ORPort was reachable.  With this patch,
we make sure that the address that the peer _says_ we have is the
same as the one we're trying to advertise right now.

Closes 20165. Bugfix on 4f5192b2 in 0.1.0.1-rc, when
reachability self-tests were first introduced.

Fixes #40105.