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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

This shouldn't have happened: A vulnerability postmortem

938 点作者 trulyrandom超过 3 年前

30 条评论

lucb1e超过 3 年前
A title that actually describes the post, mostly paraphrasing the first paragraph:<p><i>Reasons why this buffer overflow wasn&#x27;t caught earlier despite doing all the right things</i><p>And then to give those reasons:<p>- &quot;each component is fuzzed independently&quot; ... &quot;This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could never be discovered.&quot;<p>- &quot;There is an arbitrary limit of 10000 bytes placed on fuzzed input. There is no such limit within NSS; many structures can exceed this size. This vulnerability demonstrates that errors happen at extremes&quot;<p>- &quot;combined [fuzzer] coverage metrics [...]. This data proved misleading, as the vulnerable code is fuzzed extensively but by fuzzers that could not possibly generate a relevant input.&quot;<p>The conclusion is, of course, to fix those problems if your code base also has them, but also &quot;even extremely well-maintained C&#x2F;C++ can have fatal, trivial mistakes&quot;.
评论 #29412387 未加载
评论 #29408618 未加载
评论 #29408278 未加载
评论 #29409344 未加载
评论 #29409140 未加载
mjw1007超过 3 年前
I think the main surprising thing here is that people are putting smallish arbitrary limits on the sizes of inputs that they let their fuzzer generate.<p>With the benefit of a little hindsight, that does feel rather like saying &quot;please try not to find any problems involving overflows&quot;.
评论 #29412351 未加载
Eduard超过 3 年前
How realistic is it that this vulnerability can be exploited for $BAD_THINGS?<p><a href="https:&#x2F;&#x2F;www.mozilla.org&#x2F;en-US&#x2F;security&#x2F;advisories&#x2F;mfsa2021-51&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.mozilla.org&#x2F;en-US&#x2F;security&#x2F;advisories&#x2F;mfsa2021-5...</a> notes &quot;This vulnerability does NOT impact Mozilla Firefox. However, email clients and PDF viewers that use NSS for signature verification, such as Thunderbird, LibreOffice, Evolution and Evince are believed to be impacted.&quot;.
oxfeed65261超过 3 年前
I don’t understand why the “lessons learned” doesn’t recommend always* passing the destination buffer size (using memcpy_s or your own wrapper). It has been a long time since I wrote C++, but when I did this would have been instantly rejected in code review.<p>*…with, I suppose, potential exceptions in performance-critical code when you control and trust the input; I don’t believe that this code qualifies on either count.
评论 #29408714 未加载
评论 #29409380 未加载
评论 #29413507 未加载
oleganza超过 3 年前
Usually people say &quot;oh, it&#x27;s just another typical failure of writing in memory-unsafe C&quot;, but here&#x27;s a slightly different angle: why is this common error is not happening under a single abstraction like &quot;data structure that knows it size&quot;? If C was allowing for such things, then 100000 programs would be using same 5-10 standard structures where the copy-and-overflow bug would be fixed already.<p>Languages like Rust, of course, provide basic memory safety out of the box, but most importantly they also provide means to package unsafe code under safe API and debug it once and for all. And ecosystem of easy to use packages help reusing good code instead of reinventing your own binary buffers every single damn time, as it&#x27;s usually done in C.<p>So maybe it&#x27;s not the unsafeness itself, but rather inability to build powerful reusable abstractions that plagues C? Everyone has to step on the same rake again and again and again.
评论 #29408428 未加载
slownews45超过 3 年前
Wow.<p>We continue to be reminded that it&#x27;s hard to write fully memory secure code in a language that is not memory secure?<p>And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare).<p>My impression is that Apple&#x27;s imessage and other stacks also have memory unsafe languages in the api&#x2F;attack surface, and this has led to remote one click &#x2F; no click type exploits.<p>Is there a point at which someone says, hey, if it&#x27;s very security sensitive write it in a language with a GC (golang?) or something crazy like rust? Or are C&#x2F;C++ benefits just too high to ever give up?<p>And similarly, that simplicity is a benefit (ie, BoringSSL etc has some value).
评论 #29408261 未加载
评论 #29408902 未加载
评论 #29408418 未加载
评论 #29408283 未加载
评论 #29411204 未加载
评论 #29409729 未加载
评论 #29408290 未加载
评论 #29410703 未加载
评论 #29412400 未加载
评论 #29412050 未加载
评论 #29410092 未加载
评论 #29408793 未加载
评论 #29411518 未加载
评论 #29409481 未加载
评论 #29408354 未加载
DantesKite超过 3 年前
This sounds like a very good argument for switching over to Rust.
评论 #29408136 未加载
评论 #29408270 未加载
评论 #29408348 未加载
jmull超过 3 年前
To me, PORT_Memcpy is one problem here.<p>There are two buffers and one size -- the amount of memory to copy.<p>There should be PORT_Memcpy2(pDest, destSize, pSource, numBytesToCopy) (or whatever you want to call it) which at least prompts the programmer to account for the size destination buffer.<p>Then flag all calls to PORT_Memcpy and at least make a dev look at it. (Same for the various similar functions like strcpy, etc.)
评论 #29410234 未加载
评论 #29411991 未加载
yjftsjthsd-h超过 3 年前
Ah; the title means &quot;this shouldn&#x27;t have happened [because the vender was in fact doing everything right]&quot;, not &quot;this shouldn&#x27;t have happened [because it&#x27;s so stupid]&quot;.
评论 #29409348 未加载
评论 #29408411 未加载
albntomat0超过 3 年前
Since this comes up whenever there is a Project Zero article, here is a summary I made in summer 2020 on the distribution of the bugs they find&#x2F;report:<p>Since this always comes up, here&#x27;s an overview I made several weeks ago about where Project Zero focuses their efforts: All counts are rough numbers. Project zero posts:<p>Google: 24<p>Apple: 28<p>Microsoft: 36<p>I was curious, so I poked around the project zero bug tracker to try to find ground truth about their bug reporting: <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;project-zero&#x2F;issues&#x2F;list" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;project-zero&#x2F;issues&#x2F;list</a> For all issues, including closed:<p>product=Android returns 81 results<p>product=iOS returns 58<p>vendor=Apple returns 380<p>vendor=Google returns 145 (bugs in Samsung&#x27;s Android kernel,etc. are tracked separately)<p>vendor=Linux return 54<p>To be fair, a huge number of things make this not an even comparison, including the underlying bug rate, different products and downstream Android vendors being tracked separately. Also, # bugs found != which ones they choose to write about.
评论 #29410805 未加载
评论 #29412447 未加载
评论 #29410419 未加载
JulianMorrison超过 3 年前
Why isn&#x27;t static analysis taint-checking the boundedness of data? Unbounded data should be flagged as unbounded and that flag should propagate through checking until it can be proven to be bounded.
galadran超过 3 年前
The disclosure and test cases: <a href="https:&#x2F;&#x2F;www.openwall.com&#x2F;lists&#x2F;oss-security&#x2F;2021&#x2F;12&#x2F;01&#x2F;4" rel="nofollow">https:&#x2F;&#x2F;www.openwall.com&#x2F;lists&#x2F;oss-security&#x2F;2021&#x2F;12&#x2F;01&#x2F;4</a>
thrdbndndn超过 3 年前
Kinda tangent, but when I was browsing NSS&#x27; repo ( <a href="https:&#x2F;&#x2F;hg.mozilla.org&#x2F;projects&#x2F;nss" rel="nofollow">https:&#x2F;&#x2F;hg.mozilla.org&#x2F;projects&#x2F;nss</a> or mirror: <a href="https:&#x2F;&#x2F;github.com&#x2F;nss-dev&#x2F;nss&#x2F;commits&#x2F;master" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nss-dev&#x2F;nss&#x2F;commits&#x2F;master</a> ) I found that the latest commit has a much older date (7 weeks ago) than the following ones. Why is that? (Sorry I don&#x27;t know much about git other than push&#x2F;pull.)
评论 #29408417 未加载
评论 #29415256 未加载
评论 #29408390 未加载
fulafel超过 3 年前
Good lesson also about how much our security relies on these largish ongoing fuzzing efforts, and makes you think what&#x27;s going on at even larger fuzzing efforts that are less public.
InfiniteRand超过 3 年前
Always place char arrays at the end of a struct - rule of thumb I heard somewhere, maybe from CERT-C<p>That way if you do have memory corruption, the memory following your buffer is less predictable.
aidenn0超过 3 年前
I&#x27;m really curious why static analysis didn&#x27;t catch this. If they weren&#x27;t doing static analysis, I would probably have asserted that static analysis would catch this fairly easily.<p>My guess would be too many (false?) positives on bounds-checking causing them to disable that check, but I can&#x27;t be sure.
rurban超过 3 年前
Now take a deep look at the POSIX C standard, Annex K. The bounds checked extensions. Using these would have definitely avoided the problem. memcpy_s requires the size of dest to be defined. The applause goes to the glibc maintainers, who still think they are above that.
评论 #29412533 未加载
评论 #29412009 未加载
Jyaif超过 3 年前
For at least a decade, and in the teams I was in, C&quot;++&quot; written like this would not pass code review precisely because it is incredibly brittle.
评论 #29410212 未加载
nielsole超过 3 年前
&gt; Issue #2 Arbitrary size limits.[...]<p>&gt; A reasonable choice might be 2^24-1 bytes, the largest possible certificate<p>How does one treat untrusted input whose length might exceed available memory? I am working on a patch for a jwks implementation which does not even have upper bounds in the spec. Accepting any valid input until OOMing seems like a suboptimal solution.
评论 #29409780 未加载
评论 #29413108 未加载
sneak超过 3 年前
You&#x27;d think that in the wake of &quot;goto fail;&quot; the organization that pioneered rust would have rewritten their core TLS certificate checking library in rust by now, hacker news tropes notwithstanding.
brundolf超过 3 年前
Which end-user applications are affected? And what would an attacker have to do to exploit this in the wild?
Stampo00超过 3 年前
Why don&#x27;t we have linters that would complain about copying memory without bounds checking?
_wldu超过 3 年前
The sooner we can rewrite our programs in Go and Rust, the more secure we will be. Our shells, coreutils, mail readers and web browsers have to be written in safer languages.
评论 #29408573 未加载
评论 #29410254 未加载
sitkack超过 3 年前
All ASN1 parsers need to get replaced with safe Rust code, full stop.
Veserv超过 3 年前
This absolutely should have happened. &quot;Mature, world-class security teams&quot; are, as a general rule, objectively terrible at creating products that meet any meaningful, objective definition of security.<p>Remember a few years ago when Apple, the world&#x27;s most valuable company, released a version of macOS that not only let you log into root with no password(!), but actually helpfully created a root account with the password supplied for the first person who tried to login to root[1]? Zerodium can purchase a vulnerability of similar severity to the one described in the article in Mozilla&#x27;s premier product, Firefox, which undoubtedly has the best engineers at Mozilla and has had hundreds of millions if not billions spent on its development for $100k [2]. Even if we lowball the consulting rates for a skilled engineer at ~$500k, that means that we should expect a single, skilled engineer to, on average, find such a vulnerability with ~2 months of fulltime work otherwise the supply would have dried up.<p>By no objective metric does taking 2 months of a single engineer&#x27;s time to completely defeat the security of a widely used product constitute a meaningful, objective level of security. Even a two order of magnitude underestimation, literally 100x more than needed, still puts it in the range of a small team working for a year which still does not qualify as meaningful security. And, we can verify that this assessment is fairly consistent with the truth because we can ask basically any security professional if they believe a single person or a small team can completely breach their systems and they will invariably be scared shitless by the thought.<p>The processes employed by the large, public, commercial tech companies that are viewed as leaders in security systemically produce software with security that is not only imperfect, it is not even good; it is terrible and is completely inadequate for any purpose where even just small scale criminal operations can be expected as seen by the rash of modern ransomware. Even the engineers who made these systems openly admit to this state of affairs [3] and many will even claim that it can not be made materially better. If the people making it are saying it is bad as a general rule, you should run away, fast.<p>To achieve adequate protection against threat actors who actually act against these products would require not mere 100% improvements, it would require 10,000% or even 100,000% improvements in their processes. To give some perspective on that, people who tout Rust say that it if we switch to it we will remove the memory safety defects which are 70% of all security defects. If we use quantity of security defects as a proxy for security (which is an okay proxy to first order), that would require 6 successive switches to technologies each as much better than the last as people who like Rust say Rust is better than C++. That is how far away it all is, the security leaders do not need just a silver bullet, they need a whole silver revolver.<p>In summary, a vulnerability like this is totally expected and not because they failed to have &quot;world-class security&quot; but because that is what &quot;world-class security&quot; actually means.<p>[1] <a href="https:&#x2F;&#x2F;arstechnica.com&#x2F;information-technology&#x2F;2017&#x2F;11&#x2F;macos-bug-lets-you-log-in-as-admin-with-no-password-required&#x2F;" rel="nofollow">https:&#x2F;&#x2F;arstechnica.com&#x2F;information-technology&#x2F;2017&#x2F;11&#x2F;macos...</a><p>[2] <a href="https:&#x2F;&#x2F;zerodium.com&#x2F;program.html" rel="nofollow">https:&#x2F;&#x2F;zerodium.com&#x2F;program.html</a> (ZERODIUM Payouts for Desktops&#x2F;Servers:Firefox RCE+LPE)<p>[3] <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;2030&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;2030&#x2F;</a><p>[4] <a href="https:&#x2F;&#x2F;www.zdnet.com&#x2F;article&#x2F;microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.zdnet.com&#x2F;article&#x2F;microsoft-70-percent-of-all-se...</a>
评论 #29409857 未加载
edoceo超过 3 年前
Buffer Overflow is a classic right? (queue Rust enthusiasts)
评论 #29408194 未加载
评论 #29408245 未加载
评论 #29408074 未加载
评论 #29409319 未加载
nomoreusernames超过 3 年前
so who wants to tell linus to rewrite everything in rust?
throwaway5371超过 3 年前
i love the fact that people can read and write whatever they want wherever they want<p>go and rust make things a bit boring, c makes me feel like a kid<p>of course the price for freedom is security haha
mleonhard超过 3 年前
What went wrong - Issue #0: The library was not re-written in a language that prevents undefined behavior (UB).
评论 #29409970 未加载
aoetalks超过 3 年前
When will we switch to memory safe (but reasonably performant) languages like Go&#x2F;Rust&#x2F;C#?<p>Performance critical sections could remain in C&#x2F;C++, but MOST code doesn’t need the kind of performance C&#x2F;C++ provides.<p>Hopefully C&#x2F;C++ will go the way of assembly: present in TINY doses.
评论 #29412157 未加载