[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