[tor-bugs] #27896 [Core Tor/Tor]: base32 padding inconsistency between client and server in HS v3 client auth preview

[Tor Bug Tracker & Wiki]

#27896: base32 padding inconsistency between client and server in HS v3 client auth
preview
--------------------------+------------------------------------
 Reporter:  jchevali      |          Owner:  (none)
     Type:  defect        |         Status:  needs_information
 Priority:  Medium        |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |        Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal        |     Resolution:
 Keywords:  tor-hs        |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by jchevali):

 It's funny; I'm testing this on two servers that are using the same
 tor-0.3.5.3-alpha build (though not the same version of Debian).

 One server is causing the problem I described an hour ago, but only at the
 client side. There seem to be no problem at the server side, and it seems
 to accept unpadded pk descriptors.

 The other server however is not accepting unpadded descriptors, only
 padded descriptors, as per my original bug submission, i.e., it would
 accept this:

 {{{
 descriptor:x25519:LSHKYRU3WPY3QW6HZWET6UW4IKU2WZXRWAVVZZVGR2NROXJ3WQZQ====
 }}}

 (which as you see is the same as the contents in my previous bug comment,
 only with padding)

 If I give it an unpadded pk descriptor in the .auth file, with the same
 exact content I gave the other server, it would crash like this (part what
 I originally called 'padding intolerance'):

 {{{
 tor_assertion_failed_(): Bug: src/feature/hs/hs_descriptor.c:2897:
         hs_desc_build_authorized_client:
         Assertion !tor_mem_is_zero((char *) descriptor_cookie,
 HS_DESC_DESCRIPTOR_COOKIE_LEN) failed; aborting.
 Bug: Assertion !tor_mem_is_zero((char *) descriptor_cookie,
 HS_DESC_DESCRIPTOR_COOKIE_LEN) failed in
         hs_desc_build_authorized_client at
 src/feature/hs/hs_descriptor.c:2897. Stack trace:
 Bug:     ./tor(log_backtrace_impl+0x47) [0x5644802aa7d7]
 Bug:     ./tor(tor_assertion_failed_+0x93) [0x5644802a5e63]
 Bug:     ./tor(hs_desc_build_authorized_client+0x2c7) [0x5644801b99a7]
 Bug:     ./tor(+0x1026e0) [0x5644801bb6e0]
 Bug:     ./tor(hs_service_load_all_keys+0x7c0) [0x5644801bf580]
 Bug:     ./tor(set_options+0xe0a) [0x564480229c2a]
 Bug:     ./tor(options_init_from_string+0x4c7) [0x56448022b997]
 Bug:     ./tor(options_init_from_torrc+0x471) [0x56448022bef1]
 Bug:     ./tor(+0x53d61) [0x56448010cd61]
 Bug:     /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c)
 [0x7fe103a85a6c]
 Bug:     /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7fe103a86537]
 Bug:     ./tor(do_main_loop+0x91) [0x564480121241]
 Bug:     ./tor(tor_run_main+0x1373) [0x56448010f1b3]
 Bug:     ./tor(tor_main+0x3a) [0x56448010c61a]
 Bug:     ./tor(main+0x19) [0x56448010c179]
 Bug:     /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
 [0x7fe1029c9b45]
 Bug:     ./tor(+0x531c9) [0x56448010c1c9]
 }}}

 If I use the padded version, then the server would not crash, however, the
 client will be able to connect to the HS -- which shouldn't be the case,
 because the client hasn't been given any private key to match that (it
 doesn't matter if I give the client under the form of .auth_private files
 private keys for unrelated services, or no private keys / no files at
 all).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27896#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online