]> git.ipfire.org Git - thirdparty/tor.git/commitdiff
Pull up more data when parsing socks messages
authorNick Mathewson <nickm@torproject.org>
Mon, 10 Jan 2011 22:24:16 +0000 (17:24 -0500)
committerNick Mathewson <nickm@torproject.org>
Mon, 10 Jan 2011 22:24:16 +0000 (17:24 -0500)
Previously, we only looked at up to 128 bytes.  This is a bad idea
since socks messages can be at least 256+x bytes long.  Now we look at
up to 512 bytes; this should be enough for 0.2.2.x to handle all valid
SOCKS messages.  For 0.2.3.x, we can think about handling trickier
cases.

Fixes 2330.  Bugfix on 0.2.0.16-alpha.

changes/bug2330 [new file with mode: 0644]
src/or/buffers.c

diff --git a/changes/bug2330 b/changes/bug2330
new file mode 100644 (file)
index 0000000..fc0c4d8
--- /dev/null
@@ -0,0 +1,7 @@
+  o Minor bugfixes
+    - Handle SOCKS messages longer than 128 bytes long correctly, rather
+      than waiting forever for them to finish.  Fixes bug 2330.  Bugfix on
+      0.2.0.16-alpha.  Found by doorss.
+
+
+
index 2a88382501942ccd1902b64556fe7f5a94c9a49c..de0c219e85fbeb5fd78dc8deca8526fae14a36ee 100644 (file)
@@ -1336,6 +1336,10 @@ log_unsafe_socks_warning(int socks_protocol, const char *address,
                               socks_protocol, address, (int)port);
 }
 
+/** Do not attempt to parse socks messages longer than this.  This value is
+ * actually significantly higher than the longest possible socks message. */
+#define MAX_SOCKS_MESSAGE_LEN 512
+
 /** There is a (possibly incomplete) socks handshake on <b>buf</b>, of one
  * of the forms
  *  - socks4: "socksheader username\\0"
@@ -1377,7 +1381,7 @@ fetch_from_buf_socks(buf_t *buf, socks_request_t *req,
   if (buf->datalen < 2) /* version and another byte */
     return 0;
 
-  buf_pullup(buf, 128, 0);
+  buf_pullup(buf, MAX_SOCKS_MESSAGE_LEN, 0);
   tor_assert(buf->head && buf->head->datalen >= 2);
 
   socksver = *buf->head->data;