[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5647 [Tor Hidden Services]: rend_parse_client_keys() prints stack in logs if base64_decode fails
#5647: rend_parse_client_keys() prints stack in logs if base64_decode fails
---------------------------------+------------------------------------------
Reporter: asn | Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.2.x-final
Component: Tor Hidden Services | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by arma):
Replying to [comment:4 asn]:
> Kinda lame that gcc and coverity didn't detect this one as use of
uninitialized variable. Maybe we should send them an email?
We're passing an array to a function, which then passes it to all sorts of
other functions. I'm not too surprised that gcc/coverity couldn't convince
themselves that we don't write to it.
> Also, should `srclen` in `base64_decode` be
> `REND_DESC_COOKIE_LEN_BASE64+2+1` or `REND_DESC_COOKIE_LEN_BASE64+2` to
match with:
> {{{
> if (strlen(tok->args[0]) != REND_DESC_COOKIE_LEN_BASE64 + 2) {
> }}}
> ?
>
> It seems to me that if the base64 blob doesn't contain padding
characters, `base64_decode` will also read the NUL (because of the `+1`)
and fail. In other cases of `base64_decode()` we are feeding the output of
`strlen()` as the `srclen`, which does not consider the NUL.
No idea. I would hope our base64_decode is robust to a nul at the end of
the source string.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5647#comment:5>
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