Reverse Engineering TencentOS

758 findings from static analysis of TencentOS Server 2.4 through 4.6, OpenCloudOS, and proprietary components

Overview • Findings • CVEs • Coverage • Tooling • Method • Query • Report

---

What is TencentOS

TencentOS Server (TOS) is the Linux distribution Tencent maintains for Tencent Cloud CVM instances. It ships its own kernel fork (the tl4 / tk4 / tlinux series), proprietary kernel modules (shellguard LSM, kill-protect, irqlatency, DIM), a mandatory security agent (Aegis HIDS), and a cloud automation agent (TAT). These components are not open source and not publicly documented. Standard tools give you the OS surface; this repo covers what's underneath.

---

Notable findings

Kernel

KASLR disabled across TOS 2.4 through 4.2 (tencent_kernel_cross_version.py) CONFIG_RANDOMIZE_BASE is not set in any kernel from 5.4.119-19 (TOS 2.4) through 6.6.70-24 (TOS 4.2, December 2024). Kernel text is fixed at 0xffffffff81000000. KASLR was not enabled until kernel 6.6.119-51.3 (TOS 4.6, July 2026). Every exploit that requires a kernel address to be fixed - ROP chains, ret2text, function pointer overwrites - worked without bypass across five years and multiple major releases. The disablement is a deliberate config decision, not a build oversight.

shellguard LSM uses MD5 for binary integrity (tencent_tos46_kernel_shellguard_re.py) TOS 4.6 ships a proprietary LSM (shellguard.ko) that checks binary integrity in bprm_check_security. It hashes binaries with MD5. MD5 is collision-broken (Flame, 2012) and non-cryptographic for this use case. The LSM is enabled by default; its whitelist is mutable by root.

ptrace_pre_hook: writable function pointer at fixed VA (tencent_tos46_kill_hooks_re.py, tencent_tos46_kill_protect_re.py) The kill-protect and kill-hooks kernel modules export a function pointer (ptrace_pre_hook) at a static virtual address (KASLR disabled). A kernel write primitive - from any of the unmitigated CVEs catalogued here - can overwrite it to redirect ptrace control flow.

kill-protect bypass via prctl(PR_SET_NAME) (tencent_tos46_kill_protect_re.py) The kill-protect module gates signals on the process's comm string. prctl(PR_SET_NAME) writes comm from userspace with no privilege check. A process can impersonate a protected process's name and send it signals freely.

Same-cgroup bypass (tencent_tos46_kill_protect_re.py) Processes in the same top-level cgroup bypass kill-protection signal filtering entirely.

Agents

TAT agent: hardcoded DSA key pair (tencent_tos46_tagent_re.py, tencent_tos46_tagent_push_re.py) The TAT cloud automation agent has two DSA signatures burned into the binary: (agent, 126) and (agent, 134). These are used to authenticate push commands. Anyone with the private half can issue authenticated commands to any TOS instance where TAT is running.

TAT agent: push payload not signed (tencent_tos46_tagent_push_re.py) The DSA signature covers the channel address, not the payload content. A push recipient accepts any payload from an authenticated sender regardless of payload integrity.

TAT agent: popen() with unsanitized data (tencent_tos46_tagent_re.py) A popen() call passes a data argument that flows from the push channel without shell escaping. If attacker-controlled data reaches this call, it's arbitrary command execution.

TAT agent: SysV IPC shared memory - any local process can write the push channel (tencent_tos46_tagent_push_re.py) The push channel uses SysV shared memory with no per-process authentication. Any process on the host can write to it.

Stargate: polls update server over plaintext HTTP with verify=False (tencent_stargate_re.py) Stargate (Tencent's telemetry/monitoring agent) contacts its update server over HTTP, not HTTPS, and disables TLS verification. Update responses are not signed. This is a network-adjacent code execution path on any TOS host where Stargate is running.

Aegis HIDS: libcurl 7.38.0 (2014) loaded by a SYSTEM-equivalent service (tencent_tos46_aegis_hids_re.py, tencent_tos42_aegis_re.py) Aegis bundles its own libcurl.dll (7.38.0, released 2014) and loads it in a privileged context. Over 100 CVEs accumulated against libcurl 7.38.0 before EOL, including SSRF, memory corruption, and credential exposure.

Cryptography

Kona JDK: CVE-2022-21449 Psychic Signatures (tencent_kona_jdk_re.py) All TOS 2.4 Kona JDK 8 releases (8u282, 8u292, 8u322) predate the April 2022 fix for CVE-2022-21449. ECDSA signature validation in these releases accepts r=0, s=0 as a valid signature for any message. Any JWT, TLS certificate, or signed artifact verified by these JDK releases can be forged.

compat-openssl10 1.0.2o shipped in production images (tencent_tos46_compat_openssl10_re.py, tencent_tos31_appstream_compat_openssl10_re.py) OpenSSL 1.0.x reached EOL in December 2019. TOS 4.6 (2025) and TOS 3.1 still ship compat-openssl10-1.0.2o as an AppStream package. It carries CVE-2022-0778 (infinite loop in BN_mod_sqrt, CVSS 7.5) and three other unpatched CVEs.

SM2/SM3 added to shim's Secure Boot trust chain (tencent_tos46_shim_srpm_re.py) Tencent's shim patches add Chinese national crypto standards (SM2+SM3) as trusted Secure Boot signature algorithms. This extends the trust chain to the CNSA/SM algorithms, which have different security properties and auditability compared to standard UEFI CA chains.

Unpatched CVEs (selected)

Finding	CVE	CVSS	Module
OpenSSH 8.0p1 - PKCS#11 RCE	CVE-2023-38408	9.8	tencent_tos31_binary_re.py
sudo 1.8.29 - Baron Samedit heap overflow	CVE-2021-3156	7.8	tencent_tos31_binary_re.py
polkit 0.115-13 - PwnKit	CVE-2021-4034	7.8	tencent_tos31_binary_re.py
glibc 2.38 - Looney Tunables	CVE-2023-4911	7.8	tencent_os40_components_re.py
expat 2.1.0 / 2.2.5 - integer overflow RCE	CVE-2022-25315	9.8	multiple
GnuTLS 3.6.16 - client/server UAF	CVE-2021-20231/20232	9.8	tencent_tos33_components_re.py
curl 7.61.1 - SOCKS5 heap overflow	CVE-2023-38545	9.8	tencent_tos31_appstream_freeradius_re.py
regreSSHion sshd race	CVE-2024-6387	8.1	tencent_tos46_openssh_srpm_re.py
SSSD GPO path traversal → root LPE	-	-	tencent_tos46_auth_stack_re.py
DHCPv6 CLID heap overflow	-	-	tencent_tos46_auth_stack_re.py

---

Severity summary

Severity	Count
CRITICAL	45
HIGH	261
MEDIUM	225
LOW	28
INFO	197
Total	758

---

Coverage by series

Series	Modules	Findings
TencentOS Server 4.x	96	578
TencentOS Server 3.1	12	47
TencentOS Server 2.4	8	40
TencentOS Server 3.3	8	34
TencentOS Server 3.2	1	4
OpenCloudOS	2	9
Stargate	1	9
OS Components	1	6
CFS Utils	1	5
Kona JDK	1	4
Cross-version kernel	1	4
TAT agent	1	4
netatop	1	3
Other	3	11

---

What was analyzed

• qcow2 disk images: TOS 2.4, 3.1, 3.3, 4.0, 4.2, 4.4, 4.6 GenericCloud images. Mounted via nbd for full filesystem access.
• ISO images: TOS 2.4 and 3.3 installer ISOs. SBOM extracted from packages.
• RPM packages: Binaries extracted from source and binary RPMs where qcow2 images were unavailable (TOS 3.1 openssh, TOS 3.2, some TOS 3.3 packages).
• Kernel analysis: vmlinuz → vmlinux extraction, kernel config from /boot/config-*, System.map for symbol addresses, objdump/nm on stripped binaries.
• Proprietary modules: shellguard.ko, kill_block.ko, kill_hooks.ko, kill_protect.ko, irqlatency.ko, dim_core.ko, dim_monitor.ko - extracted from running kernel module paths and analyzed with capstone.
• Agents: TAT agent (Go binary), Stargate (Python), Aegis HIDS (C++ with bundled libs), sgagent (Windows PE, analyzed from CVM image).
• JDK: Kona JDK 8 releases 8u282/8u292/8u322 from TOS 2.4 TK4 images.

---

Repository structure

tos-2.4/          TencentOS Server 2.4 (8 modules, 40 findings)
tos-3.1/          TencentOS Server 3.1 (12 modules, 47 findings)
tos-3.2/          TencentOS Server 3.2 (1 module, 4 findings)
tos-3.3/          TencentOS Server 3.3 (8 modules, 34 findings)
tos-4.0/          TencentOS Server 4.0 (4 modules, 9 findings)
tos-4.2/          TencentOS Server 4.2 (4 modules, 13 findings)
tos-4.4/          TencentOS Server 4.4 (3 modules, 9 findings)
tos-4.6/          TencentOS Server 4.6 (81 modules, 514 findings)
tos-4x/           TencentOS Server 4.x shared modules (4 modules, 33 findings)
opencloudos/      OpenCloudOS (2 modules, 9 findings)
components/       Standalone components: Kona JDK, Stargate, TAT agent, CFS utils,
                  netatop, libssh, ttools, cross-version kernel (10 modules, 26 findings)

---

Module structure

Each module exports a FINDINGS list. Fields vary by finding type; common fields:

{
    "id":          "TCS4-K01",
    "severity":    "CRITICAL",          # CRITICAL / HIGH / MEDIUM / LOW / INFO
    "title":       "KASLR Disabled ...",
    "detail":      "Full technical detail, evidence, and reproduction ...",
    "cve":         "CVE-2021-4034",     # when applicable
    "status":      "UNPATCHED",         # PATCHED / UNPATCHED / PARTIAL
    "evidence":    "CONFIG_RANDOMIZE_BASE is not set",
    "recommendation": "...",
}

Some modules also export supporting data structures (SUID_INVENTORY, KERNEL_CONFIG, BINARY_ANALYSIS, etc.) alongside FINDINGS.

---

Querying findings

import glob

files = glob.glob('**/*.py', recursive=True)
critical = []

for path in files:
    ns = {}
    exec(open(path).read(), ns)
    for f in ns.get('FINDINGS', []):
        if f.get('severity') == 'CRITICAL':
            critical.append((path, f))

for path, f in critical:
    print(f"[{path}] {f['title']}")

---

Tooling

Binary analysis was done with Ablation - a custom reverse engineering tool built around semantic BERT embeddings. Ablation reads stripped binaries with no symbols, no source, and no debug info. It encodes what each function does using BinFuse opcode normalization (11 categories, architecture-agnostic) + Markov transitions, then runs cosine similarity queries against a vulnerability pattern corpus to surface candidates. It also tracks functions across firmware versions even when addresses, names, and instruction sequences have all changed - which matters here because TencentOS ships entirely stripped binaries and the kernel modules are proprietary with no upstream source.

The RE modules in this repo are Ablation's output format: structured Python dicts with full evidence, binary offsets, and reproduction detail attached to each finding.

---

Method

Static analysis only. No live systems.

1. Mount qcow2 images via nbd or extract RPM packages with rpm2cpio.
2. Enumerate kernel config, SUID binaries, loaded kernel modules, installed package versions.
3. Cross-check package versions against CVE databases and upstream changelogs.
4. Run Ablation semantic sweep against proprietary binaries - shellguard, kill-protect, TAT agent, Aegis, Stargate - to identify vulnerability patterns in stripped code.
5. Confirm patch presence or absence by locating the relevant check in the disassembly.
6. Document the finding with evidence (binary offset, config key, or string) sufficient to reproduce.