Buffer overrun in mac_authencrypt (Issue #446)

Hal Murray 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 mailing list