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:pass@inguza.com/
<http://test:pass@inguza.com/>'
And the resulting Referer output was:
> Referer: http://test:pass@inguza.com/ <http://test:pass@inguza.com/>
With the fixed package I run the same command:
curl -L -e ";auto" -raw -v http://test:pass@inguza.com/
<http://test:pass@inguza.com/>'
And the resulting Referer output was correctly stripped:
> Referer: http://inguza.com/ <http://inguza.com/>
Great!
So I think it looks good.
Best regards
// Ola
On Mon, 17 May 2021 at 12:30, Ola Lundqvist <ola@inguza.com
<mailto:ola@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 <beuc@beuc.net
<mailto:beuc@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 <ola@inguza.com
<mailto:ola@inguza.com>
> <mailto:ola@inguza.com <mailto:ola@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
<beuc@beuc.net <mailto:beuc@beuc.net>
> <mailto:beuc@beuc.net <mailto:beuc@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/>
> <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>
> <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
<beuc@beuc.net <mailto:beuc@beuc.net>
> <mailto:beuc@beuc.net <mailto:beuc@beuc.net>>
> > <mailto:beuc@beuc.net <mailto:beuc@beuc.net>
<mailto:beuc@beuc.net <mailto:beuc@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
> <ola@inguza.com <mailto:ola@inguza.com>
<mailto:ola@inguza.com <mailto:ola@inguza.com>>
> > <mailto:ola@inguza.com <mailto:ola@inguza.com>
<mailto:ola@inguza.com <mailto:ola@inguza.com>>>
> > > <mailto:ola@inguza.com
<mailto:ola@inguza.com> <mailto:ola@inguza.com
<mailto:ola@inguza.com>>
> <mailto:ola@inguza.com <mailto:ola@inguza.com>
<mailto:ola@inguza.com <mailto:ola@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
> <ola@inguza.com <mailto:ola@inguza.com>
<mailto:ola@inguza.com <mailto:ola@inguza.com>>
> > <mailto:ola@inguza.com <mailto:ola@inguza.com>
<mailto:ola@inguza.com <mailto:ola@inguza.com>>>
> > > <mailto:ola@inguza.com
<mailto:ola@inguza.com> <mailto:ola@inguza.com
<mailto:ola@inguza.com>>
> <mailto:ola@inguza.com <mailto:ola@inguza.com>
<mailto:ola@inguza.com <mailto:ola@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
> > <ola@inguza.com <mailto:ola@inguza.com>
<mailto:ola@inguza.com <mailto:ola@inguza.com>>
> <mailto:ola@inguza.com <mailto:ola@inguza.com>
<mailto:ola@inguza.com <mailto:ola@inguza.com>>>
> > > <mailto:ola@inguza.com
<mailto:ola@inguza.com> <mailto:ola@inguza.com
<mailto:ola@inguza.com>>
> <mailto:ola@inguza.com <mailto:ola@inguza.com>
<mailto:ola@inguza.com <mailto:ola@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
> > > <utkarsh@debian.org
<mailto:utkarsh@debian.org>
> <mailto:utkarsh@debian.org
<mailto:utkarsh@debian.org>> <mailto:utkarsh@debian.org
<mailto:utkarsh@debian.org>
> <mailto:utkarsh@debian.org <mailto:utkarsh@debian.org>>>
> > <mailto:utkarsh@debian.org
<mailto:utkarsh@debian.org> <mailto:utkarsh@debian.org
<mailto:utkarsh@debian.org>>
> <mailto:utkarsh@debian.org
<mailto:utkarsh@debian.org> <mailto:utkarsh@debian.org
<mailto:utkarsh@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.