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