Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-30333PUBLISHED: 2022-05-09RARLAB UnRAR before 6.12 on Linux and UNIX allows directory traversal to write to files during an extract (aka unpack) operation, as demonstrated by creating a ~/.ssh/authorized_keys file. NOTE: WinRAR and Android RAR are unaffected.
CVE-2022-23066PUBLISHED: 2022-05-09
In Solana rBPF versions 0.2.26 and 0.2.27 are affected by Incorrect Calculation which is caused by improper implementation of sdiv instruction. This can lead to the wrong execution path, resulting in huge loss in specific cases. For example, the result of a sdiv instruction may decide whether to tra...
CVE-2022-28463PUBLISHED: 2022-05-08ImageMagick 7.1.0-27 is vulnerable to Buffer Overflow.
CVE-2022-28470PUBLISHED: 2022-05-08marcador package in PyPI 0.1 through 0.13 included a code-execution backdoor.
CVE-2022-1620PUBLISHED: 2022-05-08NULL Pointer Dereference in function vim_regexec_string at regexp.c:2729 in GitHub repository vim/vim prior to 8.2.4901. NULL Pointer Dereference in function vim_regexec_string at regexp.c:2729 allows attackers to cause a denial of service (application crash) via a crafted input.
User Rank: Author
12/18/2014 | 8:33:02 AM
I've followed the Snowden leaks closely. He's certainly done wonders for those outside of the InfoSec community when it comes to general knowledge about the necessity for encryption. As for how Snowden relates to not trusting proprietary encryption code, are you referring to the intentional weakening of RSA's DUAL EC? Something else? I ask because most of the other leaks detail exploiting vulnerabilities surrounding implementation, not actually breaking crypto. Have I missed something?
I do agree that "you have no idea who has been putting trapdoors into your software" but that applies to open source as well. How deeply must we inspect the code? What about the language used? The libraries that shipped with your OS? What about the compilers? The firmware? Hardware?
The rigor required to write good security software is more often found within established companies. They have processes in place that make the variables mentioned above as consistent as possible. There's also more control over the team and the talent. A high degree of certainty in all of these areas are critical when it comes to building security applications.
At the end of the day, this game is about trust. We're all making decisions about which products to trust. Just because you can look at the code yourself doesn't mean you're capable of understanding it and just because a "security" expert said the code is fine, doesn't mean it is.
The Ada point is relevant. I don't think it's the solution but if anyone is intereted in more information about some of the security shortcomings of popular native languages and how Ada addresses them there's a free e-book you can grab from AdaCore: http://www.adacore.com/uploads_gems/Ada_Safe_and_Secure_Booklet.pdf