---------- Forwarded message ---------- From: Colin Childs via RT help@rt.torproject.org Date: 7 October 2013 14:25 Subject: [rt.torproject.org #14731] Off by one buffer overflow in tor stable To: pedrib@gmail.com
On Mon Oct 07 12:13:21 2013, pedrib@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...
Regards Pedro
Hello,
Please send a copy of this email to our tor-dev mailing list at https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev.
Thank you!
-- Colin C.
-------------------------------------------
Hi,
Please find above a bug report with possible security implications. I was a bit weary of sending to a public list at first, but I doubt the bug above is exploitable.
Regards Pedro
On Mon, Oct 7, 2013 at 5:55 PM, Pedro Ribeiro pedrib@gmail.com wrote:
---------- Forwarded message ---------- From: Colin Childs via RT help@rt.torproject.org Date: 7 October 2013 14:25 Subject: [rt.torproject.org #14731] Off by one buffer overflow in tor stable To: pedrib@gmail.com
On Mon Oct 07 12:13:21 2013, pedrib@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,
On Oct 8, 2013 4:41 PM, "Nick Mathewson" nickm@alum.mit.edu wrote:
On Mon, Oct 7, 2013 at 5:55 PM, Pedro Ribeiro pedrib@gmail.com wrote:
---------- Forwarded message ---------- From: Colin Childs via RT help@rt.torproject.org Date: 7 October 2013 14:25 Subject: [rt.torproject.org #14731] Off by one buffer overflow in tor
stable
To: pedrib@gmail.com
On Mon Oct 07 12:13:21 2013, pedrib@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@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@gmail.com) is appreciated.
Regards Pedro
-
Nick Mathewson -
Pedro Ribeiro