Le vendredi 6 octobre 2023, 19:31:43 UTC Roberto C. Sánchez a écrit : > Hi Bastien, > > On Fri, Sep 29, 2023 at 09:12:57PM +0000, Bastien Roucariès wrote: > > Hi, > > > > I tried to fix CVE-2021-32686 by using patch from upstream. > > > > I think the problem is hard to solve: > > - patch does not apply cleanly and backport will be difficult (moreover it > > is hard to test this kind of race condition) > > I somewhat disagree with your assessment here. I agree that the patch > does not apply cleanly, but the backport seems fairly straightforward. > You did not mention the source you used for the upstream patch and it is > not linked in the security tracker, so I had to go and do some digging. > I was able to find the commit [0] in savoirfairelinux/pjproject (which > is the project which contains the forked pjsip library which is used by > jami, formerly called ring).
Oh I found another upstream from asterisk patch is more clean on your side, but they are still problems and merge issue when merged at top of the patch queue made by Thorsten :S > > The older pjsip located in that project lacks ssl_sock_imp_common.c but > has the other two files. Most of the remainder of the patch applied > (with a small amount of fuzz) and what didn't apply was fairly > straightforward to backport. > > I have attached to this email what I think is a reasonable attempt at > backporting upstream's patch of the forked/modified pjsip on top of > version 20190215.1.f152c98~ds1-1+deb10u2 of ring. Note that I have not > run any build or done any sort of testing on this. > > Could you review the patch and, if you agree that it seems like a > reasonable backport, then build and test the package? Yes but the code in ssl_sock_imp_common.c is in fact here daemon/contrib/src/pjproject/gnutls.patch :S I am a little bit unease about this package. So it need to patch a patch queue or to refactor the code and try something else > > > - ring use a heavy patched PJSIP. A solution will be to use the repackaged > > dfsg pjsip from asterisk (debian dir) and try if ring patches apply > > > > However the second solution will take time for something that is DOS by > > NULL pointer deference.... > > > I agree that this second idea is likely not a good one. We have no way > to feasibly determine if upstream's forked/modified pjsip is entirely > compatible with the pjsip in the Debian archive. The risk would be too > great to switch out an underlying library implementation in this > fashion. > > > Maybe a dsa-ignore will be better for this issue > > > Perhaps first consider the patch that I backported and only if that > doesn't solve the issue satisfactorily, then reconsider marking the CVE > as ignored. > > All of that said, it is interesting to me that fairly recently (at the > end of August) the ring package in buster was updated to fix 23 CVEs, > but this particular CVE was left open. Perhaps it would be worthwhile to > find out from Thorsten (who prepared the most recent update) why that > decision was made. Thorsten could you hint use about this bug on buster ? Bastien > > Regards, > > -Roberto > > [0] > https://github.com/savoirfairelinux/pjproject/commit/d5f95aa066f878b0aef6a64e60b61e8626e664cd > >
signature.asc
Description: This is a digitally signed message part.
