1. 18 Sep, 2020 1 commit
    • Nick Mathewson's avatar
      Add flag for whether an OR conn "counts" for bootstrap tracking · 781ab9ee
      Nick Mathewson authored
      We set this flag if we've launched the connection in order to
      satisfy an origin circuit, or when we decide the connection _would_
      satisfy an origin circuit.  These are the only or_connections we
      want to consider for bootstrapping: other or_connections are opened
      because of client EXTEND requests, and they may succeed or fail
      because of the clients' confusion or misconfiguration.
      
      Closes #25061.
      781ab9ee
  2. 17 Sep, 2020 7 commits
  3. 15 Sep, 2020 4 commits
  4. 14 Sep, 2020 4 commits
  5. 10 Sep, 2020 1 commit
  6. 08 Sep, 2020 1 commit
  7. 07 Sep, 2020 1 commit
    • George Kadianakis's avatar
      statistics: Properly count all rendezvous cells (avoid undercounting). · 85a1e6c6
      George Kadianakis authored
      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.
      85a1e6c6
  8. 03 Sep, 2020 1 commit
    • David Goulet's avatar
      addr: Missing AF family to index conversion · ae643081
      David Goulet authored and Alexander Færøy's avatar Alexander Færøy committed
      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's avatarDavid Goulet <dgoulet@torproject.org>
      ae643081
  9. 26 Aug, 2020 3 commits
  10. 25 Aug, 2020 10 commits
  11. 23 Aug, 2020 1 commit
  12. 20 Aug, 2020 2 commits
  13. 19 Aug, 2020 4 commits
    • David Goulet's avatar
      relay: Query our cache when deciding for dummy descriptor fetch · 83052372
      David Goulet authored
      
      
      Instead of looking at the "Address" option alone, instead check if we have an
      address in our cache (that is discovered by tor). If not, then it tells us
      that tor does not have an address to work with so we can then ask a directory
      authority for a suggestion.
      
      Related #2178
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      83052372
    • David Goulet's avatar
      hs: Don't overwrite DoS parameters on circuit with consensus params · f5c9f6d4
      David Goulet authored
      
      
      Turns out that the HS DoS defenses parameters were overwritten by the
      consensus parameters everytime a new consensus would arrive.
      
      This means that a service operator can still enable the defenses but as soon
      as the intro point relay would get a new consensus, they would be overwritten.
      And at this commit, the network is entirely disabling DoS defenses.
      
      Fix this by introducing an "explicit" flag that indicate if the
      ESTABLISH_INTRO cell DoS extension set those parameters or not. If set, avoid
      using the consenus at once.
      
      We are not bumping the protover HSIntro value for this because 0.4.2.x series
      is EOL in 1 month and thus 0.4.3.x would be the only series with this bug. We
      are confident that a backport and then upgrade path to the latest 0.4.4.x
      stable coming up soon is enough to mitigate this problem in the coming months.
      
      It avoids the upgrade path on the service side by keeping the requirement for
      protover HSIntro=5.
      
      Fixes #40109
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      f5c9f6d4
    • George Kadianakis's avatar
      Merge branch 'maint-0.4.4' · 4e3f55fb
      George Kadianakis authored
      4e3f55fb
    • George Kadianakis's avatar
      Merge branch 'mr/124' into maint-0.4.4 · b1b00796
      George Kadianakis authored
      b1b00796