<p><br>
On Oct 8, 2013 4:41 PM, "Nick Mathewson" <<a href="mailto:nickm@alum.mit.edu">nickm@alum.mit.edu</a>> wrote:<br>
><br>
> On Mon, Oct 7, 2013 at 5:55 PM, Pedro Ribeiro <<a href="mailto:pedrib@gmail.com">pedrib@gmail.com</a>> wrote:<br>
> > ---------- Forwarded message ----------<br>
> > From: Colin Childs via RT <<a href="mailto:help@rt.torproject.org">help@rt.torproject.org</a>><br>
> > Date: 7 October 2013 14:25<br>
> > Subject: [<a href="http://rt.torproject.org">rt.torproject.org</a> #14731] Off by one buffer overflow in tor stable<br>
> > To: <a href="mailto:pedrib@gmail.com">pedrib@gmail.com</a><br>
> ><br>
> ><br>
> > On Mon Oct 07 12:13:21 2013, <a href="mailto:pedrib@gmail.com">pedrib@gmail.com</a> wrote:<br>
> >> Hi,<br>
> >><br>
> >> I think there is a small buffer overflow (off by one) in the current stable<br>
> >> version of tor.<br>
> >> The function in question is format_helper_exit_status, which returns a<br>
> >> formatted hex string. It is in common/util.c, starting at line 3270.<br>
> >> The function has a comment header that explains how it works. It<br>
> >> specifically says it returns a string that is not null terminated, but<br>
> >> instead terminates with a newline.<br>
> >><br>
> >> The code checks periodically throughout the function whether it has written<br>
> >> more bytes than it should. If it does, it errors out and writes a null<br>
> >> character in the current character positions. This by itself can lead to a<br>
> >> buffer overflow, but I believe the checks ensure that it almost never<br>
> >> writes over the buffer size - except in one case.<br>
> >><br>
> >> After it has finished everything, it then checks again if there are more<br>
> >> than 0 bytes left in the buffer. If there are, it writes two characters - a<br>
> >> newline and a null terminator (lines 3342 to 3347).<br>
> >><br>
> >> The problem here is if the buffer only has one byte left, an off by one<br>
> >> overflow occurs. These usually are very hard to exploit, but can be a<br>
> >> security issue nonetheless.<br>
> >><br>
> >> However given that I am not familiar with the tor codebase I might be<br>
> >> wrong? I also did a quick security audit on the rest of the tor code and<br>
> >> couldn't find anything else. I was inspire because of the recent events...<br>
> >><br>
><br>
> Thanks, Pedro!  Thanks for looking at Tor!<br>
><br>
> I agree that this probably isn't exploitable, but let's not take any<br>
> chances.  (I'm thinking "Not exploitable" not because off-by-one<br>
> buffer overflows are safe, but because in order to get the overflow to<br>
> happen at all, you would need to have errno be a high-magnitude<br>
> negative number, which is not usually something that happens on unixy<br>
> platforms. Moreover, you'd need to arrange for this to happen as a<br>
> result of launching a pluggable transport proxy, which is not usually<br>
> something under the attacker's control.)<br>
><br>
> Nonetheless , this should get fixed.  I've opened<br>
> <a href="https://trac.torproject.org/projects/tor/ticket/9928">https://trac.torproject.org/projects/tor/ticket/9928</a> to track it, and<br>
> written a possible fix.<br>
><br>
> best wishes,<br>
> --<br>
> Nick<br>
> _______________________________________________<br>
> tor-dev mailing list<br>
> <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
> <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a></p>
<p>No problem Nick.</p>
<p>If you issue an advisory, credit to Pedro Ribeiro (<a href="mailto:pedrib@gmail.com">pedrib@gmail.com</a>) is appreciated.</p>
<p>Regards<br>
Pedro <br>
</p>