[tor-bugs] #30040 [Core Tor/Tor]: Double-free bug on huge bandwidth file in some platforms

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

#30040: Double-free bug on huge bandwidth file in some platforms
-------------------------+-------------------------------------------------
     Reporter:  asn      |      Owner:  (none)
         Type:  defect   |     Status:  new
     Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
    Component:  Core     |    Version:
  Tor/Tor                |   Keywords:  bw-auth double-free hackerone bug-
     Severity:  Normal   |  bounty
Actual Points:           |  Parent ID:
       Points:  0.3      |   Reviewer:
      Sponsor:           |
-------------------------+-------------------------------------------------
 Here is a very situational double-free bug reported in hackerone from bug
 hunter paldium. It's a low-severity item since bandwidth files are
 considered trusted input, and anyone who controls a bandwidth file can
 cause worse disasters than double-frees. Also it only applies on very
 specific platforms that none of our dirauths use.

 {{{

 Details:
 The function compat_getdelim_ is used for tor_getline if tor is compiled
 on a system that lacks getline and getdelim. These systems should be
 very rare, considering that getdelim is POSIX.

 If this system is further a 32 bit architecture, it is possible to
 trigger a double free with huge files.

 If bufsiz has been already increased to 2 GB, the next chunk would
 be 4 GB in size, which wraps around to 0 due to 32 bit limitations.

 A realloc(*buf, 0) could be imagined as "free(*buf); return malloc(0);"
 which therefore could return NULL. The code in question considers
 that an error, but will keep the value of *buf pointing to already
 freed memory.

 The caller of tor_getline() would free the pointer again, therefore
 leading to a double free.

 This code can only be triggered in dirserv_read_measured_bandwidths
 with a huge measured bandwith list file on a system that actually
 allows to reach 2 GB of space through realloc.

 It is not possible to trigger this on Linux with glibc or other major
 *BSD systems even on unit tests, because these systems cannot reach
 so much memory due to memory fragmentation.

 This patch is effectively based on the penetration test report of
 cure53 for curl available at https://cure53.de/pentest-report_curl.pdf
 and explained under section "CRL-01-007 Double-free in aprintf() via
 unsafe size_t multiplication (Medium)".

 ## Impact

 Successfully triggering a double free can corrupt the heap
 which might allow more sophisticated attacks within the
 tor application.
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30040>
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