181–190 of 217 posts
Earlier quoted context omitted.
It's not useless, and if it identified the vulnerability it'd massively increase the risk of it being used before patch release.
Attackers can just go look at the repo's commits. Holding back the information only hurts defenders.
Earlier quoted context omitted.
Attackers can just go look at the repo's commits. Holding back the information only hurts defenders.
It seems unlikely to me that the maintainers are that careless.
Earlier quoted context omitted.
I don't really get the reasoning (if there's a security bug, surely you know you've fixed it?). I fully support taking down versions that have known vulnerabilities, like the broken OpenSSL crate mentioned in that discussion. The bug in cargo made the issues worse but not by much. Pulling crates/packages from the repository will break the build for almost everyone because updating your dependencies to the latest vers…
Security is a tradeoff between usability and safety. In this case, the author of ring received a suggestion from Rust security group to yank old, unsupported versions to be on the safe side, which created usability problems with ring. Security-minded people are OK with that, while security-ignorant people are not.
Not being able to build a fixed release for a vulnerability you discovered in your own code has a bigger impact than a theoretical vulnerability that results in... not getting feature and API updates?
The code author can release his code in whatever way he wants and he can take down all but the very latest version of his package if he wants. It just makes his package unusable as a dependency for any real-world applications.
Earlier quoted context omitted.
Security flaws can be exploited by governments and corporations, too.
And much more effectively, and at much larger scale. The same security flaw that lets you jailbreak a phone could also allow a hostile entity to say "we don't need you to unlock your phone/laptop, we'll just seize it and break into it using known security vulnerabilities". Buy devices that you control. Don't try to make other people's devices less secure because you want to break into your own.
How many times does this have to happen before we start rejecting components written in unsafe languages?
We have no indication that memory safety is even involved in this bug. For all we know, it could be a timing vulnerability that allows factoring key material, data being copied from the wrong object, or a protocol flow bug that let's the attacker bypass validation. You can create a vulnerability by adding || where you meant && in any programming language, even Rust without unsafe code enabled.
Earlier quoted context omitted.
It is very unlikely that this affects OpenSSH regardless. Only the cryptographic primitives are used from OpenSSL, and none of the complexity of the SSL functions. The cryptographic functions themselves are small and extremely well tested.
OpenSSH (or commonly used variants thereof?) supports X.509 certificates, would they really reimplement that can of worms instead of using already linked libssl functions? Especially since on OpenSSH's home platform libssl is LibreSSL which they consider safer than OpenSSL. Also, there already was one OpenSSL 3 crypto primitive caused vuln or at least security relevant bug in OpenSSH this year: https://thehackernews.…
Note that OpenSSH certificates are a different, and
much simpler, format to the X.509 certificates used in ssl(8).November 1st is a bank holiday in France, so a lot of sysadmins won’t be happy and systems will be vulnerable.
Earlier quoted context omitted.
Your point stands, but FWIW, this is actually Globalsign GMO[0], one of the largest TLS certificate authorities (CA's), so certainly they have a vested interest in making sure OpenSSL is secure. (Globalsign also partnered with CloudFlare for TLS certificates[1]) 0. https://en.wikipedia.org/wiki/GlobalSign 1. https://techcrunch.com/2012/11/01/cloudflare-globalsign-make...
I don't think the post is inaccurate or the authors untrustworthy, but I don't think it's a good idea to rely on their blog to get OpenSSL alerts, especially when there is an official, high signal-to-noise, alternative. If someone reads this HN submission and wants to make sure they get alerted about the next critical vulnerability, they should subscribe.
when will browsers learn and just replace ssl/tls with one line of code to verify that the public key portion of the URL matches the session established by the website? C is only a hundredth of the problem here (that 100th is still big). its ironic that this news was brought to us by a scammer's corporate blog
Can you elaborate?