Re: [tor-bugs] #22466 [Core Tor/Tor]: "Crosscert is expired" warnings: RSA->Ed25519 identity crosscertifice apparently made in 1970?

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#22466: "Crosscert is expired" warnings: RSA->Ed25519 identity crosscertifice
apparently made in 1970?
-------------------------------------------------+-------------------------
 Reporter:  nickm                                |          Owner:
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.1.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  030-backport tor-relay certificate   |  Actual Points:
  expired 1970                                   |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 There appear to be 3 ways an error like this could happen:

 1. do_hup() is called before the first call to update_approx_time() in
 main().
    (Since cached_approx_time is always set to time(NULL), all subsequent
 calls to do_hup() are safe, unless...)
 2. time(NULL) returns 0 or -1 (or some small value), or
 3. RAM is corrupted, most likely by overwriting a static array stored
 somewhere near cached_approx_time.

 It seems to me that 1. is the most likely, particularly if obtaining the
 log lock hangs.

 Eliminating 2. requires a close reading of the OS documentation and source
 code (see below).

 Eliminating 3. requires checking all the operations on static arrays in
 tor (I checked the ones in util.c, they seem fine). And I think we'd
 notice if we were overwriting a lot of static variables.

 The man page for my system (macOS) describes time()'s return value this
 way:

 {{{
      The time() function returns the value of time in seconds since 0
 hours, 0
      minutes, 0 seconds, January 1, 1970, Coordinated Universal Time,
 without
      including leap seconds.  If an error occurs, time() returns the value
      (time_t)-1.
 ...
      The time() function may fail for any of the reasons described in
      gettimeofday(2).
 ...
      Neither ISO/IEC 9899:1999 (``ISO C99'') nor IEEE Std 1003.1-2001
      (``POSIX.1'') requires time() to set errno on failure; thus, it is
 impos-
      sible for an application to distinguish the valid time value -1
 (repre-
      senting the last UTC second of 1969) from the error return value.
 }}}

 But gettimeofday says:

 {{{
      The following error codes may be set in errno:

      [EFAULT]  An argument address referenced invalid memory.

      [EPERM]   A user other than the super-user attempted to set the time.
 }}}

 Neither of which apply in this case.

 Linux is much more explicit:

 {{{
      When tloc is NULL, the call cannot fail.
 }}}

 So I think we should fix case 1 (initialise approx_time in our signal
 handler if it is invalid, or, if time() is not signal safe, defer any
 actions that depend on time() to the main loop), and see if the issue
 keeps on happening.

 We should also payoff the technical debt we incurred by calling so many
 things from our signal handlers. Because if this is the cause, there is
 likely to be a cluster of race-condition bugs here, not just one.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22466#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs