Bug 1306953 - hash input truncation: GNUTLS vs nettle
hash input truncation: GNUTLS vs nettle
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnutls (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Nikos Mavrogiannopoulos
Stanislav Zidek
: Rebase
Depends On:
Blocks: 1296594 1313485
  Show dependency treegraph
Reported: 2016-02-12 04:38 EST by Dr. David Alan Gilbert
Modified: 2016-11-03 20:59 EDT (History)
4 users (show)

See Also:
Fixed In Version: gnutls-3.3.22-1.el7
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-11-03 20:59:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1310103 None None None 2016-02-19 09:27 EST

  None (edit)
Description Dr. David Alan Gilbert 2016-02-12 04:38:18 EST
Description of problem:

GNUTLS has a function gnutls_hash:

   int gnutls_hash(gnutls_hash_hd_t handle, const void * ptext, size_t ptext_len);

it lets you perform md5 or any of the other hashes on a chunk of data;
this is implemented by a call to the nettle libraries implementation:

md5_update(struct md5_ctx *ctx,
           unsigned length,        <<<<<-
           const uint8_t *data);

Note that here someone unwisely used an 'unsigned' length.

Thus if you pass a large ptext_len into gnutls_hash, the length gets
truncated and thus only produces a hash on part of the data.
In my case I passed a 4GB chunk which ended up hashing 0 bytes!

Nettle fixed this upstream in:
   b8bfc32f (Niels Möller 2013-04-26 10:28:57 +0200)
   Use size_t rather than unsigned for all hash-related functions.

I'm not sure if gnutls has any fixes.

I hit this during development, I'm not aware of anything in particular
that would hit it.

Here's a backtrace that shows the truncation:

Breakpoint 1, gnutls_hash (handle=0x7f5a74029020, text=0x7f5a83e00000, textlen=4294967296) at crypto-api.c:503
503             return _gnutls_hash((digest_hd_st *) handle, text, textlen);
(gdb) b wrap_nettle_hash_update

Breakpoint 2, wrap_nettle_hash_update (_ctx=0x7f5a74045b10, text=0x7f5a83e00000, textsize=4294967296) at mac.c:305
305     {
(gdb) list

Breakpoint 3, nettle_md5_update (ctx=0x7f5a74045b10, length=0, data=0x7f5a83e00000 "S\377") at md5.c:62
62	{

I guess you could fixit in the wrap_nettle_hash_update (that's part of gnutls), but I guess you would also have to go on a hunting trip for anything
else that makes the same mistake.  Or update nettle.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. allocate 4GB of RAM
2. Initialise gnutls
3. gnutls_hash on the 4GB chunk using md5

Actual results:
The md5 result for a zero length input.

Expected results:
The md5 result for your actual data.

Additional info:
Comment 4 Karel Srot 2016-02-16 10:03:22 EST
Is this kind of fix safe? Wouldn't it break ABI?
Comment 5 Nikos Mavrogiannopoulos 2016-02-16 10:07:35 EST
The fix is for gnutls only which uses an ABI that allows 64-bit numbers; thus it doesn't break the ABI. The API problem with nettle is not addressed by the fix.
Comment 12 errata-xmlrpc 2016-11-03 20:59:14 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.