SEMCMS SHOP v 1.1 is vulnerable to SQL Injection via Ant_Menu.php.

活动（美国空间400 一年,赠送 .com 或.net 的域名 及 https ssl 证书 价值（1999元），活动只限使用本系统的用户，免费安装系统）  
声明:官方唯一QQ客服 **1181698019**(黑蚂蚁.阿梁)

最新消息疑问解答BUG反馈发展建议经验共享模版服务视频教程

注册 登陆

CVE-2021-38734: SEMCMS外贸网站商城系统 SCSHOP_v1.1 更新

Is the new Heartbleed or just a bleeding distraction?

Is the new Heartbleed or just a bleeding distraction?

Developers of the OpenSSL cryptography library have taken the unusual step of pre-warning that an update due to land next Tuesday (November 1) will fix a critical vulnerability.

The looming OpenSSL 3.x patch represent the only the second time the project has addressed a flaw classified as ‘critical’. The only previous OpenSSL update of such elevated severity addressed the infamous Heartbleed vulnerability (CVE-2014-0160).

Heartbleed was a memory handling bug that opened the door for attackers to access secret keys, passwords, and sensitive personal information from vulnerable servers. At the time of its discovery eight years ago, experts from Netcraft estimated that the flaw affected 17% of SSL web servers or “half a million widely trusted websites”.

Little is known about the upcoming critical fix (OpenSSL 3.0.7), other than it is restricted to OpenSSL version 3.0, the latest release line of the software, and does not affect previous versions.

YOU MAY ALSO LIKE HyperSQL DataBase flaw leaves library vulnerable to RCE

OpenSSL 3.0.x only debuted in 2021, a factor that might limit the extent of the problems next week’s announcement will reveal. OpenSSL has been around since 1998 and most systems today are still built using earlier release lines.

No details of the upcoming patch or the critical flaw it tackles have been released. In the absence of any hard info, infosec Twitter has gone into overdrive with some speculating that the vulnerability might represent the “next Heartbleed”.

One security expert from Google, for example, has suggested on the basis of recent software commits and a blog post by the OpenSSL team that the update might relate to a denial-of-service (DoS) issue.

**Feel the DHEat**

This particular DoS bug – known as DHEat and previous confirmed to affect OpenVPN and SSH services – involves enforcing the Diffie-Hellman key exchange.

DHEat (AKA CVE-2002-20001) scores 7.5 on the CVSS 3.1 index, indicating high severity and falling somewhat short of critical.

On the face of it, an OpenSSL patch for DHEat would appear to be a poor candidate for a critical patch unless OpenSSL is particularly vulnerable. A recent OpenSSL blog post referencing DHEat makes it even more unlikely that the looming patch tackles this issue.

It seems more likely that a previously unknown vulnerability is at play, according to experts quizzed by The Daily Swig.

**Action stations**

Brian Fox, CTO of Sonatype, told us that organizations should audit their code base for exposure to any vulnerability in OpenSSL 3.0.x, leaving them prepared to either patch or isolate vulnerable systems next week.

“In the first instance, it’s critical to find out where 3.x is used,” Fox said. “More importantly, it’s vital to get tooling in place to avoid having to audit and identify components manually every time.”

Catch up on the latest encryption-related news and analysis

Fox went on to argue that speculation about the content of the upcoming fix were, at best, “unhelpful”. He said: “The speculation assumes that the fix is available in the publicly visible source and the advance notice gives attackers time to find it. This assumption may not be true. It is a best practice at some times to embargo the actual change until after the announcement for this exact reason.

“The team at OpenSSL consists of some of the foremost experts in handling high profile open source vulnerability disclosures and if they have determined this is the best course of action – to give advance notice – then I have faith in that decision.”

Professor Alan Woodward, a computer scientist at the University of Surrey, reasoned that the problem is unlikely to be related to the older vulnerability.

“If the OpenSSL vulnerability is truly critical as per their own definition, then it sounds dire,” Prof. Woodward told The Daily Swig. “If it’s the older vulnerability, I fear they may have cried wolf. It isn’t helpful to give so little information but as it is a tiny team I can see why.”

Prof. Woodward concluded: “I guess we’ll all have to wait until next week.”

YOU MAY ALSO LIKE GitHub patches bug that could allow access to another user’s repo

Upcoming ‘critical’ OpenSSL update prompts feverish speculation

Embedding security throughout your company has greater organizational impact and myriad benefits.

As cybersecurity has become an increasingly important consideration in corporate decision-making, there's been a corresponding move to elevate the role of the chief information security officer (CISO) to a higher point in the executive hierarchy. The reasoning seems to be, "If cyber is important, CISOs must be important." However, elevating the role sets the CISO up to be a lone voice in the desert crying "security," with little connection to the day-to-day decision-makers in IT, engineering, or products.

This has led to some undesirable consequences, like the Facebook exec who thought it was OK that the company's security measures caused hours-long delays in responding to its Oct. 4, 2021, outage, or the Uber exec who paid off hackers who breached his system, rather than acknowledge the breach, or the numerous CISOs who have invested in "additional layers of security" rather than admit they made poor selections initially. In all of these cases, the CISO's isolation from functional business units undoubtedly played a role in the tunnel thinking these decisions reflect.

**Organizational Impact**

Perhaps it's time to reimagine the role of the CISO. Maybe it's better to see the CISO's importance reflected in organizational impact rather than organizational status. Perhaps embedding security in functional units will result in better security.

Imagine the CISO as a part of the IT organization ecosystem. They would be involved in every decision about the infrastructure, and security concerns would be integral to those decisions rather than tacked on after the fact. This would allow for a set of "security" solutions based on how the network is structured and managed, rather than on special security capabilities inserted into the infrastructure by an outside group.

Imagine a security expert embedded in the software development organization. They would be able to refine the development process to make sure code is written and tested with an eye to security, without saddling the developers with processes that are alien to them, thereby reducing the vulnerabilities in the company's code. Imagine a security expert embedded in product lines. They would be able to make sure the corporate infrastructure protects their IP and that their development process reduces the vulnerabilities in their product.

In all these cases, security becomes a factor in corporate decisions grounded in the reality of corporate operations. The technical expertise of the CISO becomes integral to day-to-day work rather than a constraint imposed upon it. Similarly, security and compliance need to work seamlessly so that financial systems and communications with partners and vendors remain secure. This extends to telecom systems and other hardware.

**The Risk Factor**

This seems like a more impactful way to make the technical dimension of security a powerful voice in company execution. However, one may wonder if this will diminish the policy dimension, balkanizing it to address the special interests of individual functional units. This concern can be addressed by expanding the role of the chief risk officer to include the security policy functions currently carried out by the CISO. 

This has the benefit of keeping security policy at the C-level, where it gets the attention it needs. It has the further benefit of having cybersecurity risk considered in the context of other risks (risk to availability, risk to reputation, to address the cases above). Security would no longer be an end in itself, but a dimension of doing business. This doesn't mean security needs to battle it out with other concerns and make accommodations that compromise the security posture of the organization. Rather, it sets up an environment that trades the either/or mentality for one that seeks to satisfy all requirements.

There are numerous access control technologies that would have protected Facebook effectively without locking out its own personnel. When the security risk is considered along with the availability risk, those more pragmatic solutions would emerge.

Reimagining the Role of the CISO

Cloud computing was the lifeline that kept many companies running during the pandemic. But it was a classic case of medicine that comes with serious side effects. 
Having anywhere, anytime access to data and apps gives companies tremendous flexibility in a fast-changing world, plus the means to scale and customize IT at will. The cloud is an asset or upgrade in almost every way.
With one glaring

Cloud computing was the lifeline that kept many companies running during the pandemic. But it was a classic case of medicine that comes with _serious_ side effects.

Having anywhere, anytime access to data and apps gives companies tremendous flexibility in a fast-changing world, plus the means to scale and customize IT at will. The cloud is an asset or upgrade in almost every way.

With one glaring exception: cybersecurity.

The cloud promised to make companies more secure and security more straightforward. Yet over the same time period that the cloud took over computing, cyber attacks grew steadily worse while security teams felt increasingly overwhelmed.

Why?

We will explain shortly. For lean security teams, the more important question is how to make cloud security work, especially as the cloud footprint grows (a lot) faster than security resources. Will the cloud always cast a shadow on cybersecurity?

Not with the strategy outlined in a free ebook from Cynet called "The Lean IT Guide to Cloud Security". It explains how security teams with less than 20, 10, or even 5 members can make cloud security work from here forward.

****Storms Brewing in the Cloud****

The "cloud rush" prompted by the pandemic certainly caught hacker's attention. Attacks on cloud services rose 630% in 2020 and topped on-premises attacks for the first time. The sudden increase in cloud adoption explains some of that uptick – the cloud was a larger target than before. But this really had nothing to do with the pandemic.

