[Pkg-openssl-devel] Bug#793565: Bug#793565: libssl1.0.0: HMAC broken after upgrade to 1.0.2d-1

[Marc Lehmann]

On Sat, Jul 25, 2015 at 07:40:41PM +0200, Kurt Roeckx <kurt at roeckx.be> wrote:
> > Well, many people "work gvpe". Maybe you meant "how"? gvpe uses openssl's
> > HMAC (by default hmac-sha512) to verify packet integrity, and when
> > upgrading libssl to 1.0.2d-1, for some connections, every packet gets a
> > HMAC authentication error (causing complete loss of connectivity) that
> > goes away once libssl is downgraded again.
> 
> I tried some of the test vectors in rfc4231 with the version from
> squeeze, wheezy, jessie and stretch and they all produce the same
> correct output.

It indeed can't be as simple as that, as not all connections seem to be
affected, so the problem must happen during key generation (which also
uses hmac sha2 for the hkdf, and openssl's rsa). gvpe runs it's own test
vectors for its hkdf implementation at startup, which doesn't fail either.

(This is all with the current CVS version of gvpe btw.).

> So it seems more likely that this is either a bug in gvpe or
> something cpu specific.

I don't think this logic is valid yet - it could surely be a usage bug (or
worse, such as unrelated data corruption) in gvpe of course, but since
it only manifests itself with the new openssl binary and only in some
circumstances (as originally reported), I still think a change in openssl
is more likely, especially as gvpe works fine with openssl versions down
to 0.9.8 at least.

Regardless, the problem is reproduces on i7-3930K, i5-4670S and i5-3337U,
i.e. sandy bridge e and newer. I haven't been able to test this on anything
else.

I tried both binaries (see below) with OPENSSL_ia32cap=0, with no visible
change in behaviour.

> > > This is very unlikely.  But if it's really the case rebuilding
> > > against that version should fix the issue.
> 
> Please note that I'm not saying that this is how you should fix
> it, it's a test to see if that's the issue or not.

Took me a while to be able to run tests, but the problem moves with the
libcrypto binary, not the header files:

                                 libcrypto stable       libcrypto testing
   gvpe + libssl-dev stable          works              hmac auth errors
   gvpe + libssl-dev testing         works              hmac auth errors

Or in prose: regardless of which header files were used to compile and
link, with libssl1.0.0 from stable it works, with libsssl1.0.0 from
testing it fails. specifically, a binary compiled with libssl-dev from
testing fails with libcrypto under tetsing but works with libcrypto on
stable.

That kind of rules out the header files, at least. I also visually
inspected the HMAC_CTX definition, and it's almost certainly identical, so
its not a simple structure laypout problem in the headers.

I additionally ran both binaries under valgrind to exclude obvious bugs,
but apart from lzf compression (which does access uninitialised data),
there is no output from valgrind either, so it's at leats not some obvious
corruption bug.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\