Buffer overrun in mac_authencrypt (Issue #446)
hmurray at megapathdsl.net
Mon Jan 8 05:54:21 UTC 2018
This is likely to involve some discussion so I moved it here where that will
be more convenient.
We should be supporting longer digests. Wikipedia says:
NIST's directive that U.S. government agencies must stop uses of SHA-1 after
2010 was hoped to accelerate migration away from SHA-1.
There is no panic on fixing the bug since it won't happen unless you setup
your keys file to (try to) use a digest type with a longer hash.
I see several options:
Reject digest types that don't fit. This is what ntp classic does. It's
simple to implement. It fixes the buffer overrun but doesn't support longer
Truncate longer digests. This is simple to implement (4 lines of code), but
I don't want to think about the security. (or waste the time of any security
geek, or give them an opportunity to snicker at us, or ...)
Make MAX_MAC_LEN bigger. This seems like a bad idea since the current max
size is wired into RFC 7822 (May 2017). But there is an escape: "unless a
longer MAC is agreed upon by both client and server". Anybody using a longer
digest has obviously agreeded. It's simple to implement. It's very likely
to lead to compatibility troubles when we want to use extension fields.
Put larger digests into a new type-length extension. This seems like the
right approach. We'd have to get a type code from IANA. That could be
complicated - politics rather than technical.
These are my opinions. I hate spam.
More information about the devel