Bug 2323290

Tracked here https://ibm.service-now.com/sn_vul_ibm_advisory.do?sys_id=a33255a91b21bd10d4122f42b24bcbdf&sysparm_record_list=123TEXTQUERY321%3drgw%5eu_migration_in_progress%3dfalse%5eu_global_visibility%3dtrue%5eORassigned_to%3dcfb41ac787ef1d944e7e98273cbb3592%5eORu_oss_assignee%3dcfb41ac787ef1d944e7e98273cbb3592%5eORsys_created_by%3d4J9557-897%5eORassignment_groupIN1e68e3d81b242d1099310d88cc4bcb37%2cded84ecadb2e3b0094af25894b96197e%2c2a4fd2d71b8581d0e4b0ffbf034bcbdf%2c3308282ddb4fe340c717e9ec0b961961%2c1bcac29a1ba0ad9099310d88cc4bcb5b%2c1ef80a9e1b60ad9099310d88cc4bcbb4%5eORu_all_products_refCONTAINSeeb90ed21ba0ad9099310d88cc4bcb29%5eORu_all_products_refCONTAINS5612f8421ba0a59099310d88cc4bcb26%5eORDERBYzztextsearchyy&sysparm_record_row=1&sysparm_record_rows=5&sysparm_record_target=sn_vul_ibm_advisory&sysparm_view=&sysparm_view_forced=true and https://github.com/ceph/ceph/security/advisories/GHSA-cmvq-rgwm-c896

Hello,

I think Robin Johnson originally reported this issue in 2020 against Nautilus 14.2.11+ but if there was a fix issued for the issue then I missed it.

Test Case
Set this CORS policy (AllowedOrigin = " *", space before '*'):
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><CORSRule><AllowedMethod>GET</AllowedMethod><AllowedMethod>PUT</AllowedMethod><AllowedMethod>DELETE</AllowedMethod><AllowedMethod>HEAD</AllowedMethod><AllowedMethod>POST</AllowedMethod><AllowedOrigin> *</AllowedOrigin><AllowedOrigin>https://asset.harianaceh.co.id</AllowedOrigin><AllowedHeader>*</AllowedHeader><MaxAgeSeconds>3600</MaxAgeSeconds></CORSRule></CORSConfiguration>

Issue this request: curl -H 'Origin: chrome-extension://mpognobbkildjkofajifpdfhcoklimli' -o /dev/null -v <url>

RGW will crash if still susceptible.

Proposed Patch
This is what we've been using to avoid the issue (and since we have this deployed everywhere it's not a quick test for me to see if Pacific+ is still vulnerable)

commit 4b9a10ff8028c894a9fec1c4334844af5334ec76
Author: Joshua Baergen <jbaergen>
Date:   Mon Nov 30 11:11:50 2020 -0700

    rgw: Add missing empty checks to the split string in is_string_in_set().

    In certain cases, where a user misconfigures a CORS rule, the entirety
    of the string can be token characters (or, at least, the string before
    and after a given token is all token characters), but != "*". If the
    misconfigured string includes "*" we'll try to split the string and we
    assume that we can pop the list of string elements when "*" isn't
    first/last, but get_str_list() won't return anything for token-only
    substrings and thus 'ssplit' will have fewer elements than would be
    expected for a correct rule. In the case of an empty list, front() has
    undefined behaviour; in our experience, it often results in a huge
    allocation attempt because the code tries to copy the string into a
    local variable 'sl'.

    An example of this misconfiguration (and thus a reproduction case) is
    configuring an origin of " *".

diff --git a/src/rgw/rgw_cors.cc b/src/rgw/rgw_cors.cc
index 3fa600ad1d6..26e88cce43c 100644
--- a/src/rgw/rgw_cors.cc
+++ b/src/rgw/rgw_cors.cc
@@ -95,6 +95,8 @@ static bool is_string_in_set(set<string>& s, string h) {

       get_str_list((*it), "* \t", ssplit);
       if (off != 0) {
+        if (ssplit.empty())
+          continue;
         string sl = ssplit.front();
         flen = sl.length();
         dout(10) << "Finding " << sl << ", in " << h << ", at offset 0" << dendl;
@@ -103,6 +105,8 @@ static bool is_string_in_set(set<string>& s, string h) {
         ssplit.pop_front();
       }
       if (off != ((*it).length() - 1)) {
+        if (ssplit.empty())
+          continue;
         string sl = ssplit.front();
         dout(10) << "Finding " << sl << ", in " << h
           << ", at offset not less than " << flen << dendl;

Let me know if you need anything else!

Thanks,
Josh