Bug Description
In the Community Edition build, the SM4 cryptographic routines are stubbed out using a memcpy operation, but the system processes the functions with a silent success status (Query OK). This creates a critical logical flaw and a false sense of security, as users are led to believe their data is encrypted when it is actually processed and stored as raw plaintext.
To Reproduce
Steps to reproduce the behavior:
- Open the interactive client terminal by running
./taos.
- Select or use any database context (
USE test_vuln;).
- Execute the SM4 encryption query followed by the AES encryption query to see the plaintext leak vs expected behavior:
taos> SELECT SM4_ENCRYPT('HelloGhost12345', 'my_sm4_key_16_ch') FROM secure_data;
sm4_encrypt('HelloGhost12345', 'my_sm4_key_16_ch') |
=====================================================
HelloGhost12345 |
Query OK, 1 row(s) in set (0.066803s)
taos> SELECT AES_ENCRYPT('HelloGhost12345', 'my_aes_key_16_ch') FROM secure_data;
aes_encrypt('HelloGhost12345', 'my_aes_key_16_ch') |
=====================================================
|
Query OK, 1 row(s) in set (0.011350s)
- Notice that the SM4 output returns the raw, unencrypted plaintext string
HelloGhost12345 while Query OK is advertised.
Expected Behavior
If the SM4 algorithm is restricted or unimplemented in the Community Edition, the engine should explicitly fail and throw a proper error code (e.g., Function not supported in this edition) instead of failing open, silently copying plaintext, and misleading the operator.
Environment:
- OS: Debian
- TDengine Version: 3.4.1.6
Additional Context
The root cause lies in source/libs/crypt/src/crypt.c. When TD_ENTERPRISE is not defined, the core routines fall back to Builtin_CBC_EncryptImpl, which performs a direct data copy:
int32_t Builtin_CBC_EncryptImpl(SCryptOpts *opts) {
memcpy(opts->result, opts->source, opts->len);
return opts->len;
}
While commercial gating is understandable, performing a silent memcpy without a runtime warning propagates unencrypted data into architectural call sites (like WAL logs and local configurations) while advertising them as secure.
Bug Description
In the Community Edition build, the SM4 cryptographic routines are stubbed out using a
memcpyoperation, but the system processes the functions with a silent success status (Query OK). This creates a critical logical flaw and a false sense of security, as users are led to believe their data is encrypted when it is actually processed and stored as raw plaintext.To Reproduce
Steps to reproduce the behavior:
./taos.USE test_vuln;).HelloGhost12345whileQuery OKis advertised.Expected Behavior
If the SM4 algorithm is restricted or unimplemented in the Community Edition, the engine should explicitly fail and throw a proper error code (e.g.,
Function not supported in this edition) instead of failing open, silently copying plaintext, and misleading the operator.Environment:
Additional Context
The root cause lies in
source/libs/crypt/src/crypt.c. WhenTD_ENTERPRISEis not defined, the core routines fall back toBuiltin_CBC_EncryptImpl, which performs a direct data copy:While commercial gating is understandable, performing a silent
memcpywithout a runtime warning propagates unencrypted data into architectural call sites (like WAL logs and local configurations) while advertising them as secure.