Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Backporting CVE-2022-27774 fixes to older curl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Kamil Dudka via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 29 Dec 2022 12:12:34 +0100
On Thursday, December 29, 2022 11:56:59 AM CET Kamil Dudka wrote:
> On Wednesday, December 28, 2022 9:25:39 PM CET Roberto C. Sánchez via curl-library wrote:
> > I am in the process of trying to backport the fixes for CVE-2022-27774
> > (commits 620ea21 and 139a54e) to some older versions of cURL,
> > specifically I'm targeting some pre-7.83.0 versions (i.e., before the
> > refactor of 46620b9).
> >
> > Because the code is somewhat different in the older versions I am
> > targeting, I am also trying to implement the associated tests (973-976
> > in commit 5295e8d). However, the tests also make use of some constructs
> > that seem to have been introduced fairly recently. As a result of that,
> > I am not able to verify my backported patch.
> >
> > In particular, these two lines in 620ea21 refer to struct members which
> > are not present prior to 46620b9:
> >
> > Curl_safefree(data->state.aptr.user);
> > Curl_safefree(data->state.aptr.passwd);
> >
> > My thought is that in the older versions of curl the same is
> > accomplished by this instead:
> >
> > Curl_safefree(data->set.str[STRING_USERNAME]);
> > Curl_safefree(data->set.str[STRING_PASSWORD]);
> >
> > Is someone able to confirm that this is the correct way to deal with
> > CVE-2022-27774 in older curl releases?
> >
> > Regards,
> >
> > -Roberto
>
> You can have a look how I backported the fixes, including the regression tests,
> for curl-7.76.1 in CentOS Stream:
>
> https://gitlab.com/redhat/centos-stream/rpms/curl/-/blob/c9s/0013-curl-7.76.1-CVE-2022-27774.patch
... or the more complicated backport for curl-7.61.1, which also passes
the upstream tests:
https://gitlab.com/redhat/centos-stream/rpms/curl/-/blob/c8s/0038-curl-7.61.1-CVE-2022-27774.patch
> Kamil
Date: Thu, 29 Dec 2022 12:12:34 +0100
On Thursday, December 29, 2022 11:56:59 AM CET Kamil Dudka wrote:
> On Wednesday, December 28, 2022 9:25:39 PM CET Roberto C. Sánchez via curl-library wrote:
> > I am in the process of trying to backport the fixes for CVE-2022-27774
> > (commits 620ea21 and 139a54e) to some older versions of cURL,
> > specifically I'm targeting some pre-7.83.0 versions (i.e., before the
> > refactor of 46620b9).
> >
> > Because the code is somewhat different in the older versions I am
> > targeting, I am also trying to implement the associated tests (973-976
> > in commit 5295e8d). However, the tests also make use of some constructs
> > that seem to have been introduced fairly recently. As a result of that,
> > I am not able to verify my backported patch.
> >
> > In particular, these two lines in 620ea21 refer to struct members which
> > are not present prior to 46620b9:
> >
> > Curl_safefree(data->state.aptr.user);
> > Curl_safefree(data->state.aptr.passwd);
> >
> > My thought is that in the older versions of curl the same is
> > accomplished by this instead:
> >
> > Curl_safefree(data->set.str[STRING_USERNAME]);
> > Curl_safefree(data->set.str[STRING_PASSWORD]);
> >
> > Is someone able to confirm that this is the correct way to deal with
> > CVE-2022-27774 in older curl releases?
> >
> > Regards,
> >
> > -Roberto
>
> You can have a look how I backported the fixes, including the regression tests,
> for curl-7.76.1 in CentOS Stream:
>
> https://gitlab.com/redhat/centos-stream/rpms/curl/-/blob/c9s/0013-curl-7.76.1-CVE-2022-27774.patch
... or the more complicated backport for curl-7.61.1, which also passes
the upstream tests:
https://gitlab.com/redhat/centos-stream/rpms/curl/-/blob/c8s/0038-curl-7.61.1-CVE-2022-27774.patch
> Kamil
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-12-29