Hi Sylvain I have done some regression testing and it looks fine.
I'll try to reproduce the actual issue too. // Ola On Mon, 17 May 2021 at 11:09, Sylvain Beucler <b...@beuc.net> wrote: > Hi, > > I thought you'd rebuild but here you go. > > I intend to upload today. > > Cheers! > Sylvain > > On 17/05/2021 08:13, Ola Lundqvist wrote: > > Hi again Sylvain > > > > Today I was about to test the packages but I realize that I only have a > > libcurl-doc deb file to test. > > > > Will you upload the rest for testing too? > > > > // Ola > > > > On Sun, 16 May 2021 at 09:08, Ola Lundqvist <o...@inguza.com > > <mailto:o...@inguza.com>> wrote: > > > > Hi > > > > I have reviewed the changes and it looks good. > > I'll see if I can get some time to perform any relevant tests too. > > > > // Ola > > > > On Sat, 15 May 2021 at 23:34, Sylvain Beucler <b...@beuc.net > > <mailto:b...@beuc.net>> wrote: > > > > Hi Ola, > > > > You can check the LTS version at: > > https://www.beuc.net/tmp/debian-lts/curl/ > > <https://www.beuc.net/tmp/debian-lts/curl/> > > > > I followed the method from Ubuntu and SUSE and backported the > > URL API > > for LTS and ELTS, plus the new test case for the CVE. > > > > I'm currently diffing the test suite results, cf. my notes at: > > https://wiki.debian.org/LTS/TestSuites/curl > > <https://wiki.debian.org/LTS/TestSuites/curl> > > > > Cheers! > > Sylvain > > > > On 15/05/2021 23:22, Ola Lundqvist wrote: > > > Hi Sylvain > > > > > > Great! Let me know if you want help with review, testing or > > something else. > > > > > > // Ola > > > > > > On Sat, 15 May 2021 at 23:18, Sylvain Beucler <b...@beuc.net > > <mailto:b...@beuc.net> > > > <mailto:b...@beuc.net <mailto:b...@beuc.net>>> wrote: > > > > > > Hi, > > > > > > I claimed it yesterday and my work is mostly done. > > > > > > Cheers! > > > Sylvain > > > > > > On 15/05/2021 23:11, Ola Lundqvist wrote: > > > > Hi Utkarsh > > > > > > > > I have looked into your patch and I think it looks > > good. I do not > > > fully > > > > understand why all the changes in url.c were done but > > I think it > > > looks > > > > fine anyway. > > > > The risk of regression should be small. > > > > > > > > Do you want me to do the update, or do you want to do > > it yourself? > > > > Or do you think we should ignore it? > > > > > > > > Best regards > > > > > > > > // Ola > > > > > > > > On Thu, 8 Apr 2021 at 22:33, Ola Lundqvist > > <o...@inguza.com <mailto:o...@inguza.com> > > > <mailto:o...@inguza.com <mailto:o...@inguza.com>> > > > > <mailto:o...@inguza.com <mailto:o...@inguza.com> > > <mailto:o...@inguza.com <mailto:o...@inguza.com>>>> wrote: > > > > > > > > Hi Utkarsh, all > > > > > > > > I have done some more investigation on this > > matter. I have > > > checked > > > > the statement from upstream that we can re-use > > some existing > > > strip > > > > code to remove the strings this way. > > > > The thing is that I cannot find any code that do > > URL stripping so > > > > that is not really a viable option. This leaves > > only the two > > > options > > > > you have already stated. > > > > > > > > Either we ignore, or we port the entire URL API. > > > > > > > > I think the risk of regression is rather small if > > we port it, > > > > because this is only used in this place. Assuming > > there is no > > > name > > > > clash introduced. > > > > > > > > So what do you all think? Ignore or fix? > > > > There are good arguments for both. > > > > > > > > Ignore is ok because this only happens with a > specific > > > command line > > > > option, and even if used the risk of problem is > > quite small. > > > > > > > > On the other hand curl is a very common tool which > > means that it > > > > could be worth fixing even small issues. > > > > > > > > I think both are ok. > > > > > > > > Best regards > > > > > > > > // Ola > > > > > > > > On Wed, 7 Apr 2021 at 23:07, Ola Lundqvist > > <o...@inguza.com <mailto:o...@inguza.com> > > > <mailto:o...@inguza.com <mailto:o...@inguza.com>> > > > > <mailto:o...@inguza.com <mailto:o...@inguza.com> > > <mailto:o...@inguza.com <mailto:o...@inguza.com>>>> wrote: > > > > > > > > Hi Utkarsh, all > > > > > > > > After reading the description of this CVE > > again I realize > > > that I > > > > misunderstood the description last time. > > > > > > > > The problem is that the "referrer" header is > > not stripped. > > > > > > > > This changes my conclusion to some extent. > > > > > > > > I see no problem with fixing this issue from a > > regression > > > point > > > > of view (apart from what has already been > > expressed). > > > > The amount of services that rely on the > > referrer field > > > should be > > > > small, if any. > > > > > > > > I still think we can ignore it though with the > > > same reasoing as > > > > I expressed in the last email. The problem > > should be minor. > > > > There are other worse problem by providing > > sensitive data > > > in the > > > > URL. > > > > And again if the attacker can make a redirect, > the > > > attacker can > > > > most likely get the URL anyway so then nothing > > has leaked. > > > > > > > > Cheers > > > > > > > > // Ola > > > > > > > > > > > > // Ola > > > > > > > > On Wed, 7 Apr 2021 at 13:19, Ola Lundqvist > > > <o...@inguza.com <mailto:o...@inguza.com> > > <mailto:o...@inguza.com <mailto:o...@inguza.com>> > > > > <mailto:o...@inguza.com <mailto:o...@inguza.com> > > <mailto:o...@inguza.com <mailto:o...@inguza.com>>>> wrote: > > > > > > > > Hi Utkarsh, all > > > > > > > > Is this even a vulnerability? > > > > The problem is that authentication > > information is not > > > > stripped if the browser is redirected to > > another place. > > > > > > > > If you trust a site enough to provide > > authentication > > > data, I > > > > guess you also trust that if that site > > happens to be > > > > relocated you should also trust the new > place. > > > > I mean if the attacker has the power to > > redirect I expect > > > > that it has the power to read the > > authentication data > > > > anyway. There could be cases when this is > > not the > > > case, but > > > > in general it should not be possible for > > the attacker to > > > > redirect without also having more power. > > > > > > > > We could of course consider to apply this > > fix, but it > > > > certainly will cause a regression since my > > expectation is > > > > that authentication information is > forwarded. > > > > > > > > I think it should be ignored. If we fix > > it, it should be > > > > with a configuration option, but I think > > that is a > > > > little too intrusive for (E)LTS. > > > > > > > > Or have I missed something? > > > > > > > > Best regards > > > > > > > > // Ola > > > > > > > > On Mon, 5 Apr 2021 at 02:20, Utkarsh Gupta > > > > <utka...@debian.org > > <mailto:utka...@debian.org> <mailto:utka...@debian.org > > <mailto:utka...@debian.org>> > > > <mailto:utka...@debian.org <mailto:utka...@debian.org> > > <mailto:utka...@debian.org <mailto:utka...@debian.org>>>> wrote: > > > > > > > > Hello, > > > > > > > > [CCing the Security team in case they > > have some > > > ideas or > > > > suggestions > > > > for CVE-2021-22876/curl] > > > > > > > > Whilst triaging and looking thoroughly > > for this CVE, > > > > affecting curl, I > > > > noticed that the upstream patch uses > > elements > > > like CURLU, > > > > > > CURLUPART_{URL,FRAGMENT,USER,PASSWORD}. This > > > comes from > > > > the URL API > > > > which seems to be missing in both, > > stretch and > > > jessie. > > > > > > > > There seem to be two plausible options > > at this point: > > > > > > > > 1. Given that this CVE has been > > assigned low > > > severity by > > > > upstream, we > > > > could perhaps mark this as no-dsa or > > ignored, with an > > > > appropriate > > > > comment; or > > > > > > > > 2. Backport the entire URL API (patch > > for that is > > > > attached; is > > > > intrusive) and then apply the fix for > > CVE-2021-22876 > > > > (patch attached) > > > > on top of that. Whilst this option > > makes sense, but > > > > backporting the > > > > entire URL API could have an > > unforeseen effect (or > > > > chances of > > > > potential regressions) and in any > > case, looks > > > somewhat > > > > intrusive. > > > > > > > > So for now, I've added curl to > > dla-needed and > > > ela-needed > > > > but if we > > > > decide to mark this as no-dsa or > > ignored, we could > > > > simply drop this > > > > from there as this is the only CVE > > that needs > > > working on. > > > > > > > > Let me know what y'all think. > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