It was only a matter of time before hackers started relentlessly targeting the cloud, now costing businesses $3.8 million on average with each successful breach.

Clouds look to hackers like prime targets, more appealing than almost any other.

On the one hand, clouds house huge stores of valuable data along with mission-critical applications. They are where the valuable targets live, so they're an obvious, even inevitable attack vector.

On the other hand, clouds either complicate or compromise many of the cyber defenses already in place, while coming with complicated defensive requirements of their own. Many cloud environments end up insecure, making them an easy attack vector as well.

As long as hackers continue to see clouds as equally vulnerable and valuable, the onslaught of attacks will only get worse. The damages will too.

****Making Sense of the Shared-Responsibility Model****

A big reason that cloud security gaps are so common (and so gaping) is because of the unique way we approach cloud cybersecurity.

Most cloud providers rely on the shared-responsibility model, where security responsibilities are split between the vendor and the customer.

Typically, customers handle data accountability, endpoint protection, and identity and access management. Vendors deal with application and network controls, host infrastructure, and physical server security (sharing agreements vary).

Research consistently shows that customers are confused about what is and isn't their responsibility. But even among those that aren't confused, the dividing line between responsibilities can (and has) lead to contentious disputes or security loopholes waiting for hackers to find them.

Problematic as the shared-responsibility model may be, it's standard practice. What's more, it can be a tremendous asset to learn security teams in particular provided they know their responsibilities...and pick the right partner.

****Cloud Security Starts with Vendor Selection****

For better or for worse, the shared-responsibility model obligates cloud customers to form security partnerships with their vendors. And some vendors are better than others.

Thoroughly vetting any cloud provider must be a prerequisite, but that takes time on the part of the evaluator and transparency on the part of the provider. Certifications like STAR Level 2 verify a provider's security credentials, but some companies go a step further and hire risk management services to evaluate a particular cloud. In any case, the goal is to get independent, objective proof the provider takes security seriously.

Upon selecting a vendor, following their security guidance (to the letter) could not be more important. Failure to do so has caused more than a few cloud attacks. Lean teams can make major improvements to cloud security, often at no cost whatsoever, by simply doing what the vendor says to do.

****The Key Pieces for Lean Security Teams****

Picking the right provider/partner solves a big part of the cloud security puzzle. That said, important and ongoing responsibilities still fall _entirely_ on the security team. These can be the weak-points that open the door to cloud attacks – but the right tools address each of the key responsibilities facing cloud customers, and the right vendors integrate more of those tools onto platforms to consolidate cloud security in a manageable form.

In the free ebook "The Lean IT Guide to Cloud Security", Cynet describes what the optimal cloud security toolkit looks like, along with how lean security teams can take advantage of similar strengths without increasing staff or ballooning security spending.

The ebook offers an effective guide to cloud security to the _many_ companies struggling to protect their most important IT. By design, however, it's also a practical and accessible framework designed to help security teams of any size secure cloud deployments of any size.

If cloud security falls on your shoulders, use the guidance from Cynet to make the maximum impact for the minimal investment.

Find out the keys to success in "The Lean IT Guide to Cloud Security" by downloading the free ebook.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Cloud Security Made Simple in New Guidebook For Lean Teams

Vulnerabilities in the web-based management interface of Aruba EdgeConnect Enterprise Orchestrator could allow an unauthenticated remote attacker to bypass authentication. Successful exploitation of these vulnerabilities could allow an attacker to gain administrative privileges leading to a complete compromise of the Aruba EdgeConnect Enterprise Orchestrator with versions 9.1.2.40051 and below, 9.0.7.40108 and below, 8.10.23.40009 and below, and any older branches of Orchestrator not specifically mentioned.

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aruba Product Security Advisory =============================== Advisory ID: ARUBA-PSA-2022-015 CVE: CVE-2022-37913, CVE-2022-37914, CVE-2022-37915 Publication Date: 2022-Oct-11 Status: Confirmed Severity: Critical Revision: 1 Title ===== Multiple Vulnerabilities in Aruba EdgeConnect Enterprise Orchestrator Overview ======== Aruba has released patches for Aruba EdgeConnect Enterprise Orchestrator that address multiple security vulnerabilities. Affected Products ================= - Aruba EdgeConnect Enterprise Orchestrator (on-premises) - Aruba EdgeConnect Enterprise Orchestrator-as-a-Service - Aruba EdgeConnect Enterprise Orchestrator-SP and Aruba EdgeConnect Enterprise Orchestrator Global Enterprise Tenant Orchestrators - Orchestrator 9.1.2.40051 and below - Orchestrator 9.0.7.40108 and below - Orchestrator 8.10.23.40009 and below - Any older branches of Orchestrator not specifically mentioned Versions of Aruba EdgeConnect Enterprise Orchestrator that are end of life are affected by these vulnerabilities unless otherwise indicated. Details ======= Authentication Bypass Leading to System Takeover in Aruba EdgeConnect Enterprise Orchestrator Web-Based Management Interface (CVE-2022-37913, CVE-2022-37914) --------------------------------------------------------------------- Vulnerabilities in the web-based management interface of Aruba EdgeConnect Enterprise Orchestrator could allow an unauthenticated remote attacker to bypass authentication. Successful exploitation of these vulnerabilities could allow an attacker to gain administrative privileges leading to complete compromise of the Aruba EdgeConnect Enterprise Orchestrator host. Internal References: ATLSP-12, ATLSP-25 Severity: Critical CVSSv3.x Overall Score: 9.8 CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Discovery: These vulnerabilities were discovered and reported by Daniel Jensen (@dozernz) via Aruba's Bug Bounty Program. Unauthenticated Remote Code Execution in Aruba EdgeConnect Enterprise Orchestrator Web-Based Management Interface (CVE-2022-37915) --------------------------------------------------------------------- A vulnerability in the web-based management interface of Aruba EdgeConnect Enterprise Orchestrator could allow an unauthenticated remote attacker to run arbitrary commands on the underlying host. Successful exploitation of this vulnerability could allow an attacker to execute arbitrary commands on the underlying operating system leading to complete system compromise. Internal References: ATLWL-313 Severity: Critical CVSSv3.x Overall Score: 9.8 CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Discovery: This vulnerability was discovered and reported by Daniel Jensen (@dozernz) via Aruba's Bug Bounty Program Affected: This vulnerability only affected the versions listed - Aruba EdgeConnect Enterprise Orchestrator (on-premises) - 9.1.x branch only - Any 9.1.x Orchestrator instantiated as a new machine with a release prior to 9.1.3.40197 - Orchestrators upgraded to 9.1.x were not affected. Resolution: If you have a version of Aruba EdgeConnect Enterprise Orchestrator (on-premises) that you believe is affected from the above criteria, please reach out to TAC for resolution assistance. Resolution ========== Upgrade Aruba EdgeConnect Enterprise Orchestrator to one of the following versions with the fixes to resolve all issues noted in the details section. - Aruba EdgeConnect Enterprise Orchestrator (on-premises) - Orchestrator 9.2.0.40405 and above - Orchestrator 9.1.3.40197 and above - Orchestrator 9.0.7.40110 and above - Orchestrator 8.10.23.40015 and above - Aruba EdgeConnect Enterprise Orchestrator-as-a-Service - TAC will automatically create a support case for Aruba (Silver Peak) hosted Orchestrators to be upgraded. - Aruba EdgeConnect Enterprise Orchestrator-SP and Aruba EdgeConnect Enterprise Orchestrator Global Enterprise Tenant Orchestrators - Service providers must upgrade all tenants to a patched version listed above Aruba does not evaluate or patch product versions that have reached their End of Support (EoS) milestone. Supported versions as of the publication date of this advisory are: - Aruba EdgeConnect Enterprise Orchestrator 9.2.x - Aruba EdgeConnect Enterprise Orchestrator 9.1.x - Aruba EdgeConnect Enterprise Orchestrator 9.0.x - Aruba EdgeConnect Enterprise Orchestrator 8.10.x For more information about Aruba's End of Support policy visit: https://www.arubanetworks.com/support-services/end-of-life/ Workaround ========== To minimize the likelihood of an attacker exploiting these vulnerabilities, Aruba recommends that the CLI and web-based management interfaces be restricted to a dedicated layer 2 segment/VLAN and/or controlled by firewall policies at layer 3 and above. Exploitation and Public Discussion ================================== Aruba is not aware of any public discussion or exploit code that target these specific vulnerabilities as of the release date of the advisory. Revision History ================ Revision 1 / 2022-Oct-11 / Initial release Aruba SIRT Security Procedures ============================== Complete information on reporting security vulnerabilities in Aruba Networks products and obtaining assistance with security incidents is available at: https://www.arubanetworks.com/support-services/security-bulletins/ For reporting \*NEW\* Aruba Networks security issues, email can be sent to aruba-sirt(at)hpe.com. For sensitive information we encourage the use of PGP encryption. Our public keys can be found at: https://www.arubanetworks.com/support-services/security-bulletins/ (c) Copyright 2022 by Aruba, a Hewlett Packard Enterprise company. This advisory may be redistributed freely after the release date given at the top of the text, provided that the redistributed copies are complete and unmodified, including all data and version information. -----BEGIN PGP SIGNATURE----- iQFLBAEBCAA1FiEEMd5pP5EnbG7Y0fo5mP4JykWFhtkFAmM9iKkXHHNpcnRAYXJ1 YmFuZXR3b3Jrcy5jb20ACgkQmP4JykWFhtk6hgf+Pog4Ikx66VHFIjT7owVLkbJ8 HK65RReWCqE8ruyeIeySQa4nZJ+nJZRaHagnunkRNeteC67ETo77Go8NetZ+XKnU SJ5AUF60+M8Yog4OOloNG8/ki0Eh/HZT6Stge+j/dJ1d+3QL78SPrFpUBEUWNOTM hTgwrkP+IZZJCJYHz+dy2bBNF5wwyzRau5xokoxAHzuJt4No01fTWQT3NWipPoBJ eNZKwDLMJBQCQGONY2yWCIs1QZZUQ3z7Ag7JbiJcRApSI91rxKbcCau5+14VmOZd PwUnVt85ijaQCxFO6yJXUgwrjYF/XjpP4IdcoKOCxOYquNVZzYgDFL+Iz9FWcQ== =HYd8 -----END PGP SIGNATURE-----

CVE-2022-37914

Improper Input Validation vulnerability in LiteSpeed Technologies OpenLiteSpeed Web Server Dashboard allows Command Injection. This affects 1.7.0 versions before 1.7.16.1.

CVE-2022-0073: openlitespeed/CValidation.php at v1.7.16 · litespeedtech/openlitespeed

Directory Traversal vulnerability in LiteSpeed Technologies OpenLiteSpeed Web Server Dashboard allows Path Traversal. This affects versions from 1.5.11 through 1.5.12, from 1.6.5 through 1.6.20.1, from 1.7.0 before 1.7.16.1

CVE-2022-0072: openlitespeed/httpserver.cpp at v1.7.16 · litespeedtech/openlitespeed

Crash in the OPUS protocol dissector in Wireshark 3.6.0 to 3.6.8 allows denial of service via packet injection or crafted capture file

Skip to content

Open Issue created Sep 26, 2022 by **Qiuhao Li@QiuhaoLi**

**Stack Overflow Write - OPUS dissector - dissect\_opus() frames**

**Summary**

In dissect\_opus() at wireshark-3.6.8/epan/dissectors/packet-opus.c:254, frame\_count is truncated below 0x3F (63) and checked if framesize \* frame\_count > 120 \* MAX\_FRAMES\_COUNT. But when stack variable frames\[MAX\_FRAMES\_COUNT\] is indexed with frame\_count later, **we didn't make sure frame\_count won't excess MAX\_FRAMES\_COUNT, leading to stack-over-flow write when the begin/size values are put into frames later.**

This flaw affects the current released stable wireshark/tshark/... on Linux/Windows/Mac/..., previous versions may also be affected. This issue hasn't been reported elsewhere.

**Steps to reproduce**

Open the attachment rtp\_opus\_stackoverflow\_poc.pcap with wireshark or tshark. For wireshark GUI it will crash. For tshark it will complain "\*\*\* stack smashing detected \*\*\*: terminated Aborted (core dumped)":

I reproduced this flaw on the current stable version (wireshark-3.6.8) and the latest release version (wireshark-4.0.0rc2). You can view the ASAN report below for more details.

**What is the current bug behavior?**

CWE-121: Stack-based Buffer Overflow (4.8).

**What is the expected correct behavior?**

Make sure frame\_count is not bigger than MAX\_FRAMES\_COUNT.

**Relevant logs and/or screenshots**

ASAN Report:

    qiuhao@VBox:~/wireshark_src/wireshark-3.6.8$ ./run/tshark -r ./rtp_opus_stackoverflow_poc.pcap 
    
        1   0.000000 10.100.147.143 → 10.100.148.44 SIP/SDP 2799 Request: INVITE sip:10.100.148.44 | 
    
    =================================================================
    
    ==83225==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc7ffcd4e2 at pc 0x7fe14f611705 bp 0x7ffc7ffcd330 sp 0x7ffc7ffcd320
    
    WRITE of size 2 at 0x7ffc7ffcd4e2 thread T0
    
        #0 0x7fe14f611704 in parse_size_field /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-opus.c:117
    
        #1 0x7fe14f612764 in dissect_opus /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-opus.c:290
    
        #2 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #3 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #4 0x7fe14e3e8c05 in dissector_try_string_new /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1751
    
        #5 0x7fe14e3e8c9a in dissector_try_string /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1776
    
        #6 0x7fe14f875146 in process_rtp_payload /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-rtp.c:1354
    
        #7 0x7fe14f875671 in dissect_rtp_data /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-rtp.c:1498
    
        #8 0x7fe14f879c92 in dissect_rtp /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-rtp.c:2307
    
        #9 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #10 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #11 0x7fe14e3ee90e in call_dissector_only /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3270
    
        #12 0x7fe14e3b2b70 in try_conversation_call_dissector_helper /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/conversation.c:1362
    
        #13 0x7fe14e3b2d60 in try_conversation_dissector /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/conversation.c:1392
    
        #14 0x7fe14fc6d8c6 in decode_udp_ports /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-udp.c:655
    
        #15 0x7fe14fc722cf in dissect /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-udp.c:1267
    
        #16 0x7fe14fc7239f in dissect_udp /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-udp.c:1273
    
        #17 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #18 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #19 0x7fe14e3e80a1 in dissector_try_uint_new /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1450
    
        #20 0x7fe14f07e700 in ip_try_dissect /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-ip.c:1817
    
        #21 0x7fe14f081668 in dissect_ip_v4 /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-ip.c:2306
    
        #22 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #23 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #24 0x7fe14e3e80a1 in dissector_try_uint_new /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1450
    
        #25 0x7fe14e3e813c in dissector_try_uint /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1474
    
        #26 0x7fe14ece5264 in dissect_ethertype /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-ethertype.c:296
    
        #27 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #28 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #29 0x7fe14e3ee90e in call_dissector_only /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3270
    
        #30 0x7fe14e3ee955 in call_dissector_with_data /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3283
    
        #31 0x7fe14f9cbc9f in dissect_payload /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-sll.c:414
    
        #32 0x7fe14f9cc142 in dissect_sll_common /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-sll.c:518
    
        #33 0x7fe14f9cc2c0 in dissect_sll_v1 /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-sll.c:547
    
        #34 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #35 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #36 0x7fe14e3ee90e in call_dissector_only /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3270
    
        #37 0x7fe14ed6003d in dissect_frame /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-frame.c:935
    
        #38 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #39 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #40 0x7fe14e3ee90e in call_dissector_only /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3270
    
        #41 0x7fe14e3ee955 in call_dissector_with_data /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3283
    
        #42 0x7fe14e3e3dfe in dissect_record /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:624
    
        #43 0x7fe14e3c2448 in epan_dissect_run_with_taps /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/epan.c:629
    
        #44 0x5650067314cc in process_packet_single_pass /home/qiuhao/wireshark_src/wireshark-3.6.8/tshark.c:3863
    
        #45 0x56500672f645 in process_cap_file_single_pass /home/qiuhao/wireshark_src/wireshark-3.6.8/tshark.c:3510
    
        #46 0x565006730633 in process_cap_file /home/qiuhao/wireshark_src/wireshark-3.6.8/tshark.c:3674
    
        #47 0x56500672a574 in main /home/qiuhao/wireshark_src/wireshark-3.6.8/tshark.c:2103
    
        #48 0x7fe145f5fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    
        #49 0x7fe145f5fe3f in __libc_start_main_impl ../csu/libc-start.c:392
    
        #50 0x565006723c94 in _start (/home/qiuhao/wireshark_src/wireshark-3.6.8/run/tshark+0x33c94)
    
    
    
    Address 0x7ffc7ffcd4e2 is located in stack of thread T0 at offset 258 in frame
    
        #0 0x7fe14f611a1d in dissect_opus /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-opus.c:153
    
    
    
      This frame has 4 object(s):
    
        [32, 33) 'toc' (line 161)
    
        [48, 50) 'framesize' (line 164)
    
        [64, 256) 'frames' (line 168) <== Memory access at offset 258 overflows this variable
    
        [320, 322) 'octet' (line 161)
    
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
    
          (longjmp and C++ exceptions *are* supported)
    
    SUMMARY: AddressSanitizer: stack-buffer-overflow /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-opus.c:117 in parse_size_field
    
    Shadow bytes around the buggy address:
    
      0x10000fff1a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1a70: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
    
      0x10000fff1a80: 01 f2 02 f2 00 00 00 00 00 00 00 00 00 00 00 00
    
    =>0x10000fff1a90: 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2
    
      0x10000fff1aa0: f2 f2 f2 f2 02 f3 f3 f3 00 00 00 00 00 00 00 00
    
      0x10000fff1ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
    Shadow byte legend (one shadow byte represents 8 application bytes):
    
      Addressable:           00
    
      Partially addressable: 01 02 03 04 05 06 07 
    
      Heap left redzone:       fa
    
      Freed heap region:       fd
    
      Stack left redzone:      f1
    
      Stack mid redzone:       f2
    
      Stack right redzone:     f3
    
      Stack after return:      f5
    
      Stack use after scope:   f8
    
      Global redzone:          f9
    
      Global init order:       f6
    
      Poisoned by user:        f7
    
      Container overflow:      fc
    
      Array cookie:            ac
    
      Intra object redzone:    bb
    
      ASan internal:           fe
    
      Left alloca redzone:     ca
    
      Right alloca redzone:    cb
    
      Shadow gap:              cc
    
    ==83225==ABORTING
    

**Build information**

    TShark (Wireshark) 3.6.8 (Git commit d25900c51508)
    
    
    
    Copyright 1998-2022 Gerald Combs <gerald@wireshark.org> and contributors.
    
    License GPLv2+: GNU GPL version 2 or later <https://www.gnu.org/licenses/gpl-2.0.html>
    
    This is free software; see the source for copying conditions. There is NO
    
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    
    
    Compiled (64-bit) using GCC 11.2.0, with libpcap, with POSIX capabilities
    
    (Linux), with libnl 3, with GLib 2.72.1, with zlib 1.2.11, with Lua 5.2.4, with
    
    GnuTLS 3.7.3 and PKCS #11 support, with Gcrypt 1.9.4, with MIT Kerberos, with
    
    MaxMind DB resolver, with nghttp2 1.43.0, with brotli, with LZ4, with Zstandard,
    
    with Snappy, with libxml2 2.9.13, with libsmi 0.4.8.
    
    
    
    Running on Linux 5.15.0-47-generic, with 11th Gen Intel(R) Core(TM) i7-11850H @
    
    2.50GHz (with SSE4.2), with 7949 MB of physical memory, with GLib 2.72.1, with
    
    zlib 1.2.11, with libpcap 1.10.1 (with TPACKET_V3), with c-ares 1.18.1, with
    
    GnuTLS 3.7.3, with Gcrypt 1.9.4, with nghttp2 1.43.0, with brotli 1.0.9, with
    
    LZ4 1.9.3, with Zstandard 1.4.8, with libsmi 0.4.8, with LC_TYPE=en_US.UTF-8,
    
    binary plugins supported (0 loaded).

Omit 4.0.0 and Windows/Linux/Mac GUI Version...

