{"id":30690,"date":"2022-11-02T10:49:02","date_gmt":"2022-11-02T14:49:02","guid":{"rendered":"https:\/\/www.itworldcanada.com?p=511358"},"modified":"2022-11-03T09:54:38","modified_gmt":"2022-11-03T13:54:38","slug":"openssl-vulnerability-now-rated-high-but-should-be-taken-seriously","status":"publish","type":"post","link":"https:\/\/technewsday.com\/staging\/openssl-vulnerability-now-rated-high-but-should-be-taken-seriously\/","title":{"rendered":"OpenSSL vulnerability now rated \u2018high\u2019 but should be taken seriously"},"content":{"rendered":"

The vulnerability in OpenSSL that forced the project\u2019s leaders to issue a security patch on Tuesday<\/a> isn\u2019t as bad as initially feared, with the hole\u2019s severity shifted from \u201ccritical\u201d to \u201chigh.\u201d<\/p>\n

Still, experts say infosec leaders need to take it seriously.<\/p>\n

OpenSSL 3.07 fixes a buffer overrun vulnerability in version 3.0 that can be triggered in X.509 certificate verification.<\/p>\n

It looks \u201cnot bad,\u201d Johannes Ullrich, director of research at the SANS Institute, wrote in a blog<\/a>. \u201cExploitation seems to be unlikely given the requirement for a valid signature from a trusted certificate authority. The remote code execution is only likely for a malformed Punycode email address. Patch this one as updated packages become available, but you can stand down from [worrying it\u2019s as big as] \u2018Heartbleed status.’\u201d<\/p>\n

Most organizations should ensure there is an inventory of where OpenSSL is used and what versions, wrote Jorge Orchilles, a SANS principal instructor and chief technology officer at Scythe. For OpenSSL 3.x solutions, see where and how to apply the patch, he said. Then focus on understanding the implementation of the solutions using OpenSSL 3.x that cannot be patched yet and see if there is a possibility of those implementations being exploitable.<\/p>\n

The update fixes two similar issues, CVE-2022-3786 and CVE-2022-3602. Both create buffer overruns that can be triggered in X.509 certificate verification, specifically in name constraint checking. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the \u2018.\u2019 character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.<\/p>\n

Moses Frost, a SANS instructor, wrote that many operating system vendors apparently say there are memory and compiler protections that would make reaching this bug for true exploitability harder than thought. \u201cThere is, however, a chance that OpenSSL 3.0 is in use in network gear such as firewalls, VPNs, switches, and routers,\u201d he added. \u201cMost of these devices do not offer memory protections as they can\u2019t afford to spend the computational cost of doing so. The only saving grace(s) is that the vendor may not have moved to OpenSSL 3.0 yet, and the customers may not have upgraded to software with the vulnerability. The only true way to tell is to wait for vendor disclosures.\u201d<\/p>\n

Patching this new OpenSSL vulnerability is just the start, said Kevin Bocek, vice-president of security strategy and threat Intelligence at Venafi,<\/strong> as it demonstrates how machine identities can be broken, allowing threat actors to masquerade as trusted services. \u201cWhether we\u2019re running in the cloud in Azure, using Kubernetes in Amazon AWS, or using Apache in your data center, the entire digital business requires safe authentication of machine identities,\u201d he said. \u201cThe vulnerabilities in OpenSSL show the impact of poor machine identity management \u2013 specifically authenticating machine identities \u2013 opening the door to attackers.\u201d<\/p>\n

Yotam Perkal, director of vulnerability research at Rezilion, noted that\u00a0version 3.0 of OpenSSL<\/span> was only released a year ago. In IT terms, he argued, it is considered a new library, so not many software projects and applications have migrated to use it. That makes it relatively rare to find in production systems.<\/p>\n

Still, he said, a Shodan scan suggests there are currently nearly 16,000 publicly accessible servers worldwide running potentially vulnerable versions of OpenSSL<\/span> 3.x. Close to 240,000 servers are still vulnerable to the Heartbleed vulnerability, eight years after its initial discovery, he added.<\/p>\n

SecurityScorecard said<\/a> an October 28th query of its scan data to identify specific products with OpenSSL<\/span> 3.x returned 116 results. Within these results, IP cameras were heavily represented: only five of the 116 were for products other than cameras.<\/span>\u00a0<\/span><\/p>\n

The new OpenSSL vulnerability does not affect the issuance or use of certificates, said Tim Callan, chief compliance officer at Sectigo, so IT administrators don\u2019t have to revoke or reissue certificates based on this flaw. This \u201cstraightforward buffer overflow vulnerability\u201d leaves any organization using an unpatched version of OpenSSL 3.0 subject to breach, he added. \u201cNow that this defect is widely known, we should expect attackers to begin exploiting it. Anyone on OpenSSL 3.0 should deploy the patch immediately.\u201d<\/p>\n

The original critical rating sparked fear this would be the next Heartbleed, noted Philippe Laulheret, a senior security researcher at Trellix. That\u2019s not the case. Heartbleed, he said, was easy to exploit and would leak private server information, while these two bugs are memory corruption bugs whose impact is heavily lessened by modern OS and compiler security mitigations. \u201cWhile it\u2019s impossible to rule out the risk of future exploitation, the constraints to make this happen are complex enough that it makes such a thing less likely, and no more probable or dangerous than any other run-of-the-mill memory corruption vulnerability affecting online services.\u201d<\/p>\n

Exploiting this vulnerability requires quite a bit of set up and a number of factors to fall into place before it could be leveraged, said Victor Wieczorek, VP of application security, threat\u00a0 and attack simulation at GuidePoint Security.\u201d Organizations should perform analysis to see if they are impacted, although there are relatively limited affected systems, as the attack primarily impacts the client-side, not the server. Technologies like SCA (software composition analysis) tools can help organizations identify where these components are, so they can create an inventory and then a plan for remediation based on risk.\u201d<\/p>\n

The fact that this is only the second critical vulnerability in OpenSSL<\/span> in the better part of a decade reinforces the statement that open-source code is at least as secure as proprietary, closed-source code, said Dan Lorenc, CEO at Chainguard. \u201cThis vulnerability will likely lead to many discussions around the perceived unsustainability and insecurity of open source, but the facts remain that major, well-funded vendors see bugs like this at a much higher rate. Instead of debating the merits of open source, we should instead focus on building secure software that has the tooling necessary to make remediation faster and more seamless by rooting it in secure by default measures.\u201d<\/p>\n

The post OpenSSL vulnerability now rated \u2018high\u2019 but should be taken seriously<\/a> first appeared on IT World Canada<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

One worry is the vulnerabilbe OpenSSL 3.0 is embedded in firewalls, VPNs, switches a<\/p>\n","protected":false},"author":17,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[66,16],"tags":[391,704,406,393,275,705],"class_list":["post-30690","post","type-post","status-publish","format-standard","hentry","category-open-source","category-security","tag-di","tag-openssl","tag-sans-institute","tag-security-strategies","tag-top-story","tag-vulnerability"],"acf":[],"_links":{"self":[{"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/posts\/30690","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/users\/17"}],"replies":[{"embeddable":true,"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/comments?post=30690"}],"version-history":[{"count":2,"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/posts\/30690\/revisions"}],"predecessor-version":[{"id":30742,"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/posts\/30690\/revisions\/30742"}],"wp:attachment":[{"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/media?parent=30690"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/categories?post=30690"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technewsday.com\/staging\/wp-json\/wp\/v2\/tags?post=30690"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}