CVE-2023-37941 seems to be a legit CVE

[Marcono1234]

According to https://www.cve.org/CVERecord?id=CVE-2023-37941 the CVE was assigned by the Apache Software Foundation themselves (instead of MITRE), and also was not disputed.

Maybe they just wanted to be on the safe side since this is at least related to security hardening, even if there might still be other ways in which write access to the database could be exploited.

[vin01]

yeah my guess is also that they fixed it nonetheless to be on the safe side but not as a vulnerability because pickle is used in other places as well which is just fine, from the linked PR:

However, the metastore cache will still use pickle, as it needs to be able to handle arbitrary binary types

However the company tried to use it as a "RCE" (for marketing boost?) while there is nothing being done "Remotely" here but only by compromising the actual database where superset even stores admin credentials.

I sent them a request to reject this one but so far have not heard back.

[nvn1729]

I wrote that blog post, I'm not sure what aspect of it comes across as marketing. There is remote code execution proven on the web server.

This involved chaining multiple issues: first getting access to the metadata store and then inserting a pickle in the store and triggering deserialization to get to RCE on the Superset web server. Getting access to the metadata store is possible multiple ways (one related to the SQLite install that's tracked as CVE-2023-39265 and another related to abusing a MySQL file read vulnerability that was not assigned a CVE).

I didn't break down the CVEs, just provided the full attack paths to Apache leading to RCE. CVE-2023-39265 is rated as a low by Apache even though it's what enables the RCE. CVE-2023-37941 is rated as a medium with high access complexity even though it's easy to get access to the metadata store via CVE-2023-39265.

If CVE-2023-39265 and CVE-2023-37941 were bundled as one CVE, they'd be a 7.2 high, which is what an admin RCE is normally rated as. And maybe another CVE for the MySQL file read case leading to RCE. Again I didn't file the CVEs - that was Apache.

Another complication was there was another reporter of CVE-2023-37941, so that might have factored into how Apache broke these down.

fyi, the metastore cache does not use pickle anymore by default.

[vin01]

HI @nvn1729, thanks for your comment. I will be happy to follow up.

With access to metadata database, wouldn't an attacker be able to insert their own admin account into superset thus compromising the instance?

Regarding accessing metadata store, it would still happen if a postgresql/mysql server (being used to store superset data) allows superset server to connect to it, after all superset allows access to privileged users to connect to any database. Shouldn't this be a server misconfiguration if un-trusted users are granted privileged access? It would be a flaw if read-only users or unauthenticated users were able to connect to databases. Privileged users have access to entire data that superset might be used for visualizing so if an attacker requires privileged access, it is game over.

An admin might in fact for a real use case need Sqlite/any-database access to be able to update the database via UI itself using sql lab, they should be free to do so as an admin.

[nvn1729]

@vin01

I think you're missing the full context, and I'm not sure you've really read the blog posts or used Superset to make a proper judgment.

An unauthenticated attacker starts by getting access to an admin account for the Superset web app. This could be through default creds or using a default FLASK_KEY issue to forge a session cookie (CVE-2023-27524) or other means.

Once the attacker has admin privileges to the web application, the attacker is able to get Superset to connect to its own metadata store (which is SQLite by default or could be MySQL/Postgres). There is no reason that I can think of that a Superset admin should be able to manage Superset's own configuration through SQLLab, nor is it an expected use case. There is nothing in the documentation suggesting users should manage the web app config this way. That's the point of the web application, and a recommendation I added in the post was that Superset should have a security limitation to prevent connections to its own metadata store.

With write access to the metadata store an attacker can update it to get RCE on the Superset web server. An attacker in this position would not add another admin account because the attacker already has admin access to the web app. The point is to pivot from access to the web app to getting access to the web server host.

I don't think you would ordinarily expect admin access to a web app to automatically result in RCE on the web server, do you? There are some web apps that provide shells onto hosts by design - that's not what we're talking about here. If you think admin access leading to RCE is not a valid attack path, then there are many CVEs that should be scrubbed entirely from NVD. While we're at it, let's scrub reflected XSS and DoS vulnerabilities too.

Regardless of how the CVEs break down, this is a highly impactful attack path. There's a metasploit module in progress and another PoC (none of which I wrote personally) to automate the whole flow from unauthenticated user -> RCE.

There are plenty of bogus CVEs out there from people abusing MITRE, which I think is the point of this repo right?. But I did not file the CVEs, Apache did. I personally don't care enough to dispute how Apache filed the CVEs and rated them (and I'm the one who filed the issues to begin with). The attack paths and blog posts speak for themselves. I'm not sure what you intend to follow up on, and what exactly you consider to be "marketing."

Keep in mind that, while there are plenty of bogus CVEs out there, there are also cases where orgs don't correctly file CVEs and sometimes minimize the real impact. Recent examples on the CISA known exploited vulnerabilities list:

CVE-2023-0669 - GoAnywhere MFT - this is a preauth RCE, but somehow got a 7.2. Juniper SRX CVEs - initially rated as medium but actually it's a preauth RCE: https://labs.watchtowr.com/cve-2023-36844-and-friends-rce-in-juniper-firewalls/

[vin01]

Oh yeah of course there are a lot of orgs not filing CVEs, or becoming CNAs to control the information flow, that is a different topic and something as an industry we have tried to solve with public disclosure.

However, since you mentioned use of default secret key, that is an issue in itself if someone does not generate a secure key as the documentation suggests, again, not something fundamentally wrong with or a bug in the tool itself in my opinion. Changing default session encryption keys is the standard guideline for any new application installation be it Flask or any other framework. Also with that key, again you do not need any further RCE to compromise anything since you can have an admin account session created for you to login and that is all you need. Check out the warning from Django at https://docs.djangoproject.com/en/4.2/topics/http/sessions/#using-cookie-based-sessions

An attacker in possession of the SECRET_KEY or SECRET_KEY_FALLBACKS can not only generate falsified session data, which your site will trust, but also remotely execute arbitrary code, as the data is serialized using pickle.

^ and yes, this does not need a CVE.

Having admin access means being able to access all the data the server has access to, which is the most critical thing, you can execute arbitrary sql code using sql lab already with that access. "Secure design in all places" and "an exploitable practical vulnerability" are two different things.

I have been wondering the process Apache followed for the CVEs of course, I am in contact with them and waiting for feedback.

[nvn1729]

You seem to be confusing several things. Admin access to the application is not the same as RCE on the web server hosting the web application. With Superset, yes it means access to data and executing SQL against connected databases, and you could get RCE on the database server (this is a separate issue and there was rightly no CVE assigned for it). However using admin privileges to connect to Superset's own database (with a URL bypass for the default SQLite install) and get RCE on the web server is an entirely different thing and not at all expected. Is that what you'd expect? Is that not a real issue?

re: the default SECRET_KEY - this could have gone either way. It was surfaced as a CVE to make sure people were aware of it given thousands of servers on the Internet are affected and it was the default. There is precedent with other CVEs in other applications for the same thing (look at Airflow, CouchDB, etc). For better or worse, there is no other way to coordinate disclosure to the public and get users to update without a CVE. Again I did not file this CVE.

I'm still waiting to hear what part of these very real impactful attack paths going from unauthenticated access -> RCE seem like "marketing"? You seemed to have completely misunderstood the actual attack path based on your comments here and https://github.com/apache/superset/pull/23888#issuecomment-1712192516.

[vin01]

well, let's try to see it this way. Suppose you have RCE access (even via SSH) to a superset web server which connects to no database but is just a single container or server running there. What is the worst that one can do from that?

In comparison, take a superset server with access to N databases containing critical data on which you have Edit/Admin privileges, you can basically exfiltrate all the data once you are admin. This is what an actual RCE would look like, a weakness allowing unprivileged users to execute code and hence -> modifying config -> making themselves Admin so they can access and exfil. all the critical data. In this case the attacker has access to all the data anyways.

There are tools which have the threat model of an adversary having admin access and there are tools which do not, same with having access to session secret key. It does not make sense in all places. Like I pointed out for Django, _a RCE after having gained a SECRETKEY is not a security flaw because access to SECRET_KEY is the worst that can happen, there is nothing to exploit in practical sense after that.

[nvn1729]

No, access to the SECRET_KEY is definitely not the worst that can happen. Let's say you have RCE in a container and ignore the data (for all we know the data may in fact not be critical or useful at all). Let's also ignore the local container file system too. From that position an attacker can affect anything else on the network accessible from that container. That means being able to pivot to another container/machine, getting access to more credentials (including access keys in the case of cloud metadata services), and potentially access to more data. It makes it much more likely an attacker can also establish persistence, install a miner to harvest compute, etc. These are very different set of impacts from having access to just the data or SECRET_KEY.

Your arguments have been highly inconsistent. Let's review:

"However the company tried to use it as a "RCE" (for marketing boost?) while there is nothing being done "Remotely" here but only by compromising the actual database where superset even stores admin credentials."

False. This is being done remotely. Access to the database is from the web app itself. The vectors to gain access to database from the web app are in the blog post that you linked to yourself.

"because pickle is used in other places as well which is just fine, from the linked PR"

False, the metastore cache does not use pickle anymore.

"With access to metadata database, wouldn't an attacker be able to insert their own admin account into superset thus compromising the instance?"

You've misunderstood the attack path entirely here. An attacker doesn't start with access to the database server. If an attacker already had access to the database server, I wouldn't have reported anything to begin with.

"With write access to the metadata database, I don't think any further steps are needed to compromise anything here. Such CVEs should be outright rejected."

False. The attack path describes how to get write access to the metadata database through the web app and then get to RCE on the web server through the web app, leading to additional impacts I've described at the top.

Let's look at your rationale for calling out this CVE from the main page:

"Anyone can request a CVE with no obligation to get in touch with the maintainers. Validation of the vulnerability is done on a cursory level, but of course, this process is not thorough because often validation requires an in-depth understanding and deep knowledge of the tools involved. Triaging the bugs is a time-consuming process that even the biggest companies struggle with in their bug bounty programs."

I worked with Apache on this for months, and they filed the CVEs. They triaged the issues, updated the code to be more secure, and reviewed my posts ahead of time. If none of this stuff was important, you wouldn't see a metasploit module/other PoCs being written to automate this attack path. Apache wouldn't have made the code changes to begin with. If you read the post, you would have seen the actual data gathered to support the overall impact of this with Internet-facing servers. The multiple places I privately reported this attack path to wouldn't have bothered remediating if it wasn't important.

There are plenty of bogus CVEs out there but in this case you jumped to inaccurate conclusions and didn't actually read the blog posts that you claimed to be marketing ahead of time.

At the end of the day, the CVEs don't really matter to me at all - the blog posts would have been written the same way regardless without the CVE IDs. What matters is the exploitability and impact. The CVEs are a side effect.

[vin01]

with admin access you can connect to other network components using database connections and sql lab :) And any serious installation would not allow you to connect to other instances unless its really mis-configured. You can still find hundreds of servers of all kinds on Shodan using default session keys or admin accounts, passwords. No one can fix that.

There would have been no exploitation here with all these flaws if a superset instances is configured as it should be i.e. using a secure secret key as the documentation suggests (just like Django ^ not a vulnerability).

I agree it is Apache's decision however, I can just ask them to pay attention to threat model and actual vulnerabilities, so let's leave it to them to decide how they want to deal with this. 👋

[nvn1729]

with admin access you can connect to other network components using database connections and sql lab :) And any serious installation would not allow you to connect to other instances unless its really mis-configured.

False again. Have you ever actually attempted to exploit database connections/SQL to make arbitrary network connections and get data back? It's not really possible. RCE enables much more.

There would have been no exploitation here with all these flaws if a superset instances is configured as it should be i.e. using a secure secret key.

This attitude is a problem. Passing onto users the burden of what should handled by an application designed to be secure by default. Django is a framework but Superset is a web app. Users of this web app shouldn't have to worry about setting up SECRET_KEYs when they can be generated randomly.

[vin01]

FTR: Apache security team has updated the description and NVD has updated the CRITICAL 9.8 CVSS score down to 6.6

The Superset metadata db is an 'internal' component that is typically only accessible directly by the system administrator and the superset process itself. Gaining access to that database should be difficult and require significant privileges.

Change history from NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-37941#VulnChangeHistorySection

[nvn1729]

It is typically an internal component but in prior versions of Superset there was other vulnerabilities that led to exposing access to that internal component from the webapp. Apache just chose to split an admin RCE chain into two CVEs instead of filing it as one. That's what I explained above.

So it looks like the CVE is NOT bogus?

[vin01]

Oh it is very much bogus just like the default insecure session key which no serious setup would use. It would have been rejected at initial triage if it would have been reported via a typical bug bounty program @ H1, Bugcrowd etc. ;) but yeah there is no signal, points loss for bogus CVEs yet, I wish there were.