From agifford@infowest.com  Thu Jan 24 14:42:11 2002
Return-Path: <agifford@infowest.com>
Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10])
	by hub.freebsd.org (Postfix) with ESMTP id AE5C637B41C
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 24 Jan 2002 14:42:09 -0800 (PST)
Received: from 208.186.104.163 (eq.net [208.186.104.163])
	by ns1.infowest.com (Postfix) with SMTP id C4A9522533
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 24 Jan 2002 15:40:51 -0700 (MST)
Message-Id: <20020124224051.C4A9522533@ns1.infowest.com>
Date: Thu, 24 Jan 2002 15:40:51 -0700 (MST)
From: Aaron D.Gifford <agifford@infowest.com>
Reply-To: Aaron D.Gifford <agifford@infowest.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [PATCH] Off-by-one bug in /usr/src/sys/crypto/sha2/sha2.c - easy fix included (patch)
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>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:    ume
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 24 14:50:01 PST 2002
>Closed-Date:    Tue Feb 26 09:12:47 PST 2002
>Last-Modified:  Tue Feb 26 09:14:09 PST 2002
>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:

From: "Aaron D. Gifford" <agifford@infowest.com>
To: freebsd-gnats-submit@FreeBSD.org, agifford@infowest.com
Cc:  
Subject: Re: kern/34242: Off-by-one bug in /usr/src/sys/crypto/sha2/sha2.c - easy fix included (patch)
Date: Thu, 21 Feb 2002 14:26:16 -0700

 Just following up on this bug report to see if anyone has actually looked at 
 it yet.
 
 FYI, I am the original author of the file (sha2.c) in question.  This PR is a 
 bug fix.  The KAME sources already have this very same fix.  Since I use 
 FreeBSD regularly, I think it would be nice to get my favorite OS fixed too.
 
 Thank you.
 
 Aaron out.
Responsible-Changed-From-To: freebsd-bugs->ume 
Responsible-Changed-By: johan 
Responsible-Changed-When: Thu Feb 21 20:01:03 PST 2002 
Responsible-Changed-Why:  
Over to KAME maintainer who imported the stuff. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=34242 
State-Changed-From-To: open->closed 
State-Changed-By: ume 
State-Changed-When: Tue Feb 26 09:12:47 PST 2002 
State-Changed-Why:  
Thank you! 
Now, sha2.c is quite sync with KAME's one. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=34242 
>Unformatted:
