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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

OpenSSL Security Advisory

96 点作者 tlo超过 10 年前

9 条评论

tptacek超过 10 年前
The optics of this advisory are bad, of course, but these are probably not operationally important bugs for most people:<p>* DTLS segmentation fault in dtls1_get_record (<i>only impacts people who use DTLS, and is a null pointer deref, which usually isn&#x27;t exploitable</i>)<p>* DTLS memory leak in dtls1_buffer_record (<i>same, and only exhausts memory</i>)<p>* no-ssl3 configuration sets method to NULL (<i>a non-standard build produces a null pointer crash in SSL3 negotiation</i>)<p>* ECDHE silently downgrades to ECDH (<i>this looks like a server can in an oddball situation lie about forward secrecy --- also, this only impacts OpenSSL clients, like curl</i>)<p>* RSA silently downgrades to EXPORT_RSA (<i>a server can sabotage the security of a session, which it can do in a variety of other ways anyways --- also, this only impacts OpenSSL clients, like curl</i>)<p>* DH client certificates accepted without verification (<i>breaks client authentication, which not many people rely on, but only affects servers that (a) do TLS client auth and (b) trust DH-key-issuing CAs, which are &quot;extremely rare and hardly ever encountered&quot;</i>)<p>* Certificate fingerprints can be modified (<i>this one I actually wonder about the sev:lo on; it&#x27;s low because it doesn&#x27;t impact browsers, but certificate blacklists are common in enterprise software</i>)<p>* Bignum squaring may produce incorrect results (<i>this is just weird</i>)
评论 #8857363 未加载
评论 #8858092 未加载
评论 #8857338 未加载
Tobu超过 10 年前
Seems like INRIA is starting to do some formal checking of OpenSSL. Here&#x27;s their page: <a href="http://prosecco.gforge.inria.fr/" rel="nofollow">http:&#x2F;&#x2F;prosecco.gforge.inria.fr&#x2F;</a><p>Here&#x27;s another OpenSSL flaw that was found with Coq, a formal prover: <a href="http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html" rel="nofollow">http:&#x2F;&#x2F;ccsinjection.lepidum.co.jp&#x2F;blog&#x2F;2014-06-05&#x2F;CCS-Inject...</a>
nanolith超过 10 年前
While this particular vulnerability in OpenSSL isn&#x27;t nearly as bad as some of the other recent ones, it drives me crazy that we still have NULL pointer dereferences in something this critical. The worst part of this library is that the way it is organized makes it difficult to find these problems, or to use tools such as static analyzers to help. There are some amazing static analysis tools out there for C, but they are rendered useless by some of the hackery used in this library, such as their custom allocators. I don&#x27;t mean to sound negative -- the OpenSSL team has done a great job making this library available in the first place -- but given how heavily this library is relied upon, better discipline is needed in this code base.<p>LibreSSL is a step in the right direction, and I commend the OpenBSD team for taking on this alternative. However, it&#x27;s only a starting point. The entire approach of OpenSSL is dated, and it has not done a good job keeping up with our modern understanding of solid security engineering. The code base needs to be overhauled from the ground up with modern security and software development practices in mind. If ever there were a library that should be designed using formal proofs in software, it&#x27;s this one. Even basic TDD with good code coverage would catch the majority of the bugs that have been discovered in OpenSSL over the past ten years.<p>&lt;&#x2F;rant&gt;
评论 #8858860 未加载
评论 #8858215 未加载
kazuho超过 10 年前
Kind of off-topic, but I wonder when they will release OpenSSL 1.0.2.<p>1.0.2 includes important fixes (e.g. support for ALPN which is mandatory in HTTP&#x2F;2, adds support for cross-root certificate validation).
评论 #8857172 未加载
martinknafve超过 10 年前
I&#x27;m unable to compile this on Win32 (I don&#x27;t have any problems compiling older versions). I don&#x27;t understand how the code could compile for anyone, maybe it&#x27;s a platform specific issue. Take a look here on line 80:<p><a href="https://github.com/openssl/openssl/blob/master/crypto/cversion.c" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;openssl&#x2F;openssl&#x2F;blob&#x2F;master&#x2F;crypto&#x2F;cversi...</a><p>The variable cflags isn&#x27;t defined. I suspect it should be CFLAGS. I can make it compile locally by changing that, and it would make the code in the function consistent with the other code in the same file.<p>I thought C defines were case sensitive on all platforms. Anyone knows better than me?
评论 #8857738 未加载
sarciszewski超过 10 年前
<a href="https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j...OpenSSL_1_0_1k" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;openssl&#x2F;openssl&#x2F;compare&#x2F;OpenSSL_1_0_1j......</a><p>And for future releases, it may be worthwhile to watch this URL to find unpatched vulnerabilities:<p><a href="https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k...OpenSSL_1_0_1-stable" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;openssl&#x2F;openssl&#x2F;compare&#x2F;OpenSSL_1_0_1k......</a><p>;)
评论 #8856953 未加载
评论 #8856948 未加载
ck2超过 10 年前
Nothing on centos&#x2F;epel yet.
chinathrow超过 10 年前
<a href="https://www.openssl.org/news/secadv_20150108.txt" rel="nofollow">https:&#x2F;&#x2F;www.openssl.org&#x2F;news&#x2F;secadv_20150108.txt</a>
评论 #8857098 未加载
KamiNuvini超过 10 年前
Security advisory: <a href="https://mta.openssl.org/pipermail/openssl-announce/2015-January/000007.html" rel="nofollow">https:&#x2F;&#x2F;mta.openssl.org&#x2F;pipermail&#x2F;openssl-announce&#x2F;2015-Janu...</a>
评论 #8856942 未加载
评论 #8856935 未加载
评论 #8856969 未加载