Re: RCE Vulnerability in Apache Inlong (incubator)

[healchow <he...@apache.org>]

Dear all,

Apache InLong just fixed the vulnerability of MySQL JDBC URL,
please refer to these PRs:

https://github.com/apache/inlong/pull/5884
https://github.com/apache/inlong/pull/5893
https://github.com/apache/inlong/pull/5896

Those fixes will be released in the next release.
BTW, they also have been synced in the just-released 1.3.0.

Credit: This issue was discovered by 4ra1n.

Best Regards
healchow

On Wed, Sep 7, 2022 at 3:16 PM Apache Security Team <se...@apache.org>
wrote:

> Dear PMC,
>
> The security vulnerability report has been received by the Apache
> Security Team and is being passed to you for action.
>
> Please take careful note of the following:
> - This information is private and should be treated accordingly. The
> issue must not be discussed on a public mailing list, it must not be
> added to a public bug tracker, etc.
> - The PMC is responsible for resolving this issue. The security
> team is here to provide help and advice but the responsibility to do the
> work lies with the PMC.
>
> You may find the "ASF Project Security for Committers" [1] a useful
> reference. This e-mail represents step three of that process. Step 4
> should be completed asap.
>
> Regards,
>
> Arnout Engelen
> [1] http://www.apache.org/security/committers.html
>
> ---------- Forwarded message ---------
> From: Qing Xu <em...@gmail.com>
> Date: Tue, Sep 6, 2022 at 7:07 PM
> Subject: RCE Vulnerability in Apache Inlong (incubator)
> To: Apache Security Team <se...@apache.org>
>
>
> Hi,
>
> There may be potential RCE vulnerability in the Apache Inlong.
> This attack technique is called: JDBC Attack
>
> The key to the issue is whether the jdbc url is completely trusted.
>
> You can refer to:
> (1) https://su18.org/post/jdbc-connection-url-attack/
> (2)
> https://pyn3rd.github.io/2022/06/06/Make-JDBC-Attacks-Brillian-Again-I/
>
> In the case of jdbc url with malicious parameters, deserialization
> vulnerability will be caused. Therefore, the parameters in the jdbc
> url should be blacklisted. For example, autoDeserialize should not be
> added to jdbc url.
>
> I think the repair plan can use blacklist, if there is autoDeserialize
> and other malicious parameters, it should throw exceptions.
>
> You can refer to Apache DolphinScheduler CVE-2020-11974 patch:
>
> https://github.com/apache/dolphinscheduler/blob/dev/dolphinscheduler-datasource-plugin/dolphinscheduler-datasource-mysql/src/main/java/org/apache/dolphinscheduler/plugin/datasource/mysql/param/MySQLDataSourceProcessor.java
>
> From the perspective of MySQL and JDBC, the autoDeserialize parameter
> is a reasonable feature and does not need to be prohibited, although
> it is dangerous.
>
> But from the perspective of Apache Inlong, is this parameter required?
> Maybe not, this is a very rare requirement. From a security
> perspective, it makes sense to disable it.
>
> The key to whether this issue should be fixed lies in:
> Whether the jdbc url source is completely safe. For example, it can
> only be configured in xml/yaml before startup or static code by
> developers.
>
> If there is a dynamic configuration way or an unsafe input source, it
> will be a serious security problem and must be fixed. Assuming that it
> only comes from the static configuration of the developer, it may be
> safe.
>
> However, it seems that there are some ways to dynamically configure
> jdbc url config in Apache Inlong, such as jdbc url can be configured
> on the web page by input form named jdbc url, so it is a
> vulnerability.
>
> Kind Regards
>