[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#709490: marked as done (Two disastrous bugs in RHash in Wheezy)



Your message dated Sat, 15 Jun 2013 17:21:41 +0700
with message-id <51BC4035.20602@gmail.com>
and subject line The bug is fixed
has caused the Debian Bug report #709490,
regarding Two disastrous bugs in RHash in Wheezy
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
709490: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709490
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org

Dear stable release managers,
The RHash 1.2.9-8 utility in Wheezy contains two security bugs:

1. it incorrectly calculates SHA-512 hash sum for files of certain size;
2. it incorrectly calculates GOST hash on non-x86/amd64 CPUs on certain
messages.

Please accept the fix (see below) into security archive.

In more detail.
1. SHA-512 is incorrectly calculated for files with size
   112 <= (file_size % 128) < 120.
 The bug occurs only when several files are sequentually hashed.

Internal buffer of SHA-512 context was not fully cleared by zeroes, when
processing final block of data.
See also the related SF-Bug: https://sourceforge.net/p/rhash/bugs/31/

Steps to reproduce:
 perl -e 'print "\xff"x112' > msg.bin
 rhash --sha512 --openssl="" msg.bin msg.bin
Expected output:
91078b0922e575edeb26558219603518141f167d6edeb7dfd56225beddd5482b0ab282d4feccffbe52eeb8fa0eff9b9d331c5fc55ad0d1d4b1b71cb29f2a0060
msg.bin
91078b0922e575edeb26558219603518141f167d6edeb7dfd56225beddd5482b0ab282d4feccffbe52eeb8fa0eff9b9d331c5fc55ad0d1d4b1b71cb29f2a0060
msg.bin

2. Hashes of messages containing byte sequences of 0xFF are incorrectly
calculated on ARM and non-Intel CPU's.

Steps to reproduce (on ARM or non-Intel CPU):
 perl -e 'print "\xff"x112' > msg.bin
 rhash --gost msg.bin
Expected output:
c6a27541b302df03366345955c0e45be0c6ea8639e4147ec7f37b11eee9e2370  msg.bin

How two fix.
The fix is available as RHash 1.2.9-9 [1] in Testing for some time, so
it should be well tested for now.
This package contain two small patches (see attachments) backported from RHash 1.2.10.

[1] http://packages.debian.org/testing/rhash

  With best wishes,
  Aleksey





  

Description: Fix GOST on non x86 CPUs for some specific messages
 The patch fixes GOST hash calculation for some messages containg sequences of
 0xFFFFFFFF words. The patch also adds two test vectors to check for the bug:
 .
 GOST( 64 of 0xFF ) =
    13416C4EC74A63C3EC90CB1748FD462C7572C6C6B41844E48CC1184D1E916098
 GOST-CRYPTOPRO ( 64 of 0xFF ) =
    58504D26B3677E756BA3F4A9FD2F14B3BA5457066A4AA1D700659B90DCDDD3C6
 .
 Those test vectors can be verified by OpenSSL console utility 'gostsum'.
 The bug does not occur on x86 and x86-64, because on these  archs
 assembly code replaces C.

Author: Aleksey Kravchenko <rhash.admin@gmail.com>
Origin: upstream https://github.com/rhash/RHash/commit/d2f4378043d13f5e61ef408eb2c7bf021feb1b69
Forwarded: not-needed
Last-Update: 2012-12-31

---
 librhash/gost.c        | 4 ++--
 librhash/test_hashes.c | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/librhash/gost.c b/librhash/gost.c
index 0d1612c..a6d8404 100644
--- a/librhash/gost.c
+++ b/librhash/gost.c
@@ -325,10 +325,10 @@ static void rhash_gost_compute_sum_and_hash(gost_ctx * ctx, const unsigned* bloc
 
 	/* compute the 256-bit sum */
 	for(i = 0; i < 8; i++) {
-		const unsigned old = ctx->sum[i];
 		LOAD_BLOCK_LE(i);
 		ctx->sum[i] += block_le[i] + carry;
-		carry = (ctx->sum[i] < old || ctx->sum[i] < block_le[i] ? 1 : 0);
+		carry = (ctx->sum[i] < block_le[i] ? 1 :
+			ctx->sum[i] == block_le[i] ? carry : 0);
 	}
 #endif /* USE_GCC_ASM_IA32 */
 
diff --git a/librhash/test_hashes.c b/librhash/test_hashes.c
index e712493..85bdbdd 100644
--- a/librhash/test_hashes.c
+++ b/librhash/test_hashes.c
@@ -605,7 +605,9 @@ static void test_long_strings(void)
 		assert_rep_hash(tests[count].hash_id, 'a', 1000000, tests[count].expected_hash);
 	}
 
-	/* note: it would be better to check with more complex pre-generated messages */
+	/* now we verify some specific cases */
+	assert_rep_hash(RHASH_GOST, 0xFF, 64, "13416C4EC74A63C3EC90CB1748FD462C7572C6C6B41844E48CC1184D1E916098");
+	assert_rep_hash(RHASH_GOST_CRYPTOPRO, 0xFF, 64, "58504D26B3677E756BA3F4A9FD2F14B3BA5457066A4AA1D700659B90DCDDD3C6");
 
 	/* these messages verified by eMule LinkCreator (which uses eMule variant of ED2K hash) */
 	assert_rep_hash(RHASH_ED2K, 0, 9728000, "FC21D9AF828F92A8DF64BEAC3357425D");
-- 
Description: Fix incorrect claculation of SHA-512 for some files
 SHA-512 was not correctly calculated for files with size
   112 <= (file_size % 128) < 120.
 The bug occurs only when several files are sequentually hashed.
 .
 Internal buffer of SHA-512 context was not fully cleared by zeroes,
 when processing final block of data.
 See also SF-Bug: https://sourceforge.net/p/rhash/bugs/31/

Author: Aleksey Kravchenko <rhash.admin@gmail.com>
Origin: upstream https://github.com/rhash/RHash/commit/43acddb523a94ddc5207449e9560a504faa26e68
Forwarded: not-needed
Last-Update: 2012-12-31

---
 librhash/sha512.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/librhash/sha512.c b/librhash/sha512.c
index 0999e72..7eb55d3 100644
--- a/librhash/sha512.c
+++ b/librhash/sha512.c
@@ -238,6 +238,7 @@ void rhash_sha512_final(sha512_ctx *ctx, unsigned char* result)
 
 	/* if no room left in the message to store 64-bit message length */
 	if(index >= 15) {
+		if(index == 15) ctx->message[index] = 0;
 		rhash_sha512_process_block(ctx->hash, ctx->message);
 		index = 0;
 	}
-- 

--- End Message ---
--- Begin Message ---
Fixed in the RHash version 1.2.9-8+deb7u1 :)

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---

Reply to: