[tor-bugs] #18977 [Core Tor/Tor]: correct_tm() doesn't set r->tm_wday, but format_rfc1123_time() uses it
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon May 9 17:43:02 UTC 2016
#18977: correct_tm() doesn't set r->tm_wday, but format_rfc1123_time() uses it
-------------------------------------------------+-------------------------
Reporter: teor | Owner: nickm
Type: defect | Status:
Priority: Medium | accepted
Component: Core Tor/Tor | Milestone: Tor:
Severity: Normal | 0.2.8.x-final
Keywords: 028-proposed 025-backport | Version: Tor:
026-backport 027-backport | 0.2.8.2-alpha
Parent ID: | Resolution:
Reviewer: | Actual Points:
| Points: small
| Sponsor:
-------------------------------------------------+-------------------------
Comment (by teor):
Code review:
T1: There are 4 cases, but only 3/4 set tm_wday.
How far we should backport:
This bug can crash on OSs where `int t = 0; r = tor_gmtime_r(&t, ...);`
returns NULL, or a non-NULL r with r->tm_year outside the range -1899 to
8099. This has only been detected as a bug by our unit tests on Windows so
far.
Once this case is triggered, if an int of uninitialised stack memory
happens to be outside 0-6, tor crashes.
It's only triggered by code paths that set if_modified_since in
directory_send_command() to 0, and most code paths on relays and clients
set if_modified_since to 0. (It might also be possible for authorities to
trigger this crash by passing a directory server a cached-but-not-
validated consensus that has a bad time value, but I have yet to confirm
this.)
There are many clients but few relays on Windows.
Given the simplicity of this patch, and the fact that a failure causes a
crash, I suggest we backport it to 0.2.4 (the latest running version on
the network) onwards.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18977#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list