# 深入剖析 LaTeXpOsEd：你的 .tex 源文件可能正在泄露敏感信息 > 分析 LaTeX 编译过程中的信息泄露风险，特别是通过日志、辅助文件及恶意宏命令。探讨在 arXiv 等平台上，这些漏洞如何泄露本地路径、操作系统信息，并提供针对作者和平台的缓解策略。 ## 元数据 - 路径: /posts/2025/10/13/latexposed-analyzing-information-leakage-from-tex-source-files/ - 发布时间: 2025-10-13T18:18:55+08:00 - 分类: [ai-security](/categories/ai-security/) - 站点: https://blog.hotdry.top ## 正文 在学术界和技术写作领域，LaTeX 长期以来被誉为排版高质量文档的黄金标准。我们通常认为它是一个安全的、确定性的系统：输入纯文本的 `.tex` 文件，输出格式精美的 PDF。然而，近期一项名为“LaTeXpOsEd”的研究揭示了这一普遍看法的潜在误区。研究表明，LaTeX 的编译过程远非简单的文本转换，其背后是一个图灵完备的宏语言环境，这为信息泄露和恶意攻击打开了意想不到的窗口，尤其是在 arXiv 这类接收并编译源代码的预印本平台上。 ### LaTeX 的双重身份：排版工具与编程环境 大多数用户将 LaTeX 视为一种标记语言，类似于 HTML，用于描述文档的结构与样式。但其核心 TeX 语言本质上是一种功能强大的宏处理器。这意味着在编译 `.tex` 文件时，编译器不仅仅是在“渲染”文本，而是在“执行”代码。`\input`、`\def`、` ewwrite` 等命令赋予了 LaTeX 处理文件、定义复杂逻辑甚至与操作系统交互的能力。 这种编程能力是 LaTeX 强大功能的源泉，但也构成了其安全风险的基础。攻击者可以精心构造一个看似无害的 `.tex` 文件或宏包（`.sty`），在编译时执行非预期的操作。最直接的风险之一便是信息泄露。 ### LaTeXpOsEd 揭示的主要信息泄露途径 研究人员发现，LaTeX 编译生态系统中的多个环节都可能成为敏感信息的泄露源。 1. **日志文件 (`.log`)**：每次 LaTeX 编译都会生成一个详细的日志文件。这个文件通常包含了完整的编译上下文，其中最常见也最危险的就是**本地文件的绝对路径**。例如，当你在文档中包含一张图片时，日志里可能会记录下类似 `` 的完整路径。如果这份日志文件被无意中分享出去，你的用户名、操作系统和文件结构就随之曝光。 2. **辅助文件 (`.aux`, `.toc`, etc.)**：LaTeX 在多次编译之间通过辅助文件来管理交叉引用、目录和参考文献等。这些文件同样可能缓存包含本地路径的字符串或其他环境信息。 3. **SyncTeX 文件 (`.synctex.gz`)**：为了实现 PDF 阅读器与源代码之间的正向和反向同步，LaTeX 会生成 SyncTeX 文件。这个压缩文件中包含了源文件和输出 PDF 之间详细的映射关系，其中也必然包含源文件的路径信息。 4. **恶意宏命令与文件操作**：LaTeX 的宏命令可以直接操作文件。例如，`\input{/etc/passwd}` 理论上可以读取系统文件并将其内容插入到文档中。虽然现代的 TeX 发行版通常会通过 `openin_any` 和 `shell_escape` 等安全设置来限制这种行为，但在配置不当或被恶意绕过的环境中，风险依然存在。研究就成功演示了如何通过构造特殊的 `.tex` 文件，在某些在线编译服务上读取并泄露服务器上的文件内容。 ### arXiv 平台上的真实风险 arXiv 作为全球最大的预印本服务器，其工作流程恰好与 LaTeXpOsEd 揭示的风险场景完美契合。作者通常不会上传最终的 PDF，而是提交一个包含所有 `.tex` 源文件、图片和 `.bbl` 参考文献文件的 `.tar.gz` 压缩包。arXiv 的服务器会自动解压并编译这份源码，生成最终的公开 PDF。 这个过程带来了双重风险： * **作者信息泄露**：如果作者在打包源码前没有清理编译过程中产生的辅助文件（`.log`, `.aux`, `.synctex.gz`），这些包含了作者本地环境信息的文件就会被一同上传到 arXiv。尽管 arXiv 的处理流程会清理大部分中间文件，但研究指出，某些信息仍有可能在处理不当的情况下残留在可被访问的元数据或日志中，对作者的隐私构成威胁。 * **平台安全探测**：更严重的是，恶意行为者可以向 arXiv 提交精心设计的“探测性”论文。这些论文的源码可能包含试图读取系统信息（如环境变量、内核版本）或探测网络配置的宏命令。通过观察编译是否成功、报错信息或利用某些高级技巧进行数据外渗（Data Exfiltration），攻击者可以逐步了解 arXiv 编译环境的内部架构，寻找潜在的安全漏洞。 ### 如何防范：给作者和平台的建议 面对这些潜在风险，作者和平台方都需要采取行动来加固安全防线。 **对于作者：** 1. **保持源码清洁**：在提交给 arXiv 或任何其他平台之前，务必清理你的项目目录。最简单的方法是删除所有非必需的文件，只保留 `.tex`、`.bib`、`.sty` 和图片等核心源文件。可以编写一个简单的清理脚本来自动删除 `.log`, `.aux`, `.out`, `.bbl`, `.blg`, `.synctex.gz` 等文件。 2. **谨慎使用未知宏包和模板**：只从 CTAN (Comprehensive TeX Archive Network) 等官方或可信来源获取 LaTeX 宏包和期刊模板。对于来路不明的 `.sty` 文件，除非你能审查其代码，否则应避免使用。 3. **使用相对路径**：在文档中引用图片或其他文件时，始终使用相对路径 (`figures/my_image.png`)，而非绝对路径。这不仅是良好的项目管理习惯，也能避免泄露你的本地文件结构。 **对于平台（如 arXiv）：** 1. **强化编译沙箱**：必须在高度隔离的沙箱环境（例如使用 Docker 容器）中执行 LaTeX 编译。该环境应拥有最小化的文件系统和权限，并严格限制网络访问。 2. **禁用危险命令**：应在 TeX 引擎层面强制禁用 `shell_escape`（除非绝对必要且经过严格审查）以及其他可能导致任意文件读写的危险原语。对允许的文件操作施加严格的路径白名单限制。 3. **彻底的输出清理**：在生成最终的 PDF 后，平台应确保所有中间文件和日志被彻底、安全地删除。此外，应对公开的 PDF 元数据进行扫描和清理，剔除可能由编译过程意外注入的敏感信息。 4. **异常行为监控**：对提交的源码进行静态分析，检测是否包含可疑的命令序列。同时，监控编译过程中的异常行为，如非预期的文件访问尝试或进程创建，并对此类事件进行报警和调查。 ### 结论 LaTeX 的强大和灵活是其备受青睐的原因，但这种能力也伴随着不可忽视的安全责任。LaTeXpOsEd 的研究为我们敲响了警钟：即使是看似最传统的学术工作流，在现代网络环境中也需要重新审视其安全性。对于每一位使用 LaTeX 的研究者而言，养成安全的写作和提交习惯至关重要。对于 arXiv 这样的关键学术基础设施，持续加固其编译和处理流程，则是保护整个社区免受潜在威胁的根本保障。 ## 同分类近期文章 ### [诊断 Gemini Antigravity 安全禁令并工程恢复：会话重置、上下文裁剪与 API 头旋转](/posts/2026/03/01/diagnosing-gemini-antigravity-bans-reinstatement/) - 日期: 2026-03-01T04:47:32+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 剖析 Antigravity 禁令触发机制，提供 session reset、context pruning 和 header rotation 等工程策略，确保可靠访问 Gemini 高级模型。 ### [Anthropic 订阅认证禁用第三方工具：工程化迁移与 API Key 管理最佳实践](/posts/2026/02/19/anthropic-subscription-auth-restriction-migration-guide/) - 日期: 2026-02-19T13:32:38+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 解析 Anthropic 2026 年初针对订阅认证的第三方使用限制，提供工程化的 API Key 迁移方案与凭证管理最佳实践。 ### [Copilot邮件摘要漏洞分析：LLM应用中的数据流隔离缺陷与防护机制](/posts/2026/02/18/copilot-email-dlp-bypass-vulnerability-analysis/) - 日期: 2026-02-18T22:16:53+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 深度剖析Microsoft 365 Copilot因代码缺陷导致机密邮件被错误摘要的事件，揭示LLM应用数据流隔离的工程化防护要点。 ### [用 Rust 与 WASM 沙箱隔离 AI 工具链：三层控制与工程参数](/posts/2026/02/14/rust-wasm-sandbox-ai-tool-isolation/) - 日期: 2026-02-14T02:46:01+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 探讨基于 Rust 与 WebAssembly 构建安全沙箱运行时，实现对 AI 工具链的内存、CPU 和系统调用三层细粒度隔离，并提供可落地的配置参数与监控清单。 ### [为AI编码代理构建运行时权限控制沙箱：从能力分离到内核隔离](/posts/2026/02/10/building-runtime-permission-sandbox-for-ai-coding-agents-from-capability-separation-to-kernel-isolation/) - 日期: 2026-02-10T21:16:00+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 本文探讨如何为Claude Code等AI编码代理实现运行时权限控制沙箱，结合Pipelock的能力分离架构与Linux内核的命名空间、seccomp、cgroups隔离技术，提供可落地的配置参数与监控方案。