What is the Vulnerability?
The core issue is that one of our supported data warehouses (an embedded in-memory database H2), exposes a number of ways for a connection string to include code that is then executed by the process running the embedded database. Because we allow users to connect to databases, this means that a user supplied string can be used to inject executable code.
We allow users to validate their connection string before adding a database (including on setup), and this validation API was the primary vector used as it can be called without validation.
We had previously sanitized user input to remove the init command which allowed code execution. In a string of one week, we were informed of three successive vulnerabilities related to the H2 connection string handling by independent security researchers of how to effect this. We fixed each of these in turn.
Impact
The vulnerability could potentially allow remote code execution on your Metabase server.
Patches
We previously notified our users of the original vulnerability, but two subsequent attack vectors were discovered after we patched the original one. We subsequently patched each of the found vulnerabilities.
Due to the variety of these attacks and the lack of usage of this database driver, we are removing the ability of users to add H2 databases entirely. We believe that continuing to apply user input sanitation bandaids on top of an insecure core problem is irresponsible and are removing this functionality from our application.
If you have an existing connection to an H2 database, you'll still be able to connect to that database. But we strongly encourage you to migrate your data from H2 to another database.
v0.46.6.4
Docker image: metabase/metabase:v0.46.6.4
Download the JAR here : https://downloads.metabase.com/v0.46.6.4/metabase.jar
v1.46.6.4
Docker image: metabase/metabase-enterprise:v1.46.6.4
Download the JAR here: https://downloads.metabase.com/enterprise/v1.46.6.4/metabase.jar
v0.45.4.3
Docker image: metabase/metabase:v0.45.4.3
Download the JAR here: https://downloads.metabase.com/v0.45.4.3/metabase.jar
v1.45.4.3
Docker image: metabase/metabase-enterprise:v1.45.4.3
Download the JAR here: https://downloads.metabase.com/enterprise/v1.45.4.3/metabase.jar
v0.44.7.3
Docker image: metabase/metabase:v0.44.7.3
Download the JAR here: https://downloads.metabase.com/v0.44.7.3/metabase.jar
v1.44.7.3
Docker image: metabase/metabase-enterprise:v1.44.7.3
Download the JAR here: https://downloads.metabase.com/enterprise/v1.44.7.3/metabase.jar
v0.43.7.3
Docker image: metabase/metabase:v0.43.7.3
Download the JAR here: https://downloads.metabase.com/v0.43.7.3/metabase.jar
v1.43.7.3
Docker image: metabase/metabase-enterprise:v1.43.7.3
Download the JAR here: https://downloads.metabase.com/enterprise/v1.43.7.3/metabase.jar
Workarounds
If for some reason you cannot upgrade immediately, you can block these vulnerabilities at the network level by blocking the following endpoints until you are able to upgrade.
POST /api/database
PUT /api/database/:id
POST /api/setup/validate
Note that blocking these endpoints will prevent people from adding new database connections to Metabase.
Note also that these are PUT and POST endpoints. You should still allow GET requests to these endpoints. The GET requests aren’t relevant to the vulnerability, and Metabase will stop working if you block them.
If you are using H2 as a file-based database, we recommend you migrate to SQLite.
How to know if you have been exploited
Search in your logs (Metabase logs or load balancer/reverse-proxy logs) for any API call to /api/setup/validate that returned a status code of 400. That endpoint should be called only once in the lifetime of your Metabase instance, so there shouldn't be any other calls after that. If you see that the endpoint has been called at any other time, you should consider that you have been exploited and you need to take action immediately.
References
Credits:
Shubham Shah - Assetnote, Maxwell Garrett, for discovering the initial vulnerability
Chaitin Security Response Institute and independent security researcher bluE0, for reporting a separate attack vector
Reginaldo Silva, for another, and different, attack vector
Duc Nguyen and Jang Nguyen from the Calif.io team, for another attack vector
What is the Vulnerability?
The core issue is that one of our supported data warehouses (an embedded in-memory database H2), exposes a number of ways for a connection string to include code that is then executed by the process running the embedded database. Because we allow users to connect to databases, this means that a user supplied string can be used to inject executable code.
We allow users to validate their connection string before adding a database (including on setup), and this validation API was the primary vector used as it can be called without validation.
We had previously sanitized user input to remove the
initcommand which allowed code execution. In a string of one week, we were informed of three successive vulnerabilities related to the H2 connection string handling by independent security researchers of how to effect this. We fixed each of these in turn.Impact
The vulnerability could potentially allow remote code execution on your Metabase server.
Patches
We previously notified our users of the original vulnerability, but two subsequent attack vectors were discovered after we patched the original one. We subsequently patched each of the found vulnerabilities.
Due to the variety of these attacks and the lack of usage of this database driver, we are removing the ability of users to add H2 databases entirely. We believe that continuing to apply user input sanitation bandaids on top of an insecure core problem is irresponsible and are removing this functionality from our application.
If you have an existing connection to an H2 database, you'll still be able to connect to that database. But we strongly encourage you to migrate your data from H2 to another database.
v0.46.6.4
Docker image: metabase/metabase:v0.46.6.4
Download the JAR here : https://downloads.metabase.com/v0.46.6.4/metabase.jar
v1.46.6.4
Docker image: metabase/metabase-enterprise:v1.46.6.4
Download the JAR here: https://downloads.metabase.com/enterprise/v1.46.6.4/metabase.jar
v0.45.4.3
Docker image: metabase/metabase:v0.45.4.3
Download the JAR here: https://downloads.metabase.com/v0.45.4.3/metabase.jar
v1.45.4.3
Docker image: metabase/metabase-enterprise:v1.45.4.3
Download the JAR here: https://downloads.metabase.com/enterprise/v1.45.4.3/metabase.jar
v0.44.7.3
Docker image: metabase/metabase:v0.44.7.3
Download the JAR here: https://downloads.metabase.com/v0.44.7.3/metabase.jar
v1.44.7.3
Docker image: metabase/metabase-enterprise:v1.44.7.3
Download the JAR here: https://downloads.metabase.com/enterprise/v1.44.7.3/metabase.jar
v0.43.7.3
Docker image: metabase/metabase:v0.43.7.3
Download the JAR here: https://downloads.metabase.com/v0.43.7.3/metabase.jar
v1.43.7.3
Docker image: metabase/metabase-enterprise:v1.43.7.3
Download the JAR here: https://downloads.metabase.com/enterprise/v1.43.7.3/metabase.jar
Workarounds
If for some reason you cannot upgrade immediately, you can block these vulnerabilities at the network level by blocking the following endpoints until you are able to upgrade.
POST /api/databasePUT /api/database/:idPOST /api/setup/validateNote that blocking these endpoints will prevent people from adding new database connections to Metabase.
Note also that these are
PUTandPOSTendpoints. You should still allowGETrequests to these endpoints. TheGETrequests aren’t relevant to the vulnerability, and Metabase will stop working if you block them.If you are using H2 as a file-based database, we recommend you migrate to SQLite.
How to know if you have been exploited
Search in your logs (Metabase logs or load balancer/reverse-proxy logs) for any API call to /api/setup/validate that returned a status code of 400. That endpoint should be called only once in the lifetime of your Metabase instance, so there shouldn't be any other calls after that. If you see that the endpoint has been called at any other time, you should consider that you have been exploited and you need to take action immediately.
References
Credits:
Shubham Shah - Assetnote, Maxwell Garrett, for discovering the initial vulnerability
Chaitin Security Response Institute and independent security researcher bluE0, for reporting a separate attack vector
Reginaldo Silva, for another, and different, attack vector
Duc Nguyen and Jang Nguyen from the Calif.io team, for another attack vector