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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Sudo-rs' first security audit

62 点作者 Argorak超过 1 年前

5 条评论

comex超过 1 年前
&gt; Description: The cargo release build does not strip symbols, so they will be included in the final binary. (..) Impact: Since the code is open source, there is not much information to be gained, but removing these symbols might make reverse engineering of the binary harder.<p>What a ridiculous finding.<p>I can try to steelman the argument. Sure, maybe &quot;reverse engineering of the binary&quot; is useless most of the time for an open source project because you can just look at the source code. But if there were hypothetically a memory corruption vulnerability in sudo-rs, then an attacker <i>would</i> want to identify the specific machine code corresponding to the vulnerable source, in order to determine how it could be exploited. That wouldn&#x27;t be too hard to achieve without symbols, but symbols would definitely make it easier.<p>Except… even if the binary has symbols stripped, you can just `apt install sudo-rs-dbgsym`, or use debuginfod, to get the full debug info including symbols and DWARF records. Because distros provide that for all their packages. As a feature. To assist debugging.<p>Even if distros didn&#x27;t distribute debug symbols, today&#x27;s security best practices include reproducible builds, which means you should be able to rebuild the package yourself and get the exact same binary, plus the symbols.<p>So while it might save a tiny bit of disk space to strip the symbols, the security benefit is absolutely nil.<p>…Well, in theory anyway. In practice, Debian&#x27;s sudo-rs package seems to be missing both a dbgsym package and reproducible build info. But that&#x27;s a bug!
评论 #38135887 未加载
评论 #38136360 未加载
评论 #38136198 未加载
评论 #38136205 未加载
评论 #38135970 未加载
评论 #38136316 未加载
aliceryhl超过 1 年前
I&#x27;m surprised that CLN-003 made the list even as low severity. It&#x27;s intended to make reverse engineering of the binary harder, but the code is already freely accessible (and CLN-003 also acknowledges this).
评论 #38136439 未加载
评论 #38139550 未加载
g-b-r超过 1 年前
The arbitrary delete vulnerability scared me at first, but are there really situations where a non-root user can create a new user??
评论 #38141265 未加载
cedws超过 1 年前
I just ran tokei in the sudo-rs repository and there&#x27;s over 28,000 lines of code not including whitespace. The Rust rewrite is a good step forward but we should really be asking ourselves if we need all this complexity in something so critical.<p>OpenBSD&#x27;s doas is 108 lines of C. sudo and doas are not equivalent in functionality, but it shows how simple things can really be.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;openbsd&#x2F;src&#x2F;blob&#x2F;master&#x2F;distrib&#x2F;special&#x2F;doas&#x2F;doas.c">https:&#x2F;&#x2F;github.com&#x2F;openbsd&#x2F;src&#x2F;blob&#x2F;master&#x2F;distrib&#x2F;special&#x2F;d...</a>
评论 #38135269 未加载
评论 #38135414 未加载
评论 #38135411 未加载
评论 #38135775 未加载
评论 #38136035 未加载
评论 #38136313 未加载
0xbadcafebee超过 1 年前
<p><pre><code> CLN-001: relative path traversal vulnerability (moderate) During the audit, it came to light that the original sudo implementation was also affected by this issue, although with a lower security severity due to their use of the openat function. </code></pre> I thought Rust was secure? How is it possible to write a program in Rust and still have the same security vulnerabilities, and actually be higher severity?<p>It&#x27;s almost as if changing to an entirely new programming language and ecosystem isn&#x27;t enough to make a secure application, and that you still have to try hard to secure it, regardless of the language.<p>How interesting.
评论 #38136389 未加载
评论 #38136284 未加载
评论 #38136390 未加载
评论 #38136318 未加载