[tor-bugs] #30041 [Core Tor/Tor]: OOB access with huge buffers (src/lib/buf/buffers.c)

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

#30041: OOB access with huge buffers (src/lib/buf/buffers.c)
-------------------------+-------------------------------------------------
     Reporter:  asn      |      Owner:  (none)
         Type:  defect   |     Status:  new
     Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
    Component:  Core     |    Version:
  Tor/Tor                |   Keywords:  security hackerone bug-bounty
     Severity:  Normal   |  029-backport 034-backport 035-backport
Actual Points:           |  Parent ID:
       Points:           |   Reviewer:
      Sponsor:           |
-------------------------+-------------------------------------------------
 Here is an out-of-bounds read bug found by paldium in hackerone. It's a
 low-severity bug because it can only be used for DoS, and requires
 transfer of more than INT_MAX bytes through a connection.

 We should backport to 029 and forward anyhow.

 {{{
 # Summary
 It is possible to trigger out of boundary accesses with buffers if their
 content exceeds INT_MAX bytes. See my first patch (0001) how to trigger
 the issue through unit tests, as this is the easiest way to see what
 happens. It will result in an out of boundary read. A 64 bit system with
 at least 5 GB is required for this unit test though!

 # Explanation
 A buffer consists of one or multiple chunks, which actually contain the
 data. A chunk contains a memory region and a data pointer. The data
 pointer points somewhere into the memory, where the actual user data is
 stored.

 Even though a chunk is free to be larger than INT_MAX, it cannot be
 advised to use such chunks. Whenever a function performs searches or
 lookups, it is bound to "int" due to buf_pos_t. Many functions properly
 check that INT_MAX is not exceeded and throw assertions, but unfortunately
 not all...

 Keeping that in mind, I was able to perform a sequence of actions that in
 fact create chunks with a data length greater than INT_MAX. The int
 variable "pos" will eventually overflow and access memory far ahead from
 reserved user data, effectively performing an out of boundary access.

 # Exploitation
 Generally this is a defensive coding measure to make sure that buffers are
 safe.

 It should be possible to trigger a huge buffer in
 src/core/mainloop/connection.c. In function
 connection_buf_read_from_socket a linked connection (directory
 authentication, as far as I can tell) is joined into the connection buffer
 with buf_move_to_buf.

 The return value of buf_move_to_buf is not properly checked, which means
 that excessively large data returned from the linked connection can slowly
 increase the value of "max_to_read" which means that more and more data
 can be stored in the connection.

 Should it eventually overflow INT_MAX (granted, this takes a LOOONG time),
 the integer calculation will corrupt the buffer, leading to out of
 boundary operations.

 # Patch
 To prevent this issue, both patches (0002 to fix buffers and 0003 to check
 for error return value) must be applied.

 ## Impact

 Heap data is corrupted and out of boundary read access occur. It will be
 very hard to extract data with that, because it would be a blind memory
 check -- and will most likely directly cause a segmentation fault.

 Most likely attack vector is therefore denial of service.
 }}}

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