TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Using Rust Macros to exfiltrate secrets

122 点作者 superjared大约 4 年前

15 条评论

the_duke大约 4 年前
Proc macros can run arbitrary code, so this POC is not that interesting - apart from raising awareness for the problem.<p>This can be done even easier without users having to use a macro: with `build.rs` build scripts, which are run by default. So all you&#x27;d need is to compromise some popular dependency with a custom build.rs<p>Many other languages have the same (or at least similar) problem (Makefiles, npm hooks, ...)<p>There is an interesting proposal and prototype for compiling proc macros to WASM so they can be run in a sandbox: <a href="https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;watt" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dtolnay&#x2F;watt</a><p>But in the end it doesn&#x27;t make that much difference: nothing prevents a random library from just reading your secrets and calling curl to send it to a server at runtime.<p>Build time execution is definitely an additional attack vector.<p>But if you use a third party dependency, you have to trust it or review all it&#x27;s code for every version. There is no way around this, and it&#x27;s true for any language.
评论 #27155985 未加载
评论 #27156414 未加载
评论 #27157256 未加载
评论 #27155616 未加载
terseus大约 4 年前
I can&#x27;t believe that people is comparing opening a project in a code editor with running a build script.<p>The PoC doesn&#x27;t even open a file, it just opens the directory. It&#x27;s a pretty big difference, when you execute a build script you _expect_ to run code, when you open a directory in your editor you don&#x27;t expect any side effect _at all_.<p>My guess is that since the proc_macros returns a TokenStream, rust-analyzer have no way to know what it provides except running it.<p>I&#x27;m not sure there&#x27;s a solution for this that doesn&#x27;t cripple macros in Rust, apart from being able to configure rust-analyzer to ignore the macros, which clearly limit its usefulness.
评论 #27168156 未加载
评论 #27157298 未加载
评论 #27156981 未加载
评论 #27159322 未加载
评论 #27157078 未加载
评论 #27156628 未加载
kam大约 4 年前
This is why VSCode is adding Workspace Trust to prevent extensions from running untrusted code by merely opening a directory. <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;issues&#x2F;120251#issuecomment-825832603" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;issues&#x2F;120251#issuecomme...</a>
ngalstyan4大约 4 年前
The more general problem with trusting software supply chains is well described in Ken Thompson&#x27;s Turing award lecture on &quot;Trusting Trust&quot;[1]<p>[1]: <a href="http:&#x2F;&#x2F;users.ece.cmu.edu&#x2F;~ganger&#x2F;712.fall02&#x2F;papers&#x2F;p761-thompson.pdf" rel="nofollow">http:&#x2F;&#x2F;users.ece.cmu.edu&#x2F;~ganger&#x2F;712.fall02&#x2F;papers&#x2F;p761-thom...</a>
Jaygles大约 4 年前
This is a huge deal right? VSCode has to be one of the most popular editors and the standard way of setting up the Rust toolchain on a machine would get you in a state that makes you vulnerable to this.
评论 #27155859 未加载
评论 #27155673 未加载
评论 #27157058 未加载
vlovich123大约 4 年前
Is there a reason that access to the filesystem isn&#x27;t sandboxed aggressively by the compiler? Even having build macros that can access arbitrary parts of the filesystem (vs a dedicated scratch directory) seems like a bad idea. Is there any legitimate use-case here?
评论 #27161231 未加载
mike-cardwell大约 4 年前
This doesn&#x27;t affect me because I <a href="https:&#x2F;&#x2F;www.grepular.com&#x2F;Sandbox_Rust_Development_with_Rust_Analyzer" rel="nofollow">https:&#x2F;&#x2F;www.grepular.com&#x2F;Sandbox_Rust_Development_with_Rust_...</a>
greenshackle2大约 4 年前
You can also just put arbitrary code in build.rs, it will be run by cargo check, rust-analyzer, etc. Though I admit macro expansion hacks are more fun and easier to hide.
duped大约 4 年前
For what it&#x27;s worth, any VSCode extension that integrates with language tooling could be used to implement this.
评论 #27157060 未加载
not2b大约 4 年前
This issue is very similar to the problem of malicious macros in Microsoft Office documents, and I think it needs to be addressed somehow (by figuring out a proper security model and asking for user confirmation for actions outside this model).
juancampa大约 4 年前
Are there any working groups or teams in the rust foundation[0] looking into stuff like this? I know every package manager has these issues but there&#x27;s no technical reason preventing us from building sandboxes (i.e. WASM, deno, ...) for this and making it a first class citizen of cargo&#x2F;rustup&#x2F;etc.<p>Just installing a relatively popular crate (say Hyper) makes you realize that all of your secret could have been stolen by any of the myriad of dependencies.<p>[0] <a href="https:&#x2F;&#x2F;www.rust-lang.org&#x2F;governance" rel="nofollow">https:&#x2F;&#x2F;www.rust-lang.org&#x2F;governance</a>
评论 #27161251 未加载
rhooke大约 4 年前
A lot of the work I do recently has been using devcontainers in VSCode [1]. They even have a Rust sample one. I feel like this would provide at least a little bit of protection against this kind of attack if you do not mount any imporant stuff into the container.<p>I can&#x27;t see a robust solution to this, though.<p>[1] <a href="https:&#x2F;&#x2F;code.visualstudio.com&#x2F;docs&#x2F;remote&#x2F;containers" rel="nofollow">https:&#x2F;&#x2F;code.visualstudio.com&#x2F;docs&#x2F;remote&#x2F;containers</a>
akkartik大约 4 年前
Has something like this ever been possible with Common Lisp and say Emacs?
cryptonector大约 4 年前
Meh. You could do this in C also. Nothing new here.
yannoninator大约 4 年前
Blocks of text again... TL;DR?
评论 #27156929 未加载
评论 #27156861 未加载