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

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Dec 16 08:56:00 UTC 2015


#17868: base64_decode_nopad() destination buffer length problem
-------------------------+--------------------------------
     Reporter:  dgoulet  |      Owner:
         Type:  defect   |     Status:  new
     Priority:  Medium   |  Milestone:  Tor: 0.2.8.x-final
    Component:  Tor      |    Version:
     Severity:  Normal   |   Keywords:
Actual Points:           |  Parent ID:
       Points:           |    Sponsor:  SponsorR
-------------------------+--------------------------------
 TL;DR; the `base64_decode_nopad()` doesn't work.

 Here is a concrete example. We have `40 bytes` of binary data that we want
 to encode. With padding, that is using `base64_encode()` we end up with a
 size of `56 bytes`. Those resulting bytes, when passed to
 `base64_decode()`, the check on the destination buffer done in that
 function makes it that we need `42 bytes` and not the original `40 bytes`.
 This is due because of the padding.

 One solution, instead of explicitly adding 2 bytes like it's been done in
 many places in the code, it is to use the `_nopad()` interface. However,
 the `base64_decode_nopad()` simply adds some `=` at the end with a new
 source buffer and passes along the base64_decode() function. However the
 `dstlen` that is the destination buffer length where the decoded data will
 go is not updated to reflect the new length of the source buffer so the
 call fails because of the `dstlen` check in the decode function.

 Passing 40 bytes for `dstlen` and 54 for `srclen` (which is the expected
 value _without_ padding), the nopad() call changes `srclen` to 56 bytes
 but then `dstlen` should be 42 bytes else the call fails.

 I'm not sure how to fix that properly apart from making `_nopad()` call
 allocating a new source buffer if needed. I would much prefer that than
 the caller adding bytes beforehand making the code cryptic and honestly
 unsafe to any future length changes.

 Thoughts?

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


More information about the tor-bugs mailing list