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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Why did the OpenSSL punycode vulnerability happen?

197 点作者 stargrave超过 2 年前

9 条评论

mikepavone超过 2 年前
&gt; There is a function, ossl_punycode_decode that decodes Punycode. Punycode is a way to encode Unicode as ASCII, used to represent Unicode strings in the ASCII-only world of DNS. ossl_punycode_decode takes an output buffer, and if the buffer runs out it keeps parsing and verifying the Punycode but discards the rest of the output.<p>&gt; I did not have the heart to figure out why it works like this. Maybe there&#x27;s a good reason to do progressive parsing. Maybe it&#x27;s an artifact of how C makes you do memory management or of OpenSSL&#x27;s C style. Anyway.<p>Not involved in OpenSSL, but this is a fairly common pattern in a lot of C APIs. You want to decode some data, but you&#x27;re not sure how big the output is going to be ahead of time. You could write a separate function to calculate the length, but that function has to do most of the work of actual decoding to figure out that length. A lot of times the output is small enough it can fit in some conservatively sized buffer so you can save a fair bit of work by having a (potentially stack-allocated) buffer of some fixed size and then allocating a precisely sized buffer on the heap if it turns out to not be big enough. Further, having a separate length function means you typically end up with two similar but separate decode implementations which has its own problems.<p>In most other languages, you have some sort of growable container in the standard library so you just avoid the problem entirely at the expense of having less control over memory allocations.
评论 #33445950 未加载
评论 #33446162 未加载
评论 #33444776 未加载
MBCook超过 2 年前
So the blog mentions that in certain cases you have to decode the punycode from one field to compare it to the value in another field.<p>Would it have been safer to <i>encode</i> the data in the other field to punycode and compare the encoded values?<p>That way a hacker can’t mess with your decoder (where bugs like to lie). But at the other end you risk that your <i>encoder</i> has an issue. I do t know how to judge if those are equal risks or not.<p>Thoughts?
评论 #33446903 未加载
评论 #33448070 未加载
tester756超过 2 年前
It feels like issues like those are more common in parsers, this specific kind of software.<p>But why?<p>Why is parsing so hard? or is it just in low lvl languages? or maybe languages with poor string primitives?<p>I&#x27;ve written parsers in high level languages and it didnt felt dangerous or insanely hard
评论 #33444392 未加载
评论 #33444503 未加载
评论 #33445303 未加载
评论 #33444347 未加载
评论 #33479132 未加载
评论 #33444444 未加载
评论 #33444194 未加载
评论 #33458586 未加载
评论 #33444561 未加载
dang超过 2 年前
Ongoing related thread:<p><i>The latest OpenSSL vulns were added fairly recently</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33437158" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33437158</a> - Nov 2022 (56 comments)
AceJohnny2超过 2 年前
&gt; <i>As curl author Daniel Stenberg said, &quot;I&#x27;ve never even considered to decode punycode. Why does something like OpenSSL need to decode this?&quot;</i><p>&gt; <i>[...]</i><p>&gt; <i>Internationalization is not the issue, internationalization is the job.</i><p>I want to cheer at this.<p>Internationalization is <i>hard</i>, really hard, especially in a computing world so defined by its english-language dominance. The little amount of effort demonstrated in defining and testing this feature demonstrates that.<p>For all I admire Stenberg&#x27;s work and focus on quality, that was a rather poor take from him.
评论 #33444961 未加载
ahoog42超过 2 年前
I decided to review SBOMs from about 3,800 popular mobile apps to see if any included vulnerable versions of OpenSSL v3.0.x. No mobile apps did (not surprised) but what did surprise me was 98% of the OpenSSL versions included in these apps were vulnerable to older CVEs. About 16% of the apps included OpenSSL, mostly as a transitive dependency.<p>I posted additional details in this blog+video: <a href="https:&#x2F;&#x2F;www.andrewhoog.com&#x2F;post&#x2F;how-to-detect-openssl-v3-and-heartbleed-in-mobile-apps&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.andrewhoog.com&#x2F;post&#x2F;how-to-detect-openssl-v3-and...</a>
评论 #33449420 未加载
jesprenj超过 2 年前
Why would a TLS library even parse punycode? The sole reason we still use this hack is so that core infrastructure does not have to change when we use internationalized domains.<p>If TLS libraries, DNS servers, HTTP servers, ... needed to be patched anyways for the use of IDNs, then why did we not do it properly and just use UTF-8?<p>No matter how many vulnerabilities we&#x27;ve introduced into software, &quot;Š&quot; in my name still cannot be represented in domain names and is instead written with american letters xn--pga.<p>I&#x27;m sorry for poorly articulating my thoughts here.
评论 #33454034 未加载
评论 #33450545 未加载
nraynaud超过 2 年前
About the classification: I would add that the people choosing the severity are a bit alone because of secrecy, so they also can’t really ask too much for advice.<p>That’s probably where the NSA could be useful because of their big number of competent and sworn to secrecy employees, but nobody can trust that the zero day sent for an opinion will not be used to fuck with a foreign country on day one.
cryptonector超过 2 年前
So, punycode I do think was silly. We should just have used UTF-8 in DNS and have left it at that.<p>Using UTF-8 would not have required a flag day. It would have required upgrading some servers in order to be able to have non-ASCII domainnames, but it wouldn&#x27;t have broken anyone not using non-ASCII domainnames.
评论 #33455028 未加载