Fix a framing bug when reading versions from a versions cell.

Our ++ should have been += 2.  This means that we'd accept version
numbers even when they started at an odd position.

This bug should be harmless in practice for so long as every version
number we allow begins with a 0 byte, but if we ever have a version
number starting with 1, 2, 3, or 4, there will be trouble here.

Fix for bug 8059, reported pseudonymously. Bugfix on 0.2.0.10-alpha
-- specifically, commit 6fcda529, where during development I
increased the width of a version to 16 bits without changing the
loop step.
This commit is contained in:
Nick Mathewson 2013-03-11 12:29:28 -04:00
parent 0196647970
commit b9037521c6
2 changed files with 7 additions and 1 deletions

6
changes/bug8059 Normal file
View File

@ -0,0 +1,6 @@
o Minor bugfixes (protocol conformance):
- Fix a misframing issue when reading the version numbers in a
VERSIONS cell. Previously we would recognize [00 01 00 02] as
'version 1, version 2, and version 0x100', when it should have
only included versions 1 and 2. Fixes bug 8059; bugfix on
0.2.0.10-alpha. Reported pseudonymously.

View File

@ -1208,7 +1208,7 @@ channel_tls_process_versions_cell(var_cell_t *cell, channel_tls_t *chan)
tor_assert(chan->conn->handshake_state);
end = cell->payload + cell->payload_len;
for (cp = cell->payload; cp+1 < end; ++cp) {
for (cp = cell->payload; cp+1 < end; cp += 2) {
uint16_t v = ntohs(get_uint16(cp));
if (is_or_protocol_version_known(v) && v > highest_supported_version)
highest_supported_version = v;