[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #17868 [Core Tor/Tor]: base64_decode_nopad() destination buffer length problem
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs