Fix using of uninitialized buffer "t"

[svpcom]

Status

READY

Requires Backporting

Yes

Which branch?
All branches

Migrations

NO

Additional comments

Security fix

[AndrzejKurek]

Hello, @svpcom, and thanks for the contribution!
Unfortunately, bzero that you've used is Unix-specific, and we're targeting multiple other platforms. You could consider using mbedtls_platform_zeroize instead, but could you please elaborate first about the details of this fix?
When exactly is t used as an uninitialized buffer? What are the preconditions?
Thanks in advance.

[svpcom]

In mbedtls_hkdf_expand there are unsigned char t[MBEDTLS_MD_MAX_SIZE];
in loop:

/*
     * Compute T = T(1) | T(2) | T(3) | ... | T(N)
     * Where T(N) is defined in RFC 5869 Section 2.3
     */
    for( i = 1; i <= n; i++ )
    {

HMAC read data from uninitialized t at the first iteration of loop

ret = mbedtls_md_hmac_update( &ctx, t, t_len );

So T(1) can be undefined if compiler doesn't zeroize t

[Patater]

Could you please add a regression test? We test with ASan and would expect a failure there if we provide the right test case.

[Patater]

memset() should be fine here, since t doesn't contain secrets at this point.

[Patater]

For the mbedtls-2.16 and mbedtls-2.7 branches, we need a contributor license agreement (CLA) in order to take onboard your fix.

If this is a personal contribution, the easiest way to do this is if you create an mbed account and accept this click through agreement. Alternatively, you can find a slightly different agreement to sign here, which can be signed and returned to us, and is applicable if you don't want to create an mbed account or alternatively if this is a corporate contribution.

Thanks!

[AndrzejKurek]

@svpcom, looking at the first iteration, mbedtls_md_hmac_update is called with t_len equal to 0.
Implementations shouldn't access a buffer of zero length, and if they do, accessing uninitialized data is just the smaller of their problems - accessing data out of bounds is worse (in my opinion).

Thanks to @yanesca for also taking a look at this.

[danh-arm]

Hi @svpcom. It seems this PR stalled since earlier reviewers think there is not an issue here. If you still think there's an issue then please comment otherwise we will close.

Also note that we now require a "Signed-off-by:" line in contributions so if you want to want to submit a reworked PR, please apply this.

Thanks, Dan.

[gilles-peskine-arm]

Thank you for reporting this! As Andrzej notes, there's no bug: the part of t that gets read is always initialized. However it would be more robust to do it explicitly. In the interest of moving on, I made a slightly different fix at #3160 which supersedes this PR.