[druid-user] Re: Subject: [CVE-2021-26919] Authenticated users can execute arbitrary code from malicious MySQL database systems

I wanted to add a few more details about this advisory, in the hopes that it will be helpful to people that are upgrading.

Here’s a link to the relevant docs about the new properties: https://druid.apache.org/docs/latest/configuration/index.html#ingestion-security-configuration

And the most secure setup for these properties is:

druid.access.jdbc.enforceAllowedProperties = true
druid.access.jdbc.allowUnknownJdbcUrlFormat = false

If you aren’t reading any data from JDBC into Druid, you should add both of these to your common.runtime.properties. If you are reading data from JDBC, then you need to understand a little bit about how the properties work to get a secure setup that won’t break your JDBC workflow.

The first property enforces jdbc property validation for mysql and postgresql. This is enough to block the MySQL-based attack mentioned in this CVE. That’s because the attack relies on setting a specific property a specific way, which will be blocked by the validation. To set this without breaking your workflow, make sure that any properties you use in JDBC urls are added to the cluster-wide druid.access.jdbc.allowedProperties whitelist.

The second property disables connections to other kinds of databases, where we don’t have code to validate properties. (Each driver’s URL format is unfortunately a bit different, so Druid can’t understand what properties are in use for arbitrary JDBC drivers.) This doesn’t prevent any known attacks, because the only one we know of specifically exploits the MySQL driver. The purpose of this setting is to prevent any similar and currently-unknown attacks that may involve other jdbc drivers. We provide this option in case you are feeling paranoid.

Setting these properties may impact legitimate use cases. For example, legitimate use cases would be impacted if you were using mysql or postgresql properties that aren’t on the default allow list, or if you were using jdbc connections to database types other than mysql and postgresql. We didn’t want to break these things by surprise in a patch release, so the most secure setup isn’t enabled by default. In a future major version we’ll switch the defaults to the more secure ones.