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>> 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>>> 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>>> 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>>> 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>>> 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.