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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Why the OpenSSL punycode vulnerability was not detected by fuzz testing (2022)

112 点作者 lemper大约 1 年前

5 条评论

cjbprime大约 1 年前
I&#x27;m not sure the post (from 2022) is&#x2F;was correct. I&#x27;ve looked into it too, and I expect this <i>was</i> reachable by the existing x509 fuzzer. There&#x27;s a fallacy in assuming that a fuzzer will solve for all reachable code paths in a reasonable time, and that if it doesn&#x27;t then there must be a problem with the harness. The harness is a reasonable top-level x509 parsing harness, but starting all the way from the network input makes solving those deep constraints unlikely to happen by (feedback-driven) chance, which is what I think happened here.<p>Of course, a harness that started from the punycode parsing -- instead of the top-level X509 parsing -- finds this vulnerability immediately.
评论 #40078622 未加载
评论 #40079943 未加载
评论 #40080731 未加载
arp242大约 1 年前
(2022)<p>Previous:<p><i>Why CVE-2022-3602 was not detected by fuzz testing</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33693873">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33693873</a> - Nov 2022 (171 comments)
评论 #40078375 未加载
_flux大约 1 年前
I suppose it would be nice to require at least 100% line coverage for tested encryption-related functionality, when tested by a fuzzer. Deviations from this could be easily detected in CI.<p>Testing cannot be used to prove that a flaw doesn&#x27;t exist, only that it does.
评论 #40077965 未加载
评论 #40077319 未加载
评论 #40081495 未加载
stcredzero大约 1 年前
Would it be possible to attach an LLM to a debugger sessions executing all of the fuzzer seeds, and ask it to figure out how to expand coverage?
评论 #40077356 未加载
TacticalCoder大约 1 年前
Why is OpenSSL using punycode? To do internationalized domain name parsing?
评论 #40077244 未加载
评论 #40077384 未加载