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 <[email protected]> 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 <[email protected]> > Date: Tue, Sep 6, 2022 at 7:07 PM > Subject: RCE Vulnerability in Apache Inlong (incubator) > To: Apache Security Team <[email protected]> > > > 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 >