CVE-2022-3725: Stack Overflow Write - OPUS dissector - dissect_opus() frames (#18378) · Issues · Wireshark Foundation / wireshark · GitLab

Even if the security bug is not another Heartbleed, prepare like it might be, they note — it has potentially sprawling ramifications.

Organizations have five days to prepare for what the OpenSSL Project on Oct. 26 described as a "critical" vulnerability in versions 3.0 and above of the nearly ubiquitously used cryptographic library for encrypting communications on the Internet.

On Tuesday, Nov. 1, the project will release a new version of OpenSSL (version 3.0.7) that will patch an as-yet-undisclosed flaw in current versions of the technology. The characteristics of the vulnerability and ease with which it can be exploited will determine the speed with which organizations will need to address the issue.

**Potentially Huge Implications**

Major operating system vendors, software publishers, email providers, and technology companies that have integrated OpenSSL into their products and services will likely have updated versions of their technologies timed for release with the OpenSSL Project's disclosure of the flaw next Tuesday. But that will still leave potentially millions of others — including federal agencies, private companies, service providers, network device manufacturers, and countless website operators — with a looming deadline to find and fix the vulnerability before threat actors begin to exploit it.

If the new vulnerability turns out to be another Heartbleed bug — the last critical vulnerability to impact OpenSSL — organizations and indeed the entire industry are going to be under the gun to address the issue as quickly as possible.

The Heartbleed vulnerability (CVE-2014-0160), disclosed in 2014, basically gave attackers a way to eavesdrop on Internet communications, steal data from services and users, to impersonate services, and do all this with little trace of their ever having done any of it. The bug existed in OpenSSL versions from March 2012 onward and affected a dizzying range of technologies, including widely used Web servers such as Nginx, Apache, and IIS; organizations such as Google, Akamai, CloudFlare, and Facebook; email and chat servers; network appliances from companies such as Cisco; and VPNs.

The disclosure of the bug triggered a frenzy of remedial activity across the industry and sparked concerns of major compromises. As Synopsys' Heartbleed.com site noted, Apache and Nginx alone accounted for a market share of over 66% of active sites on the Internet at the time Heartbleed was disclosed.

There's no telling, until Tuesday at least, if the new flaw will be anything like Heartbleed. But given the almost critical-infrastructure-like use of OpenSSL for encryption across the Internet, organizations would do well not to underestimate the threat, security experts said this week.

**Security Orgs Should Brace for Impact**

"It is a bit difficult to speculate about the impact, but past experience has shown that OpenSSL doesn't use the label 'critical' lightly," says Johannes Ullrich, dean of research at the SANS Institute.

OpenSSL itself defines a critical flaw as one that enables significant disclosure of the contents of server memory and potential user details, vulnerabilities that can be exploited easily and remotely to compromise server private keys.

Version 3.0, the current release of OpenSSL, is used in many current operating systems, such as Ubuntu 22.04 LTS and MacOS Mavericks and Ventura, Ullrich notes. Organizations can expect to receive Linux patches quickly and likely at the same time as the OpenSSL bulletin on Tuesday. But organizations should get ready now, finding out which systems use OpenSSL 3.0, Ullrich says. "After Heartbleed, OpenSSL introduced these preannouncements of security patches," he says. "They are supposed to help organizations prepare. So, use this time to find out what will need patching."

Brian Fox, co-founder and CTO at Sonatype, says that by the time the OpenSSL Project discloses the bug Tuesday, organizations need to identify if they are using a vulnerable version anywhere in their technology portfolio, which applications are using it, and how long it would take for them to remediate the issue. 

"Potential reach is always the most consequential piece of any major flaw," Fox notes. "In this instance, the largest challenge with updating OpenSSL is that often this usage is embedded inside of other devices." In these instances, it can be hard to assess exposure without asking the upstream provider of the technology, he adds.

Anything that communicates with the Internet securely could potentially have OpenSSL built in to it. And it's not just software that can be affected but hardware as well. The advance notice that the OpenSSL Project provided should give organizations time to prepare. "Finding what pieces of software or devices is the first step. Organizations should do that now, and then patching or sourcing updates from the upstream vendors will follow," Fox says. "All you can do at the moment is inventory."

**An Entire Ecosystem Might Need to Update**

A lot will also depend on how vendors of products with vulnerable versions of OpenSSL embedded in them respond to the disclosure. The OpenSSL Project's release of the new version on Tuesday is only the first step. "An entire ecosystem of applications built with OpenSSL will also have to update their code, release their own updates, and organizations will need to apply them," says John Bambenek, principal threat hunter at Netenrich.

Ideally, organizations that have dealt with Heartbleed will have an idea of where their OpenSSL installs are and which of their vendor products will require an update as well. "This is why software bills of materials can be important," Bambenek says. "They can take this time to reach out and understand their suppliers and vendors plans for updates to make sure those updates are applied as well." One likely issue that organizations need to be prepared for is how to deal with end-of-life products for which updates are not available, he adds.

Mike Parkin, senior technical engineer at Vulcan Cyber, says that without evidence of exploit activity and associated indicators of compromise, it is best that organizations follow their normal change management process for when a known update is on the way. "On the security side, it's worth putting some additional focus on systems that might be affected if an exploit emerges before the new release drops," he advises.

There's not enough information in OpenSSL Project's announcement to say how much work will be involved in the upgrade, "but unless it requires updating certificates, the upgrade will probably be straightforward," Parkin predicts.

Also on Nov. 1, the OpenSSL project will release OpenSSL version 1.1.1s, which it described as a "bug-fix release." Version 1.1.1, which it replaces, is not susceptible to the CVE that is being fixed in 3.0, the project noted.

Prepare Now for Critical Flaw in OpenSSL, Security Experts Warn

The implementation of backslash parsing in the Dart URI class for versions prior to 2.18 and Flutter versions prior to 3.30 differs from the WhatWG URL standards. Dart uses the RFC 3986 syntax, which creates incompatibilities with the '\' characters in URIs, which can lead to auth bypass in webapps interpreting URIs. We recommend updating Dart or Flutter to mitigate the issue.

Tag

#ssl