commit 0704fa8a63c2e203162c359e184e63b10c45630c Author: Nick Mathewson nickm@torproject.org Date: Tue Aug 30 09:00:34 2016 -0400
Handle u32 overflow in ed25519 cert expiration time.
The impact here isn't too bad. First, the only affected certs that expire after 32-bit signed time overflows in Y2038. Second, it could only make it seem that a non-expired cert is expired: it could never make it seem that an expired cert was still live.
Fixes bug 20027; bugfix on 0.2.7.2-alpha. --- changes/bug20027 | 3 +++ src/or/torcert.c | 6 +++++- 2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/changes/bug20027 b/changes/bug20027 new file mode 100644 index 0000000..79d1540 --- /dev/null +++ b/changes/bug20027 @@ -0,0 +1,3 @@ + o Minor bugfixes (ed25519 certificates): + - Correctly interpret ed25519 certificates that would expire some + time after 19 Jan 2038. Fixes bug 20027; bugfix on 0.2.7.2-alpha. diff --git a/src/or/torcert.c b/src/or/torcert.c index 2629155..ef7775e 100644 --- a/src/or/torcert.c +++ b/src/or/torcert.c @@ -139,7 +139,11 @@ tor_cert_parse(const uint8_t *encoded, const size_t len) cert->encoded_len = len;
memcpy(cert->signed_key.pubkey, parsed->certified_key, 32); - cert->valid_until = parsed->exp_field * 3600; + const int64_t valid_until_64 = ((int64_t)parsed->exp_field) * 3600; + if (valid_until_64 > TIME_MAX) + cert->valid_until = TIME_MAX - 1; + else + cert->valid_until = (time_t) valid_until_64; cert->cert_type = parsed->cert_type;
for (unsigned i = 0; i < ed25519_cert_getlen_ext(parsed); ++i) {
tor-commits@lists.torproject.org