libcurl explicitly allows users to share cookies between multiple easy handles that are concurrently employed by different threads. When cookies to be sent to a server are collected, the matching function collects all cookies to send and the cookie lock is released immediately afterwards. That funcion however only returns a list with *references* back to the original strings for name, value, path and so on. Therefore, if another thread quickly takes the lock and frees one of the original cookie structs together with its strings, a use-after-free can occur and lead to information disclosure. Another thread can also replace the contents of the cookies from separate HTTP responses or API calls. External References: https://curl.haxx.se/docs/adv_20161102I.html
Created attachment 1213818 [details] Upstream patch
Created curl tracking bugs for this issue: Affects: fedora-all [bug 1390894]
Created mingw-curl tracking bugs for this issue: Affects: fedora-all [bug 1390895] Affects: epel-7 [bug 1390896]
There are some barriers here: an application needs to use libcurl via the "easy API", has to threaded, and on top of that a racy condition has to be triggered, which is probably hard to influence from the outside/malicious servers. I currently don't think that this is a significant problem in a RHEL context.
This issue has been addressed in the following products: Red Hat JBoss Core Services Via RHSA-2018:2486 https://access.redhat.com/errata/RHSA-2018:2486
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS Via RHSA-2018:3558 https://access.redhat.com/errata/RHSA-2018:3558