[tor-dev] Fwd: [rt.torproject.org #14731] Off by one buffer overflow in tor stable

[Pedro Ribeiro]

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

No problem Nick.

If you issue an advisory, credit to Pedro Ribeiro (pedrib at gmail.com) is
appreciated.

Regards
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20131008/aee31877/attachment.html>