[Opendnssec-announce] Security bug: Off-by-one error and new year

[Rickard Bellgrim]

Dear OpenDNSSEC user

During the end of last year, a bug was uncovered in the library ldns.
The bug had an off-by-one error which caused some signatures to have
the expiration date set to December 31 2012. 64-bit versions are
unaffected.

Affected versions: ldns < 1.6.12 (32-bit)
Fixed versions: ldns >= 1.6.12 (32-bit)

Description:
The 32-bit version of ldns has code for converting days since epoch to
the day of year. That code had a bug which handled the end of the year
in the wrong way. The result of the bug was that some signatures got
the intended validity period extended by a year. The signature will be
reused by the Signer Engine until the key is rolled. However, the
Enforcer is not aware that there exist signatures with such a long
validity period. Any affected signature will thus have no
post-publication of its corresponding DNSKEY, possibly resulting in
validation failure. There is also the risk that the affected signature
will be used in a replay attack.

Test for affected signatures:
The affected signatures can be spotted by reviewing your signed zone.
E.g. by using the following command:
> grep "20121231[0-9]\{6\} 2011" signed.zone.file

Remove the affected signatures:
If there are signatures in the zone with extra long validity periods,
then it is recommended to recreate all of the signatures. This is done
by clearing the internal storage of the Signer Engine. You then wait
for the next scheduled re-sign, but you can also force an immediate
re-sign (the second command below) to speed up the process:
> ods-signer clear <zone>
> ods-signer sign <zone>

Mitigate replay attacks:
Once the affected signatures are removed from the zone, it may also be
advisable to roll your keys. If you have a non-static zone and are
changing your zone data, then there is a chance for an attacker to
replay old data since the signature is still valid. You need to assess
the risk and possible cost of such an attack. If you need to mitigate
such an attack, then you need to roll your keys. Rolling keys will
invalidate any signatures that an attacker may have stored for later
use. If the signature of the DNSKEY RRset was affected, then you also
need to roll the KSK:
> ods-ksmutil key rollover --zone <zone> --keytype ZSK
> ods-ksmutil key rollover --zone <zone> --keytype KSK

Solution:
The issue has been fixed in ldns 1.6.12. You should upgrade ldns
before the end of this year.

// OpenDNSSEC team