[Pkg-net-snmp-devel] Bug#963713: Bug#963713: net-snmp: CVE-2019-20892

[Sergio Durigan Junior]

On Sunday, June 28 2020, Craig Small wrote:

> On Fri, 26 Jun 2020 at 07:33, Andreas Hasenack <andreas at canonical.com>
> wrote:
>
>> we are not happy yet with those commits because they change a struct
>> without bumping the soname. We are investigating how impactful that is.
>>
>
> Hi,
>   Did you see how bad these patches are with the API change?  Generally if
> the API is doing things like mystruct_new() and mystruct_free() its
> probably ok but malloc(struct mystruct) will be a problem because the
> binary will have one idea of the size and the library another. It also
> depends if they are using accessor functions to get values or directly
> pulling them out of the struct.
>
> I'm concerned that if the binary has one idea of the struct and the library
> has another we are going to get some very bad corruption going on between
> them.

Yeah, I did investigate that.  You can see some of my findings here:

  https://github.com/net-snmp/net-snmp/commit/39381c4d2#commitcomment-40180748

In an perfect world, a user would not be accessing the struct fields
directly.  However, we can never guarantee that 100%, because the whole
definition of struct used to be exported.  Upstream has changed that
recently (and introduced another API breakage, FWIW).

I think the important piece of information here is that upstream bit the
bullet and bumped the soname recently:

  https://github.com/net-snmp/net-snmp/commit/a0932b73ea0851308ca3e797caa600192cc3508a

But we have to decide what to do with the version we're carrying on
Debian.


Arguably, it is really unlikely that a user will be using this struct in
a program.  And a quick search on sources.d.o tells us that net-snmp is
the only package in the archive that uses this struct:

  https://codesearch.debian.net/search?q=usmStateReference

So we could do like Fedora did and ignore that the ABI has been broken,
since there are no apparent packages that will be affected.  In this
case, the set of patches I backported from upstream is enough to address
the CVE.  This is probably what Ubuntu will do as well, FWIW.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-net-snmp-devel/attachments/20200628/2eb4f0b4/attachment.sig>