[tor-bugs] #17868 [Core Tor/Tor]: base64_decode_nopad() destination buffer length problem

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Jun 20 19:52:34 UTC 2016


#17868: base64_decode_nopad() destination buffer length problem
----------------------------+------------------------------------
 Reporter:  dgoulet         |          Owner:  nikkolasg
     Type:  defect          |         Status:  needs_revision
 Priority:  Medium          |      Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor    |        Version:
 Severity:  Normal          |     Resolution:
 Keywords:  review-group-4  |  Actual Points:
Parent ID:                  |         Points:  0.1
 Reviewer:                  |        Sponsor:  SponsorR-can
----------------------------+------------------------------------
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * reviewer:  dgoulet =>


Comment:

 Seems now that the nopad function is useless because it's just a call to
 `base64_decode()`. This also doesn't solve the issue. Using
 `base64_encode_size()` computation, here is an example (all in bytes):

 to_encode_size = 40
 encoded_size = base64_encode_size(40) == 56

 `base64_decode()` makes this check: `if (destlen < (srclen*3)/4)`

 ... which turns out that if destlen is 40 and srclen is 56, well that
 check fails which is the original issue here. The nopad function should
 have taken a smaller value since we don't need padding thus don't go to
 56. That nopad function needs to compensate for the extra padding that the
 decode one wants to put in there (which is what was there in the first
 place).

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


More information about the tor-bugs mailing list