Date: Thu, 24 Jan 2002 15:40:51 -0700 (MST) From: "Aaron D.Gifford" <agifford@infowest.com> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/34242: [PATCH] Off-by-one bug in /usr/src/sys/crypto/sha2/sha2.c - easy fix included (patch) Message-ID: <20020124224051.C4A9522533@ns1.infowest.com>
next in thread | raw e-mail | index | archive | help
>Number: 34242 >Category: kern >Synopsis: Off-by-one bug in /usr/src/sys/crypto/sha2/sha2.c - easy fix included (patch) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 24 14:50:01 PST 2002 >Closed-Date: >Last-Modified: >Originator: Aaron D. Gifford >Release: FreeBSD 4.5-RC i386 >Organization: >Environment: System: FreeBSD my.host 4.5-RC FreeBSD 4.5-RC #1: Sat Jan 12 12:09:54 MST 2002 root@my.host:/usr/obj/usr/src/sys/MYKERNEL i386 >Description: The SHA-256/385/512 implementation used by KAME and FreeBSD that I wrote has an off-by-one bug that results in bad hashes for a minority of input data sets. I have included a quick, simple patch to fix the problem below. I have rated this as "serious" because this bug may prevent FreeBSD hosts from properly interoperating with other hosts when using IPva in certain configurations when data packets are just right to trigger the bad hash. This also means that FIXED hosts may have trouble talking to BROKEN hosts in that same small subset of cases where hash input data lengths were just right to expose the bug. I say "may" in the above, because there is a very real possibility that actual real-world usage might not ever tweak the bug at all, in which case this bug is not serious at all. >How-To-Repeat: I am unaware as to whether or not real-world IPv6 usage encounters the bad has bug. However, my own SHA2 test data sets clearly expose the bug. Thanks to Rogier van de Pol who originally brought the bug to my attention with his test data sets. >Fix: Apply the patch below. It changes only two lines in the source code file, making a "<" comparison into a "<=" comparision, completely fixing the off-by-one bug. I should have acted sooner to get this fix into 4.5, and probably should have reported the bug as soon as it was brought to my attention and was fixed. The below fix has been applied to KAME CVS now for several months. I appologize for my procrastination. The details of the bug the below patch fixes are: * When SHA-256 input data length "L" is L = 55 + 64 * X where where X is an integer >= 0, the off-by-one bug results in the generation of a bad SHA-256 hash. * When SHA-384 or SHA-512 input data lengths "L" are L = 111 + 128 * X (again, X X is an integer >= 0), then the resulting SHA-384 or SHA-512 hashes will be bad. Thanks to Rogier van de Pol for sending me test data that revealed the bug so that I could fix it. For test vectors, visit my SHA2 implementation's web site at: http://www.aarongifford.com/computers/sha.html The below patch is against FreeBSD-STABLE sources as of Jan. 24, 2002. Thank you. Aaron Gifford --- /usr/src/sys/crypto/sha2/sha2.c.orig Thu Jan 24 15:03:56 2002 +++ /usr/src/sys/crypto/sha2/sha2.c Thu Jan 24 15:04:59 2002 @@ -566,7 +566,7 @@ /* Begin padding with a 1 bit: */ context->buffer[usedspace++] = 0x80; - if (usedspace < SHA256_SHORT_BLOCK_LENGTH) { + if (usedspace <= SHA256_SHORT_BLOCK_LENGTH) { /* Set-up for the last transform: */ bzero(&context->buffer[usedspace], SHA256_SHORT_BLOCK_LENGTH - usedspace); } else { @@ -883,7 +883,7 @@ /* Begin padding with a 1 bit: */ context->buffer[usedspace++] = 0x80; - if (usedspace < SHA512_SHORT_BLOCK_LENGTH) { + if (usedspace <= SHA512_SHORT_BLOCK_LENGTH) { /* Set-up for the last transform: */ bzero(&context->buffer[usedspace], SHA512_SHORT_BLOCK_LENGTH - usedspace); } else { >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020124224051.C4A9522533>