Hi again I was able to reproduce the issue and I can confirm that it is solved by the update.
On an unfixed version I run the following: curl -L -e ";auto" -raw -v http://test:p...@inguza.com/' And the resulting Referer output was: > Referer: http://test:p...@inguza.com/ With the fixed package I run the same command: curl -L -e ";auto" -raw -v http://test:p...@inguza.com/' And the resulting Referer output was correctly stripped: > Referer: http://inguza.com/ Great! So I think it looks good. Best regards // Ola On Mon, 17 May 2021 at 12:30, Ola Lundqvist <o...@inguza.com> wrote: > 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 | > --------------------------------------------------------------- > > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
