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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

OpenSSL Security Advisory [7th February 2023]

134 点作者 FiloSottile超过 2 年前

9 条评论

some_furry超过 2 年前
Are these dates correct?<p><pre><code> An initial report of a possible timing side channel was made on 14th July 2020 by Hubert Kario (Red Hat). A refined report identifying a specific timing side channel was made on 15th July 2022 by Hubert Kario. The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario. </code></pre> If so, it&#x27;s <i>interesting</i> that it took exactly 2 years and 1 day for the refined report.<p>EDIT: By interesting I just mean &quot;an amusing coincidence&quot; or &quot;possibly a typo&quot;, nothing weird.
评论 #34696401 未加载
评论 #34695529 未加载
Nimi超过 2 年前
Is there a writeup describing the exact timing side channel? The advisory states that the vulnerability affects all RSA padding modes, which seems to imply non-constant-time BigNum operations. However, OpenSSL implemented RSA blinding even before the fix, which is supposed to prevent those class of problems. So this should be interesting :-)<p>(I did find the commit fixing it, but it&#x27;s huge, and I can&#x27;t follow the change: <a href="https:&#x2F;&#x2F;github.com&#x2F;openssl&#x2F;openssl&#x2F;commit&#x2F;b1892d21f8f0435deb0250f24a97915dc641c807">https:&#x2F;&#x2F;github.com&#x2F;openssl&#x2F;openssl&#x2F;commit&#x2F;b1892d21f8f0435deb...</a>
1letterunixname超过 2 年前
Keep doing the same thing and expecting a different result is one of 2 possibilities. No surprise and it will keep happening. Let me enumerate:<p>- Governance is awful<p>- They pile in every feature imaginable<p>- ... with insufficient testing<p>- Insist on throwing everything imaginable together in one mega package<p>- Code style is messy<p>- Aren&#x27;t all that organized<p>- Release unbaked features randomly<p>- Bow to the whims of emergency asks by random governments and corporations<p>It&#x27;s why OpenBSD forked and took a blowtorch to half of their junk.<p>Don&#x27;t use OpenSSL and not expect to be pwned by any one of an endless stream of 0days or CVEs.
LinuxBender超过 2 年前
Updates for this were released on Alpine and Void Linux. I assume the same for most other distributions?<p><pre><code> Alpine: OpenSSL 3.0.8 7 Feb 2023 (Library: OpenSSL 3.0.8 7 Feb 2023) Void: OpenSSL 1.1.1t 7 Feb 2023</code></pre>
formerly_proven超过 2 年前
These pretty much all just look like the usual legacy crypto horror show bugs.
评论 #34698336 未加载
irogers超过 2 年前
This seems relevant:<p>Future of Memory Safety Challenges and Recommendations <a href="https:&#x2F;&#x2F;advocacy.consumerreports.org&#x2F;wp-content&#x2F;uploads&#x2F;2023&#x2F;01&#x2F;Memory-Safety-Convening-Report-1-1.pdf" rel="nofollow">https:&#x2F;&#x2F;advocacy.consumerreports.org&#x2F;wp-content&#x2F;uploads&#x2F;2023...</a><p>&quot;&quot;&quot; Case Studies 1. The Python cryptographic authority is one of the most widely used cryptography libraries in the Python ecosystem. Many of the tools are largely built on OpenSSL. The popular cryptography library is written in C. About two years ago, the maintainers started the process of migrating some of their dependence on OpenSSL away from that to their own Rust code, particularly starting with areas around certificate parsing and parsing of other structures. These are some of the most classical places to find memory safety vulnerabilities in C libraries, and they wanted to mitigate the risk that they were having by relying on OpenSSL.<p>Another benefit was getting huge performance improvements, because the greater safety guarantees they were getting from the language allowed them to be more aggressive in doing things like not copying memory. Specifically, the safety guarantees of Rust mean that one can easily represent structures like X.509 certificates as an array of bytes, and then a parsed structure containing pointers into the original array. ... &quot;&quot;&quot;
评论 #34697398 未加载
topspin超过 2 年前
One type error, one timing attack and six memory safety problems. Defect ratio checks out.
评论 #34698251 未加载
评论 #34696719 未加载
评论 #34700810 未加载
stabbles超过 2 年前
A few more CVEs and we&#x27;re at OpenSSL 1.1.1z, followed by v1.1.1.za, and it is going to break some package manager that in a certain locale orders versions as 1.1.1.za &gt; 1.1.1z, and its users will be stuck on a vulnerable version.
评论 #34695959 未加载
评论 #34697423 未加载
KennyBlanken超过 2 年前
A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does.<p><a href="https:&#x2F;&#x2F;www.libressl.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.libressl.org&#x2F;</a>
评论 #34697010 未加载
评论 #34697170 未加载
评论 #34698199 未加载
评论 #34696920 未加载
评论 #34697410 未加载