Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892
On Wed, 8 Jul 2020 at 01:48, Sylvain Beucler wrote: > On 07/07/2020 17:07, Sylvain Beucler wrote: > > In any case, all of this happens between 5.7.3 and 5.8.pre1. > > Restricting further (good..bad): > > $ git shortlog > > 1a0dbe19bf2787bb5bea913f210a9a5eb4c0c80c..e207b8113260fd7d84df0ebdb66925ab70da29b2 > Robert Story (2): > Add VMware copyright > tweak sndMsgMaxSize handling > > VMwareDev Randy (4): > getbulk enhancements: limit responses gathered > reduce session msg max sizes to transport max > getbulk enhancements: response size + fallback to forward encoding > move v3 engineID probe into initial packet build > Thanks for doing this bisect. So the issue happened after 5.7.3 (this change happened in 2015, 5.7.3 was released in 2014) which means we only need to worry about unstable and testing. - Craig
Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892
Hi, Do we have definite info on what versions are affected? I cannot reproduce the issue in jessie/stretch/buster (5.7.x). Incidentally Salvatore's test now yields an error in bullseye (5.8dfsg-3), though I suspect the issue is at the client's level: # snmpbulkget -v3 -Cn1 -Cr1472 -l authPriv -u testuser -a SHA -A testpass -x AES -X testpass 127.0.0.1 1.3.6.1.2.1.1.5 1.3.6.1.2.1.1.7 Error in packet. Reason: (genError) A general failure occured Cheers! Sylvain Beucler Debian LTS Team
Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892
On Monday, June 29 2020, Craig Small wrote: > Hi All > There's a few goes of the required patches but I think I've got them all. > There was the v3doublefree2.patch, a format patch and then the first git > reference in the tracker where they have re-arranged the free function so > it tracks the reference count. > > The result does compile and build packages and it is not too terrible about > the lintian warnings, but I haven't installed or tested it yet; that's a > job for tomorrow (which is only an hour away, but it will be much longer > than that). If anyone is keen in the meantime go ahead and see if it works > for you. Hey Craig, Thanks for the work on the patches; I've had to do the same for Ubuntu, so I understand the complexity... :-) I'd like to propose an improvement on the current fix. While doing the backports on Ubuntu, I noticed a few other patches that were needed in order to guarantee that the existing memory leaks were addressed. Unfortunately, the very first upstream commit that tried to fix the CVE ended up introducing some leaks, and in the end it was necessary to reorganize the code a little bit to solve them all. The commits are scattered over the history, sometimes without much context, so it takes a little time until we have a proper set of them to be backported. Anyway, I took the liberty to open an MR here: https://salsa.debian.org/debian/net-snmp/-/merge_requests/3 This MR adds the extra patches from upstream, performs some renames, and brings the Debian package closer to the Ubuntu version. Let me know what you think. 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/
Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892
Hi All There's a few goes of the required patches but I think I've got them all. There was the v3doublefree2.patch, a format patch and then the first git reference in the tracker where they have re-arranged the free function so it tracks the reference count. The result does compile and build packages and it is not too terrible about the lintian warnings, but I haven't installed or tested it yet; that's a job for tomorrow (which is only an hour away, but it will be much longer than that). If anyone is keen in the meantime go ahead and see if it works for you. - Craig On Sun, 28 Jun 2020 at 22:30, Salvatore Bonaccorso wrote: > Hi Andreas, > > On Fri, Jun 26, 2020 at 06:31:44PM -0300, Andreas Hasenack wrote: > > I believe it was introduced in 5.8. The previous version we had was 5.7.3 > > and we didn't reproduce it there. > > I can confirm that it is not reproducible with the buster version with > the avalable reproducer, but I was still searching evidence via a code > change/upstream commit where the issue was really introduced. > > If you find/found so, could you please update us as well with that > informaation so we can sync up the security-tracker information. > > Thanks for your work! > > Regards, > Salvatore > > ___ > Pkg-net-snmp-devel mailing list > pkg-net-snmp-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-net-snmp-devel
Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892
On Sunday, June 28 2020, Craig Small wrote: > On Fri, 26 Jun 2020 at 07:33, Andreas Hasenack > 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/ signature.asc Description: PGP signature
Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892
On Fri, 26 Jun 2020 at 07:33, Andreas Hasenack 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. - Craig
