Multiple stored cross-site scripting vulnerabilities in the web user interface of IPFire versions prior to 2.27 allows a remote authenticated attacker with administrative privilege to inject an arbitrary script.

The next Core Update is released: IPFire 2.27 - Core Update 170. It features new IP blocklists for the firewall engine, significant improvements to Pakfire, modernizes the default cryptographic algorithm selection for IPsec connections, as well as a new kernel, and a plethora of bug fixes and security improvements under the hood.

**IP-Reputation Blocking to keep known threats out**

Based on prior development by Tim FitzGeorge, Stefan brought a new feature to the firewall engine, which allows the easy activation of various public IP-based blocklists, just by a single click.

All enabled blocklists are updated automatically at an appropriate interval (a technique we already deployed for updating IPS rulesets), and protect against various threats, such as IP addresses or networks having a poor reputation, being involved with cyber crime hosting, or simply not allocated, hence no traffic should be routed to and from them.

You probably wonder why IPFire now comes with yet another way for IP-based blocking. There are several motivations behind this:

*   IP blocklists are already available for the Intrusion Prevention System. However, it is a rather expensive way for dealing with network traffic that can already be safely dropped based on the reputation of involved IPs. There is no need to waste more CPU resources on it than absolutely necessary - why not let the firewall engine itself handle such traffic, and bother the IPS with more relevant stuff?
*   The "drop all traffic from and to hostile networks" feature is meant as a basic level of network protection suitable for IPFire's _entire_ user base, hence enabled by default. It protects against "the baddest of the bad" on the internet, and does not require any attention or maintenance whatsoever.
*   IP blocklists, as introduced with this Core Update, provide a more fine-grained level, and your mileage may vary: For example, blocking Tor traffic might be appropriate for some IPFire users, but certainly not for all of them. Some may find certain blocklists to be too aggressive for their use-case.

One size doesn't always fit all. The IP blocklist feature is IPFire's way of take this into account, and make further protection against network threats easy and resource-efficient.

**IPsec: MODP-2048 is ejected for new connections in favour of ECP-384/-521**

Following recommendations not to use Diffie-Hellman groups shorter than 3,000 bits after 2022, MODP-2048 has been dropped from the default cryptographic algorithm selection for new IPsec connections. To provide a more performant alternative to MODP-3072 and MODP-4096 and to be more compatible to other vendors in the default configuration, the NIST-standardized elliptic curves ECP-384 and ECP-521 have been added to the defaults for new IPsec connections.

Existing IPsec connections remain unchanged. However, IPFire users operating IPsec connections are advised to revise the cryptographic settings for these, and drop using weak algorithms, if possible.

**Linux Kernel 5.15.59**

Among bug fixes throughout the kernel including security fixes and hardware support improvements, the updated kernel also adds mitigations against Retbleed, another CPU vulnerability affecting various Intel and AMD processors. IPFire's web interface has been updated to display the mitigation state of Retbleed accordingly.

The following kernel-related changes have been made in addition:

*   On x86_64, Intel DMA Remapping Devices (better known as IOMMU) are enabled by default during boot, if available.
*   To reduce attack surface, legacy DRM drivers are no longer available. Since the respective kernel modules have already been blocklisted for a long time, thus unusable, this should not have an impact in production.
*   64-bit ARM users experience improved KASLR thanks to the kernel's memory address now being randomized before unpacking it (#12363).
*   Merging slab caches is no longer permitted, to prevent kernel heap overflows, and adversaries interfering with cache structures used by several programs.
*   Support for PCI pass-through has been enabled to allow mapping PCI devices into VMs running on IPFire (#12754).

**Miscellaneous**

*   Robin Roevens contributed a series of improvements to Pakfire, such as better error handling on downloads, and refactored a lot of code under the hood.
*   He also updated and improved the Zabbix agent add-on, which now features version 6.0.6 (LTS).
*   Support for assigning aliases to multiple RED interfaces has been added.
*   Non-unique hardware UUIDs as well as empty serial numbers are now ignored for computing Fireinfo profile IDs (#12896).
*   The blocklist of the University of Toulouse is now downloaded via HTTPS (#12891).
*   Logwatch summaries are now properly included in backups (#12827).
*   ncurses terminfo files for tmux are now properly shipped, resolving #12905.
*   All logged IPS events are now correctly displayed in the web interface (#12899).
*   Mount options of /boot have been hardened on both existing installations and new x86_64 IPFire instances.
*   On new installations, the partition's size has also been increased to 256 MiB, since components such as the kernel keep getting bigger and bigger.
*   amazon-ssm-agent is now available on 64-bit ARM as well.
*   pyfuse3 is now packaged for BorgBackup (#12611).
*   Two stored XSS vulnerabilities have been fixed, thanks to JPCERT for reaching out (#12925).
*   Updated packages: Bash 5.1.16, bind 9.16.31, GnuTLS 3.7.7, harfbuzz 4.4.1, hdparm 9.64, intel-microcode 20220809, kmod 30, krb5 1.20, logwatch 7.7, lsof 4.95.0, nano 6.4, ninja 1.11.0, OpenSSL 1.1.1q, rpcsvc-proto 1.4.3, screen 4.9.0, sqlite 33900000, suricata 5.0.10, unbound 1.16.2, usbutils 014, vim 9.0, xfsprogs 5.18.0, zlib to incorporate a fix for CVE-2022-37434.
*   Updated add-ons: ClamAV 0.105.1, fmt 9.0.0, git 2.37.1, gptfdisk 1.0.9, gutenprint 5.3.4, haproxy 2.6.0, htop 3.2.1, i2c-tools 4.3,iperf 2.1.7, mpd 0.23.8, NRPE 4.1.0, openvmtools 12.0.5, pcengines-apu-firmware 4.17.0.1, python3-cryptography 36.0.2, qemu 7.0.0, qemu-ga 7.0.0, rsync to patch CVE-2022-29154, Samba 4.16.4, shairport-sync 3cc1ec6

As always, we thank all people contributing to this release in whatever shape and form. Please note IPFire is backed by volunteers, maintaining and improving this distribution in their spare time - should you like what we are doing, please donate to keep the lights on, an consider becoming engaged in development to distribute the load over more shoulders.

CVE-2022-36368: IPFire 2.27 - Core Update 170 released - The IPFire Blog

Debian Linux Security Advisory 5257-2 - The security update announced as DSA 5257-1 caused regressions on certain systems using the amdgpu driver. Updated packages are now available to correct this issue.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA512

- -------------------------------------------------------------------------  
Debian Security Advisory DSA-5257-2                   security@debian.org  
https://www.debian.org/security/                     Salvatore Bonaccorso  
October 23, 2022                      https://www.debian.org/security/faq  
- -------------------------------------------------------------------------

Package        : linux  
Debian Bug     : 1022025

The security update announced as DSA 5257-1 caused regressions on  
certain systems using the amdgpu driver. Updated packages are now  
available to correct this issue.

For the stable distribution (bullseye), this problem has been fixed in  
version 5.10.149-2.

We recommend that you upgrade your linux packages.

For the detailed security status of linux please refer to its security  
tracker page at:  
https://security-tracker.debian.org/tracker/linux

Further information about Debian Security Advisories, how to apply  
these updates to your system and frequently asked questions can be  
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org  
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmNUyy5fFIAAAAAALgAo  
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2  
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xND  
z0TZ4xAAibsuLCjd0d0XfWQ24WZsI7I1wn1FvP/NRM3j8SEq/86uF80yiBmOeRoA  
5kDli4+cd/YwCrEHd+qoS597uUqV6kr6YUg2z/t/lvl//ZNDHegh2SmwXghISwmk  
E96Ix9CcLtEkNui5UeFbCRJqSnFmh5++CJE85tR3hq+GpbNYqoO0ZA5Cg26H2EXJ  
1S27U79fKgpFRj0GE/TFj/S6Uk2MxrfQ4vwv3Xm8n2b9f2eGVKI5f8cQu2jCCnzi  
IhavwMzC7WXRxNwrI/QoGRFjx6nCieFvEpO2aCsgKY5KPA7ecXBoI+w9ALSYVvAI  
/CIG4hppNbLxCgGr5VViXHmRwo17riMLyVc7B3OljlkZmwKAgkriHqlh/pU0uM6J  
By+MyjR9BNhH9ZA3Ry9+Y5rNNVmSqaTY3goRxSEeo29H/mZyTHE4Urdua7hNlLmU  
wWgA/sc4amF642fFjYV4m/zoyZmiPA3miyy/RnkzEHzV3+yPwX3kh/myJuPMmRb0  
YWF4Lr/iVINxyP6+O6MzsqdiAaa/uWJ5JBSdhzLP00dM/Sl0oGY1YJB0hehkftey  
hItI/v6C0GdUksWBtWrFJc4s/tiVThBONlvEd5ENmc1Cu2RVZWsJGdmsLoYBoMHS  
o1fEhq4zJijIiqfEGXEVdTBNfJQ/eMaEZ9R8ZYSLrc7FlnfJS64=  
=kbFE  
-----END PGP SIGNATURE-----

Debian Security Advisory 5257-2

The new open source specification from Open Compute Project is backed by Google, Nvidia, Microsoft, and AMD.

Some of the top names in the hardware industry have joined forces to create common technologies to enhance security in the cloud.

Google, Nvidia, Microsoft, and AMD partnered to establish Caliptra, an open specification to embed security mechanisms inside chips. The spec, which is open source and free to license, was announced on Tuesday at the Open Compute Project Summit, being held in Santa Clara, Calif. The participating companies are members of the Open Compute Project (OCP), which will maintain the development of the specification along with the Linux Foundation.

The Caliptra project revolves around establishing a root of trust (RoT) — building security layers into silicon so data is encrypted and not exposed as it travels in data centers or the cloud.  

"We need to embed that capability in silicon. At some point in the future, it's not going to be enough to have it on the motherboard, for example in the server as a separate piece of circuitry," said Cliff Grossner, vice president of market intelligence at OCP, during a press briefing.

Caliptra expands the security boundaries of data from the chip level to the cloud. The specification provides common language for chip makers and cloud providers to create technologies around confidential computing, which is gaining attention as a way to protect data while it is in storage, in transit, or being processed in the cloud.

"With the rise of edge computing, the resultant growth in the exposed attack surface also presents a need for stronger physical security solutions," wrote Mark Russinovich, Microsoft CTO for Azure, in a Tuesday blog post about Caliptra.

**Defining Open Source Confidential Computing**

Vulnerabilities like Spectre and Meltdown showed hackers could steal data by attacking hardware. Intel and AMD, whose CPUs dominate the data center and cloud infrastructure, are adding proprietary features to lock down data at the chip level, but Caliptra is being pitched as a viable open source alternative.

The specification defines a reusable silicon block that can be dropped into chips and devices to establish an RoT. The silicon block provides verifiable cryptographic assurances that the chip security configuration is correct. It also provides a mechanism within the chip to ensure that the boot code can be trusted.

"This represents an enhancement over existing solutions today, and we expect that this will meet the enhanced security requirements for edge and confidential computing going forward," OCP's Grossner said.

The specification includes mechanisms to protect data from a range of electromagnetic, side-channel, and other common attacks. But Caliptra does not cover emerging attack vectors like quantum computers, which will provide the means to crack advanced encryption in just seconds.

The Caliptra specification also covers major aspects of attestation, which is more of a chip-level handshake to ensure that only authorized parties get access to data stored in hardware enclaves. The RoT blocks in a chip isolate the data, while providing an effective mechanism to verify the authenticity and integrity of code, firmware, and other security assets.

**Securing the Enterprise Cloud**

The first Caliptra spec, version 0.5, can be prototyped on field-programmable gate arrays before being implemented into final chip designs. The specification document points to the technology being geared for enterprise computing infrastructures rather than home or business PCs.

The tenets of Caliptra, which include authentication, detection, and recovery, tilt heavily toward establishing a silicon RoT for server and edge chips, which are built differently than PC chips.

Microsoft is using attestation based on Trusted Platform Module (TPM) chips as a security mechanism for Windows 10 and 11 operating systems. The company's Pluton security chip, which has a TPM built in and can be used for attestation, has largely been rejected by the wider PC industry.

Microsoft and Google executives didn't say whether or when they would make Caliptra a part of their cloud services. Microsoft last week expanded the use of AMD's SNP-SEV technology for confidential computing in the cloud. Azure also offers virtual machine instances with Intel's proprietary SGX security enclave.

**Expanding the Open Compute Project**

The Open Compute Project was established in 2011 by the likes of Google and Meta (then Facebook), which were buying thousands of servers and looking to standardize on hardware designs in their mega data centers. The goal was to reduce the server build times and cut costs by stripping off unnecessary components.

OCP has since grown into a powerhouse that counts all major infrastructure hardware providers as members — with the exception of Apple and Amazon, which rely on internally designed hardware.

OCP guidelines also include power, cooling, storage, and networking specifications that are now widely adopted. The OCP has also inspired nontech companies, largely in the financial sector, to experiment and develop standardized servers for on-premises data centers.

"We have the industry leaders coming together here within the OCP community, and we want to bring the standardized facility architecture for deployed servers," Grossner said. "Server security will become scalable."

Servers previously largely depended on CPUs, but now include different computing devices such as GPUs to handle applications like artificial intelligence. Standardizing the server security architecture was a top priority for company executives addressing media during the OCP call.

"This ecosystem we all play in — it starts with trust you have ... in your computing. We were on a path to have a number of bifurcated solutions, and that's just not good for anyone," said Mark Papermaster, chief technology officer at AMD, during the call.

Hardware Makers Standardize Server Chip Security With Caliptra

Microsoft highlighted emerging confidential computing offerings for Azure during its Ignite conference.

Microsoft is putting hardware in charge of data protection in Azure to help customers feel confident about sharing data with authorized parties within the cloud environment. The company made a series of hardware security announcements at its Ignite 2022 conference this week to highlight Azure's confidential computing offerings.

Confidential computing involves creating a Trusted Execution Environment (TEE), essentially a black box to hold encrypted data. In a process called attestation, authorized parties can place code inside the box to decrypt and access the information without first having to move the data out of the protected space. The hardware-protected enclave creates a trustworthy environment in which data is tamper-proof, and the data isn't accessible to even those with physical access to the server, a hypervisor, or even an application.

"It's really kind of the ultimate in data protection," Mark Russinovich, Microsoft Azure's chief technology officer, said at Ignite.

**On Board With AMD's Epyc**

Several of Microsoft's new hardware security layers take advantage of on-chip features included in Epyc — the server processor from Advanced Micro Devices deployed on Azure.

One such feature is SEV-SNP, which encrypts AI data when in a CPU. Machine-learning applications move data continuously between a CPU, accelerators, memory, and storage. AMD's SEV-SNP ensures data security inside the CPU environment, while locking off access to that information as it goes through the execution cycle.

AMD's SEV-SNP feature closes a critical gap so data is secure at all layers while residing or moving in the hardware. Other chip makers have largely focused on encrypting data while in storage and in transit on communication networks, but AMD's features secure data while being processed in the CPU.

That offers multiple benefits, and companies will be able to mix proprietary data with third-party datasets residing in other secure enclaves on Azure. The SEV-SNP features use attestation to ensure incoming data is in its exact form from a relying party and can be trusted.

"This is enabling net new scenarios and confidential computing that was not possible before," said Amar Gowda, principal product manager at Microsoft Azure, during an Ignite webcast.

For example, banks will be able to share confidential data without the fear of anyone stealing it. The SEV-SNP feature will bring encrypted bank data into the secure third-party enclave where it could mingle with datasets from other sources.

"Because of this attestation and memory protection and integrity protection, you can rest assured that the data does not leave the boundaries in the wrong hands. The whole thing is about how do you enable new offerings on top of this platform," Gowda said.

**Hardware Security on Virtual Machines**

Microsoft also added additional security for cloud-native workloads, and the non-exportable encryption keys generated using SEV-SNP are a logical fit for enclaves where data is transient and not retained, James Sanders, principal analyst for cloud, infrastructure, and quantum at CCS Insight, says in a conversation with Dark Reading.

"For Azure Virtual Desktop, SEV-SNP adds an additional layer of security for virtual-desktop use cases, including bring-your-own-device workplaces, remote work, and graphics-intensive applications," Sanders says.

Some workloads haven't moved to the cloud because of regulation and compliance limitations tied to data privacy and security. The hardware security layers will allow companies to migrate such workloads without compromising their security posture, Run Cai, a principal program manager at Microsoft, said during the conference.

Microsoft also announced that the Azure virtual desktop with confidential VM was in public preview, which will be able to run Windows 11 attestation on confidential VMs.

"You can use secure remote access with Windows Hello and also secure access to Microsoft Office 365 applications within confidential VMs," Cai said.

Microsoft has been dabbling with the use of AMD's SEV-SNP in general-purpose VMs from earlier this year, which was a good start, CCS Insight's Sanders says.

Adoption of SEV-SNP is also important validation for AMD among data center and cloud customers, as previous efforts at confidential computing relied on partial secure enclaves rather than protecting the entire host system.

"This was not straightforward to configure, and Microsoft left it to partners to provide security solutions that leveraged in-silicon security features," Sanders says.

Microsoft's Russinovich said that Azure services to manage hardware and deployment of code for confidential computing are coming. Many of those managed services will be based on Confidential Consortium Framework, which is a Microsoft-developed open source environment for confidential computing.

"Managed service is in preview form ... we've got customers that are kicking the tires on it," Russinovich said.

Microsoft Secures Azure Enclaves With Hardware Guards

Confidential Containers (CoCo) is a new sandbox project of the Cloud Native Computing Foundation (CNCF) that enables cloud-native confidential computing by taking advantage of a variety of hardware platforms and technologies.

Confidential Containers (CoCo) is a new sandbox project of the Cloud Native Computing Foundation (CNCF) that enables cloud-native confidential computing by taking advantage of a variety of hardware platforms and technologies. The project brings together software and hardware companies including Alibaba-cloud, AMD, ARM, IBM, Intel, Microsoft, Red Hat, Rivos and others.  

The CoCo project builds on existing and emerging hardware security technologies such as Intel SGX, Intel TDX, AMD SEV and IBM Z Secure Execution, in combination with new software frameworks **to help better secure user data in use**. This will establish a new level of confidentiality, which does not rely on trust in the cloud providers and their employees, but on hardware-level cryptography. CoCo will support multiple environments including public clouds, on-premise and edge computing.

The goal of the CoCo project is to **standardize** confidential computing at the container level and **simplify** its consumption in Kubernetes. This is in order to enable Kubernetes users to deploy confidential container workloads using familiar workflows and tools without extensive knowledge of underlying confidential computing technologies.

The CoCo project aims to integrate Trusted Execution Environments (TEE) infrastructure with the cloud-native world. A TEE is at the heart of a confidential computing solution. TEEs are isolated environments with enhanced security, provided by confidential computing (CC) capable hardware that prevents unauthorized access or modification of applications and data while in use. You’ll also hear the terms "enclaves", "trusted enclaves" or "secure enclaves." In the context of confidential containers, these terms are used interchangeably.

**What does this actually mean?** 

Using CoCo, you will be able to deploy your workload on infrastructure owned by someone else, significantly reducing the risk of any unauthorized entity accessing your workload data and extracting your secrets. The infrastructure can be owned by a cloud provider, a different division in your organization such as the IT department or even an untrusted third party. This new level of confidentiality is achieved by, among other things, encrypting the computer’s memory and protecting other low level resources your workload requires at the hardware level. This includes the state of the CPU, physical memory, interrupts and more. Cryptography-based proofs help validate that no one has tampered with your workload, loaded software you did not want, read or modified the memory used by your workload, injected a malicious CPU state to attempt to derail your software or succeeded in doing anything out of order. In short, CoCo helps confirm that if either your software runs without being tampered with or it fails to run you will know about it.

For additional details see the CoCo project overview. 

In this blog we will focus on the first community release targeted for September 2022. The next sections provide more insight into what are the goals of this release and the supported use cases. We will also give a short overview of the architecture components supported in this release. 

Detailed release notes are available on the confidential containers GitHub repository.

**Goals of the first release**

This release focuses on the following:

*   **Simplicity** - Using a dedicated Kubernetes operator, the CoCo operator, for deployment and configuration. Our goal is to make this technology as accessible as possible hiding away most of the hardware-dependent parts 
    
*   **Stability** \- Supporting continuous integration (CI) for the key workflows of the release. We want to ensure that as the community grows and more contributors join, existing use cases remain stable.
    
*   **Documentation** - Detailed and clear instruction of how to deploy and use this release. Confidential computing is a vast and evolving field with many acronyms, building blocks and technology layers. We’d like to provide the users with enough information to understand and try out the use cases we describe.
    

Non-goals for the release include:

*   Full support and CI testing for all commonly used hardware architectures.
    
*   Performance and resource optimizations
    
*   Full integration with third-party services for attestation or key brokering
    
*   Full functionality and security features for all standard Kubernetes tools: some commands, notably those that access sensitive data in the workload, may either fail to function (being blocked for security reasons), or still route data through insecure channels.
    
*   Support for upstream versions of containerd and CRIO (this release relies on a customized version of containerd, which the operator installs for you)
    

We expect these limitations to be addressed in subsequent releases.

**Use cases supported in this release**

This release supports the following use cases:

*   Creating a sample CoCo workload
    
*   Creating a CoCo workload using a pre-existing encrypted image
    
*   Creating a CoCo workload using a pre-existing encrypted image on hardware with support for Confidential Computing (CC HW)
    
*   Building a new encrypted container image and deploying it as a CoCo workload
    

**Some insight into the CoCo architecture **

The following diagram provides a high level view of the main components the CoCo solution consists of and interact with: 

The CoCo solution embeds a Kubernetes pod inside a virtual machine (VM) together with an engine called the _**enclave software stack**_. There is a one-to-one mapping between a Kubernetes pod and a VM-based TEE (or enclave). The container images are kept inside the enclave and can be either signed or encrypted.

The **enclave software stack** is _**measured**_, which means that a  trusted cryptographic algorithm is used to authenticate its content. It contains the _**enclave agent**_ which is responsible for initiating attestation and fetching of the secrets from the key management service.

Supporting components for the solution are the _**container image registry**_ and the _**relying party**_, which combines the _**attestation service**_ and _**key management service**_.

The **container image registry** is responsible for storing and delivering encrypted container images. A container image typically contains multiple layers, and each layer is encrypted separately. At least one layer needs to be encrypted for the workload to be efficiently protected.

The **attestation service** is responsible for checking the measurement of the enclave software stack against a list of approved workloads, and authorize or deny the delivery of keys.

The **key management service** is responsible for storing secrets that the workload needs in order to run, such as disk decryption keys, and for delivering these secrets to the enclave agent.

After the VM has been launched, we can then summarize the flow CoCo follows in the following 4 steps (colored in red in the diagram above):

1.  The enclave agent sends a request to the attestation service. The attestation service responds with a cryptographic challenge for the agent to prove the workload’s identity using the measurement of the enclave. If the enclave agent responds to this challenge successfully, the attestation service notifies the key management service that secrets can be delivered.
    
2.  If the workload is authorized to run, the key management service finds the secrets corresponding to the workload, and sends them to the agent. Among the necessary secrets are the decryption keys for the disks being used.
    
3.  The image management service inside the enclave downloads container images from the container images registry, verifies them, and decrypts them locally to encrypted storage. At that point, the container images become usable by the enclave.
    
4.  The enclave software stack creates a pod and containers inside the virtual machine, and starts running the containers (all containers within the pod are secured).
    

**Why is Red Hat investing in this project? **

As part of the move to open hybrid cloud and in an effort to consolidate its relevant security aspects, advancement in technology allows our customers to further protect the data in use by providing an additional layer of encryption. There are certain industries that are highly sensitive and need additional protection for their workloads. As regulatory environments change, Red Hat intends to provide the necessary tools.

Red Hat believes that confidential computing can be a game changer for software manufacturers and cloud providers. It combines the advantages of cloud and on-premise while keeping the processes simple.

CoCo makes these new technologies easier to consume. Being able to transparently integrate confidential containers in Red Hat OpenShift, which is built on Kubernetes, is expected to become an important addition to the Red Hat product portfolio.

What is the Confidential Containers project? 

Hello everyone! Five years ago I wrote a blogpost about OpenSCAP. But it was only about the SCAP Workbench GUI application and how to use it to detect security misconfigurations. Alternative video link (for Russia): https://vk.com/video-149273431_456239104 This time, I will install the OpenSCAP command line tool on Ubuntu and use it to check for vulnerabilities […]

Hello everyone! Five years ago I wrote a blogpost about OpenSCAP. But it was only about the SCAP Workbench GUI application and how to use it to detect security misconfigurations.

Alternative video link (for Russia): https://vk.com/video-149273431\_456239104

This time, I will install the OpenSCAP command line tool on Ubuntu and use it to check for vulnerabilities on my local host.

**Installation**

First of all, we need to install OpenSCAP. I have Ubuntu 20.04.5 LTS on my host.

    $ lsb_release -a
    No LSB modules are available.
    Distributor ID:	Ubuntu
    Description:	Ubuntu 20.04.5 LTS
    Release:	20.04
    Codename:	focal

According to the official OpenSCAP website oscap tool can be installed on Ubuntu with the command apt-get install libopenscap8.

    $ sudo apt-get install libopenscap8
    [sudo] password for alexander: 
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following packages were automatically installed and are no longer required:
      libfwupdplugin1 python3-defusedxml python3-pyqt5.qtopengl python3-zmq
    Use 'sudo apt autoremove' to remove them.
    The following NEW packages will be installed:
      libopenscap8
    0 upgraded, 1 newly installed, 0 to remove and 31 not upgraded.
    Need to get 2,483 kB of archives.
    After this operation, 66.2 MB of additional disk space will be used.
    Get:1 http://ru.archive.ubuntu.com/ubuntu focal-updates/universe amd64 libopenscap8 amd64 1.2.16-2ubuntu3.2 [2,483 kB]
    Fetched 2,483 kB in 0s (5,700 kB/s)    
    Selecting previously unselected package libopenscap8.
    (Reading database ... 290720 files and directories currently installed.)
    Preparing to unpack .../libopenscap8_1.2.16-2ubuntu3.2_amd64.deb ...
    Unpacking libopenscap8 (1.2.16-2ubuntu3.2) ...
    Setting up libopenscap8 (1.2.16-2ubuntu3.2) ...
    Processing triggers for man-db (2.9.1-1) ...
    Processing triggers for libc-bin (2.31-0ubuntu9.9) ...

We can then check that the installation was successful with the command oscap -V

    $ oscap -V
    OpenSCAP command line tool (oscap) 1.2.16
    Copyright 2009--2017 Red Hat Inc., Durham, North Carolina.
    
    ==== Supported specifications ====
    XCCDF Version: 1.2
    OVAL Version: 5.11.1
    CPE Version: 2.3
    CVSS Version: 2.0
    CVE Version: 2.0
    Asset Identification Version: 1.1
    Asset Reporting Format Version: 1.1
    CVRF Version: 1.1
    ...

Everything looks good and now we need to get the content describing the vulnerability checks. It’s great that Canonical has invested in creating free OVAL content feeds that can be downloaded from https://ubuntu.com/security/oval.

We download the content with wget.

    $ wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
    --2022-10-01 14:00:00--  https://security-metadata.canonical.com/oval/com.ubuntu.focal.usn.oval.xml.bz2
    Resolving security-metadata.canonical.com (security-metadata.canonical.com)... 185.125.190.20, 185.125.190.29, 185.125.190.21, ...
    Connecting to security-metadata.canonical.com (security-metadata.canonical.com)|185.125.190.20|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 276068 (270K) [application/x-bzip2]
    Saving to: ‘com.ubuntu.focal.usn.oval.xml.bz2’
    
    com.ubuntu.focal.usn.oval.xml.bz2               100%[=======================================================================================================>] 269.60K  1.35MB/s    in 0.2s    
    
    2022-10-01 14:00:00 (1.35 MB/s) - ‘com.ubuntu.focal.usn.oval.xml.bz2’ saved [276068/276068]

Unzip the data using bunzip2 tool:

    $ bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
    $ ls com.ubuntu.*
    com.ubuntu.focal.usn.oval.xml

**Vulnerability report**

We can use the oscap tool to create an html vulnerability report. The tool shows the OVAL definition statuses while it is running.

    $ oscap oval eval --report report.html com.ubuntu.$(lsb_release -cs).usn.oval.xml
    Definition oval:com.ubuntu.focal:def:891000000: false
    Definition oval:com.ubuntu.focal:def:871000000: false
    Definition oval:com.ubuntu.focal:def:861000000: false
    Definition oval:com.ubuntu.focal:def:851000000: false
    Definition oval:com.ubuntu.focal:def:841000000: false
    ...
    Definition oval:com.ubuntu.focal:def:43322000000: false
    Definition oval:com.ubuntu.focal:def:43302000000: false
    Definition oval:com.ubuntu.focal:def:41716000000: false
    Definition oval:com.ubuntu.focal:def:100: true
    Evaluation done.

In this example, oscap has detected a vulnerability in the Firefox web browser.

And after updating the Firefox package on the host, this vulnerability disappears.

If you want to automatically process scan results, you can export them in XML format.

    $ oscap oval eval --results oval-results.xml com.ubuntu.$(lsb_release -cs).usn.oval.xml

**Separating Inventory and Vulnerability Detection: System Characteristics**

In most cases, using OpenSCAP looks like this. You install the OpenSCAP package on a target Linux host, copy the OVAL content to the host, and detect vulnerabilities directly on the host. You can then collect these results from the host and put them into some kind of vulnerability storage and prioritization solution.

Can we separate inventory collection from actual vulnerability detection? Yes, it is possible with the OVAL System Characteristics. The idea is that we collect inventory host data in a special XML format and then pass it as a parameter to the oscap tool. How does oscap know which objects to collect? It understands this from the same OVAL definition file.

So, we collect System Characteristics with

    $ oscap oval collect --syschar syschar.xml  com.ubuntu.$(lsb_release -cs).usn.oval.xml
    Collected: "oval:com.ubuntu.focal:obj:8910000001" : does not exist
    Collected: "oval:com.ubuntu.focal:obj:8910000000" : does not exist
    Collected: "oval:com.ubuntu.focal:obj:8710000001" : does not exist
    ...
    Collected: "oval:com.ubuntu.focal:obj:564910000000" : complete
    Collected: "oval:com.ubuntu.focal:obj:564810000010" : complete
    Collected: "oval:com.ubuntu.focal:obj:564810000000" : complete
    ...
    Collected: "oval:com.ubuntu.focal:obj:100" : complete

And then analyse and generate a report from it

    $ oscap oval analyse --results oval-results.xml com.ubuntu.$(lsb_release -cs).usn.oval.xml syschar.xml
    $ oscap oval generate report oval-results.xml > ssg-scan-oval-report.html

Therefore, it is theoretically possible to learn how to generate syschar.xml files without using the oscap utility and implement **fully agent-less remote scan**. But this is one for the future.

**System Characteristics Errors**

Unfortunately, there were bugs during testing of oscap 1.2.16. The System Characteristics syschar.xml has been created successfully. But attempts to analyze it with oscap led to errors:

    $ oscap oval analyse --results oval-results.xml com.ubuntu.$(lsb_release -cs).usn.oval.xml syschar.xml
    E: oscap:     Error occured when comparing a variable 'oval:com.ubuntu.focal:var:564810000000' value '0:5.4.0-126' with collected item entity = '0:5.15.0-1016'
    E: oscap:     Error occured when comparing a variable 'oval:com.ubuntu.focal:var:564710000000' value '0:5.4.0-126' with collected item entity = '0:5.4.0-1089'
    E: oscap:     Error occured when comparing a variable 'oval:com.ubuntu.focal:var:564410000000' value '0:5.4.0-126' with collected item entity = '0:5.15.0-1018'
    ...
    OpenSCAP Error: Invalid type of operation in string evaluation: 6. [../../../../src/OVAL/results/oval_cmp_basic.c:195]

At the same time, oval-results.xml was created and it was possible to generate an html report from it. But some of the checks are displayed in the error state.

I suspect that the problem is in the current version of oscap in the Ubuntu repository (1.2.16) and in the current actual version 1.3.6 it may work, but this needs to be checked. To do this, OpenSCAP should be installed from source.

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.

А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.

How to Perform a Free Ubuntu Vulnerability Scan with OpenSCAP and Canonical’s Official OVAL Content

The previously identified ransomware builder has veered in an entirely new direction, targeting consumers and business of all sizes by exploiting known CVEs through brute-forced and/or stolen SSH keys.

The powerful Chaos malware has evolved yet again, morphing into a new Go-based, multiplatform threat that bears no resemblance to its previous ransomware iteration. It's now targeting known security vulnerabilities to launch distributed denial-of-service (DDoS) attacks and perform cryptomining.

Researchers from Black Lotus Labs, the threat intelligence arm of Lumen Technologies, recently observed a version of Chaos written in Chinese, leveraging China-based infrastructure, and exhibiting behavior far different than the last activity seen by the ransomware-builder of the same name, they said in a blog post published Sept. 28.

Indeed, the distinctions between earlier variants of Chaos and the 100 distinct and recent Chaos clusters that researchers observed are so different that they say it poses a brand-new threat. In fact, researchers believe the latest variant is actually the evolution of the DDoS botnet Kaiji and perhaps "distinct from the Chaos ransomware builder" previously seen in the wild, they said.

Kaiji, discovered in 2020, originally targeted Linux-based AMD and i386 servers by leveraging SSH brute-forcing to infect new bots and then launch DDoS attacks. Chaos has evolved Kaiji's original capabilities to include modules for new architectures — including Windows — as well as adding new propagation modules through CVE exploitation and SSH key harvesting, the researchers said.

**Recent Chaos Activity**

In recent activity, Chaos successfully compromised a GitLab server and unfurled a flurry of DDoS attacks targeting the gaming, financial services and technology, and media and entertainment industries, along with DDoS-as-a-service providers and a cryptocurrency exchange.

Chaos is now targeting not only enterprise and large organizations but also "devices and systems that aren't routinely monitored as part of an enterprise security model, such as SOHO routers and FreeBSD OS," the researchers said.

And while the last time Chaos was spotted in the wild it was acting more as typical ransomware that entered networks with the purpose of encrypting files, the actors behind the latest variant have very different motives in mind, the researchers said.

Its cross-platform and device functionality as well as the stealth profile of the network infrastructure behind the latest Chaos activity appears to demonstrate that the aim of the campaign is to cultivate a network of infected devices to leverage for initial access, DDoS attacks, and cryptomining, according to the researchers.

**Key Differences, and One Similarity**

While previous samples of Chaos were written in .NET, the latest malware is written in Go, which is rapidly becoming a language of choice for threat actors due to its cross-platform flexibility, low antivirus detection rates, and difficulty to reverse-engineer, the researchers said.

And indeed, one of the reasons that the latest version of Chaos is so powerful is because it operates across multiple platforms, including not only Windows and Linux operating systems but also ARM, Intel (i386), MIPS, and PowerPC, they said.

It also propagates in a far different way than previous versions of the malware. While researchers were unable to ascertain its initial access vector, once it takes hold of a system, the latest Chaos variants exploit known vulnerabilities in a way that shows the ability to pivot quickly, the researchers noted.

"Among the samples we analyzed were reported CVEs for Huawei (CVE-2017-17215) and Zyxel (CVE-2022-30525) personal firewalls, both of which leveraged unauthenticated remote command line injection vulnerabilities," they observed in their post. "However, the CVE file appears trivial for the actor to update, and we assess it is highly likely the actor leverages other CVEs."

Chaos has indeed gone through numerous incarnations since it first emerged in June 2021 and this latest version is not likely to be its last, the researchers said. Its first iteration, Chaos Builder 1.0-3.0, purported to be a builder for a .NET version of the Ryuk ransomware, but the researchers soon noticed it bore little resemblance to Ryuk and was actually a wiper.

The malware evolved across several versions until version four of the Chaos builder that was released in late 2021 and got a boost when a threat group named Onyx created its own ransomware. This version quickly became the most common Chaos edition directly observed in the wild, encrypting some files but maintain overwritten and destroying most of the files in its path.

Earlier this year in May, the Chaos builder traded its wiper capabilities for encryption, surfacing with a rebranded binary dubbed Yashma that incorporated fully fledged ransomware capabilities.

While the most recent evolution of Chaos witnessed by Black Lotus Labs is far different, it does have one significant similarity with its predecessors — rapid growth that is unlikely to slow anytime soon, the researchers said.

The earliest certificate of the latest Chaos variant was generated on April 16; this is subsequently when researchers believe threat actors launched the new variant in the wild.

Since then, the number of Chaos self-signed certificates has shown "marked growth," more than doubling in May to 39 and then jumping to 93 for the month of August, the researchers said. As of Sept. 20, the current month has already surpassed the previous month's total with the generation of 94 Chaos certificates, they said.

**Mitigating Risk Across the Board**

Because Chaos is now attacking victims from the smallest home offices to the largest enterprises, researchers made specific recommendations for each type of target.

For those defending networks, they advised that network administrators stay on top of patch management for newly discovered vulnerabilities, as this is a principal way Chaos spreads.

"Use the IoCs outlined in this report to monitor for a Chaos infection, as well as connections to any suspicious infrastructure," the researchers recommended.

Consumers with small office and home office routers should follow best practices of regularly rebooting routers and installing security updates and patches, as well as leveraging properly configured and updated EDR solutions on hosts. These users also should regularly patch software by applying vendors' updates where applicable.

Remote workers — an attack surface that has significantly increased over the last two years of the pandemic — also are at risk, and should mitigate it by changing default passwords and disabling remote root access on machines that don't require it, the researchers recommended. Such workers also should store SSH keys securely and only on devices that require them.

For all businesses, Black Lotus Labs recommends considering the application of comprehensive secure access service edge (SASE) and DDoS mitigation protections to bolster their overall security postures and enable robust detection on network-based communications.

Chaos Malware Resurfaces With All-New DDoS & Cryptomining Modules

Hertz v0.3.0 ws discovered to contain a path traversal vulnerability via the normalizePath function.

Copy link

Contributor

** **ruokeqx** commented Sep 4, 2022 •**

**What type of PR is this?**

fix: A bug fix

**Check the PR title.**

*   This PR title match the format: (optional scope):
    
*   The description of this PR title is user-oriented and clear enough for others to understand.
    

**(Optional) Translate the PR title into Chinese.**

修复目录穿越漏洞

**(Optional) More detail description for this PR(en: English/zh: Chinese).**

en: fix by simply replace all backslashes with forward slashes  
zh(optional): 将反斜杠全部改成正斜杠

**Which issue(s) this PR fixes:**

Fixes #228

Currently hertz has no restriction on backslash in normalizePath function.

func normalizePath(dst, src \[\]byte) \[\]byte {
	dst \= dst\[:0\]
	dst \= addLeadingSlash(dst, src)
	dst \= decodeArgAppendNoPlus(dst, src)

	// remove duplicate slashes
	b := dst
	bSize := len(b)
	for {
		n := bytes.Index(b, bytestr.StrSlashSlash)
		if n < 0 {
			break
		}
		b \= b\[n:\]
		copy(b, b\[1:\])
		b \= b\[:len(b)\-1\]
		bSize\--
	}
	dst \= dst\[:bSize\]

	// remove /./ parts
	b \= dst
	for {
		n := bytes.Index(b, bytestr.StrSlashDotSlash)
		if n < 0 {
			break
		}
		nn := n + len(bytestr.StrSlashDotSlash) \- 1
		copy(b\[n:\], b\[nn:\])
		b \= b\[:len(b)\-nn+n\]
	}

	// remove /foo/../ parts
	for {
		n := bytes.Index(b, bytestr.StrSlashDotDotSlash)
		if n < 0 {
			break
		}
		nn := bytes.LastIndexByte(b\[:n\], '/')
		if nn < 0 {
			nn \= 0
		}
		n += len(bytestr.StrSlashDotDotSlash) \- 1
		copy(b\[nn:\], b\[n:\])
		b \= b\[:len(b)\-n+nn\]
	}

	// remove trailing /foo/..
	n := bytes.LastIndex(b, bytestr.StrSlashDotDot)
	if n \>= 0 && n+len(bytestr.StrSlashDotDot) \== len(b) {
		nn := bytes.LastIndexByte(b\[:n\], '/')
		if nn < 0 {
			return bytestr.StrSlash
		}
		b \= b\[:nn+1\]
	}

	return b
}

After:

func normalizePath(dst, src \[\]byte) \[\]byte {
	// replace all backslashes with forward slashes
	for {
		n := bytes.Index(src, bytestr.StrBackSlash)
		if n < 0 {
			break
		}
		src\[n\] \= '/'
	}
	...
}

**Codecov Report**

> Merging #229 (4ecd30e) into develop (8751608) will **decrease** coverage by 0.02%.  
> The diff coverage is 0.00%.

@@             Coverage Diff             @@
#\#           develop     #229      +/-   ##
===========================================
\- Coverage    59.19%   59.17%   -0.03%     
===========================================
  Files           79       79              
  Lines         8105     8110       +5     
===========================================
+ Hits          4798     4799       +1     
\- Misses        2953     2957       +4     
  Partials       354      354              

Impacted Files

Coverage Δ

pkg/protocol/uri.go

70.34% <0.00%> (-0.72%)

⬇️

pkg/network/standard/buffer.go

81.08% <0.00%> (-0.50%)

⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Copy link

Contributor Author

****ruokeqx** commented Sep 4, 2022**

Copy link

Contributor Author

****ruokeqx** commented Sep 4, 2022**

> When checking other http framework source code, I find that fasthttp community fix the same bug six months ago. Maybe we can borrow some code.
> 
> valyala/fasthttp#1226 valyala/fasthttp@6b5bc7b

They just repeat the logic, there is no need to write duplicate code.  
The point is that backslash also work in windows. So, essentially, we just need to replace the backslash with forward slash, by which we, to some extent, limit the separator.  
In my limited point of view, my fix is better.

@@ -480,6 +480,15 @@ func splitHostURI(host, uri \[\]byte) (\[\]byte, \[\]byte, \[\]byte) {

}

  

func normalizePath(dst, src \[\]byte) \[\]byte {

// replace all backslashes with forward slashes

for {

n := bytes.Index(src, bytestr.StrBackSlash)

**Choose a reason for hiding this comment**

The reason will be displayed to describe this comment to others. Learn more.

1.  Seems it will double check for bytes that have been replaced, is this an performance issue on long paths?
2.  I'm not sure it's a good idea to replace src in place, maybe it's hard to understand that if normalizePath has a return value and also modifies the input parameters.

**Choose a reason for hiding this comment**

The reason will be displayed to describe this comment to others. Learn more.

> 1.  Seems it will double check for bytes that have been replaced, is this an performance issue on long paths?
> 2.  I'm not sure it's a good idea to replace src in place, maybe it's hard to understand that if normalizePath has a return value and also modifies the input parameters.

maybe this one would be better

func normalizePath(dst, src \[\]byte) \[\]byte {
	dst \= dst\[:0\]
	dst \= addLeadingSlash(dst, src)
	dst \= decodeArgAppendNoPlus(dst, src)

	// replace all backslashes with forward slashes
	if filepath.Separator \== '\\\\' {
		for i := range dst {
			if dst\[i\] \== '\\\\' {
				dst\[i\] \= '/'
			}
		}
	}
	...
}

BTW: echo use function filepath.ToSlash

https://github.com/labstack/echo/blob/master/context\_fs.go#L33

func ToSlash(path string) string {
	if Separator \== '/' {
		return path
	}
	return strings.ReplaceAll(path, string(Separator), "/")
}

**Choose a reason for hiding this comment**

The reason will be displayed to describe this comment to others. Learn more.

bytes.IndexByte will do a SIMD accelerate in some platforms. Not sure which one is better.

And since the bug only happens in Windows? Maybe add a if filepath.Separator == '\\' { to filter the platform?

The example/standard demo seems still have the problem in Windows if the url is : 127.0.0.1:8888/..%5c..%5cgo.sum

Copy link

Contributor Author

****ruokeqx** commented Sep 5, 2022 •**

> The example/standard demo seems still have the problem in Windows if the url is : 127.0.0.1:8888/..%5c..%5cgo.sum

this version solve the problem

func normalizePath(dst, src \[\]byte) \[\]byte {
	dst \= dst\[:0\]
	dst \= addLeadingSlash(dst, src)
	dst \= decodeArgAppendNoPlus(dst, src)

	// replace all backslashes with forward slashes
	if filepath.Separator \== '\\\\' {
		for i := range dst {
			if dst\[i\] \== '\\\\' {
				dst\[i\] \= '/'
			}
		}
	}
	...
}

before the if judgment  
src = "/..%5c..%5cgo.sum"  
dst = "//..\\..\\go.sum"

curl -v 127.0.0.1:8888/..%5c..%5cgo.sum
\*   Trying 127.0.0.1:8888...
\* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
\> GET /..%5c..%5cgo.sum HTTP/1.1
\> Host: 127.0.0.1:8888
\> User-Agent: curl/7.83.1
\> Accept: \*/\*
\>
\* Mark bundle as not supporting multiuse
< HTTP/1.1 404 404 Page not found
< Date: Mon, 05 Sep 2022 09:10:07 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 26
<
Cannot open requested path\* Connection #0 to host 127.0.0.1 left intact

> > The example/standard demo seems still have the problem in Windows if the url is : 127.0.0.1:8888/..%5c..%5cgo.sum
> 
> this version solve the problem
> 
> func normalizePath(dst, src \[\]byte) \[\]byte {
> 	dst \= dst\[:0\]
> 	dst \= addLeadingSlash(dst, src)
> 	dst \= decodeArgAppendNoPlus(dst, src)
> 
> 	// replace all backslashes with forward slashes
> 	if filepath.Separator \== '\\\\' {
> 		for i := range dst {
> 			if dst\[i\] \== '\\\\' {
> 				dst\[i\] \= '/'
> 			}
> 		}
> 	}
> 	...
> }
> 
> before the if judgment src = "/..%5c..%5cgo.sum" dst = "//....\\go.sum"
> 
> curl -v 127.0.0.1:8888/..%5c..%5cgo.sum
> \*   Trying 127.0.0.1:8888...
> \* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
> \> GET /..%5c..%5cgo.sum HTTP/1.1
> \> Host: 127.0.0.1:8888
> \> User-Agent: curl/7.83.1
> \> Accept: \*/\*
> \>
> \* Mark bundle as not supporting multiuse
> < HTTP/1.1 404 404 Page not found
> < Date: Mon, 05 Sep 2022 09:10:07 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 26
> <
> Cannot open requested path\* Connection #0 to host 127.0.0.1 left intact

Good job! As for the performance part, maybe do a bench test to see the answer.

Copy link

Contributor Author

****ruokeqx** commented Sep 5, 2022**

> > > The example/standard demo seems still have the problem in Windows if the url is : 127.0.0.1:8888/..%5c..%5cgo.sum
> > 
> > this version solve the problem
> > 
> > func normalizePath(dst, src \[\]byte) \[\]byte {
> > 	dst \= dst\[:0\]
> > 	dst \= addLeadingSlash(dst, src)
> > 	dst \= decodeArgAppendNoPlus(dst, src)
> > 
> > 	// replace all backslashes with forward slashes
> > 	if filepath.Separator \== '\\\\' {
> > 		for i := range dst {
> > 			if dst\[i\] \== '\\\\' {
> > 				dst\[i\] \= '/'
> > 			}
> > 		}
> > 	}
> > 	...
> > }
> > 
> > before the if judgment src = "/..%5c..%5cgo.sum" dst = "//....\\go.sum"
> > 
> > curl -v 127.0.0.1:8888/..%5c..%5cgo.sum
> > \*   Trying 127.0.0.1:8888...
> > \* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
> > \> GET /..%5c..%5cgo.sum HTTP/1.1
> > \> Host: 127.0.0.1:8888
> > \> User-Agent: curl/7.83.1
> > \> Accept: \*/\*
> > \>
> > \* Mark bundle as not supporting multiuse
> > < HTTP/1.1 404 404 Page not found
> > < Date: Mon, 05 Sep 2022 09:10:07 GMT
> > < Content-Type: text/plain; charset=utf-8
> > < Content-Length: 26
> > <
> > Cannot open requested path\* Connection #0 to host 127.0.0.1 left intact
> 
> Good job! As for the performance part, maybe do a bench test to see the answer.

I did some simple benchmarks, when there are backslashes in path, for-range option is faster, when there is no backslash in path, IndexByte option is faster.

Choose IndexByte maybe more reasonable since most normal URLs don't have backslashes in them.

var benchDstBackslashShort \= \[\]byte("/..\\\\foo")
var benchDstBackslashLong \= \[\]byte("/..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\foo")
var benchDstNoBackslashShort \= \[\]byte("/../foo")
var benchDstNoBackslashLong \= \[\]byte("/../../../../../../../../../../foo")

func BenchmarkForrange(b \*testing.B) {
	for i := 0; i < b.N; i++ {
		for i := range benchDstNoBackslashShort {
			if benchDstNoBackslashShort\[i\] \== '\\\\' {
				benchDstNoBackslashShort\[i\] \= '/'
			}
		}
		benchDstNoBackslashShort \= \[\]byte("/../foo")
	}
}

func BenchmarkIndexByte(b \*testing.B) {
	for i := 0; i < b.N; i++ {
		for {
			n := bytes.IndexByte(benchDstNoBackslashShort, '\\\\')
			if n < 0 {
				break
			}
			benchDstNoBackslashShort\[n\] \= '/'
		}
		benchDstNoBackslashShort \= \[\]byte("/../foo")
	}
}

environment

goos: windows
goarch: amd64
pkg: github.com/cloudwego/hertz/pkg/protocol
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz

benchDstBackslashShort

BenchmarkForrange-12     	57650732	        19.92 ns/op	       8 B/op	       1 allocs/op
BenchmarkIndexByte-12    	43823608	        27.97 ns/op	       8 B/op	       1 allocs/op
PASS
ok  	github.com/cloudwego/hertz/pkg/protocol	2.521s

benchDstBackslashLong

BenchmarkForrange-12     	21818498	        52.70 ns/op	      48 B/op	       1 allocs/op
BenchmarkIndexByte-12    	 9185786	       130.1 ns/op	      48 B/op	       1 allocs/op
PASS
ok  	github.com/cloudwego/hertz/pkg/protocol	2.941s

benchDstNoBackslashShort

BenchmarkForrange-12     	53754288	        19.66 ns/op	       8 B/op	       1 allocs/op
BenchmarkIndexByte-12    	61503766	        19.34 ns/op	       8 B/op	       1 allocs/op
PASS
ok  	github.com/cloudwego/hertz/pkg/protocol	2.379s

benchDstNoBackslashLong

BenchmarkForrange-12     	21096711	        49.30 ns/op	      48 B/op	       1 allocs/op
BenchmarkIndexByte-12    	32403181	        37.07 ns/op	      48 B/op	       1 allocs/op
PASS
ok  	github.com/cloudwego/hertz/pkg/protocol	2.724s

PTAL. There may have a side effect which lead to a failure of existing UT

Copy link

Contributor Author

****ruokeqx** commented Sep 6, 2022 •**

My fault. Since we add if filepath.Separator == '\\' {, backslashes were replaced when running UT in my windows laptop. However, linux would not replace them.  
We can pass the the UT by modifying the code like below.

if filepath.Separator \== '\\\\' && string(parsedPath) != expectedPath {
    t.Fatalf("Unexpected Path: %q. Expected %q", parsedPath, expectedPath)
}

Also, github action can not check windows path.

CVE-2022-40082: fix: fix path-traversal bug by ruokeqx · Pull Request #229 · cloudwego/hertz

A stacked combination of hardware and software protects the next version of Windows against the latest generation of firmware threats.

Microsoft on Tuesday released a hefty PDF detailing Windows 11's new security-focused features, with a heavy emphasis on supporting zero trust.

For a couple of years now, Microsoft, Google, and Amazon have been working with the US federal government on improving cybersecurity through zero trust, among other techniques. It's no coincidence that these are the big three cloud service providers, of course; they are best positioned to institute controls to prevent catastrophic cyberattacks.

But Microsoft is also moving security way down the stack to where cloud rivals can't follow: firmware.

**Hardware Security Under Attack**

While network-level security is mandatory, it is not sufficient to protect against attackers who target firmware and other low-level elements of a computer.

Flaws in firmware for CPUs, printers, and other hardware can open a door to a corporate network. Malware like TrickBot, MoonBounce, and LoJax that worms its way into the silicon is difficult to dislodge.

"These new threats call for computing hardware that is secure down to the very core, including hardware chips and processors which store sensitive business information," Microsoft stated in the new report. "With hardware-based protection, we can enable strong mitigation against entire classes of vulnerabilities that are difficult to thwart with software alone." 

Besides the extra strength of the protection, Microsoft touts less slowdown using hardware-based protection versus running it in software.

The foundation of the built-in hardware security is a partnership between hardware root-of-trust and silicon-assisted security.

**Hardware Root-of-Trust**

Hardware root-of-trust is, by definition, "a starting point that is implicitly trusted." In the case of a PC, it's the part that checks BIOS code to ensure it's legitimate before it boots up. And anyone who's had to remove malware from a machine with infected BIOS knows how vital that is.

The new security measures include storing sensitive data such as cryptographic keys and user credentials isolated from the operating system within a separate secure area. Microsoft requires a Trusted Platform Module (TPM) 2.0 chip to be installed on both new and upgraded Windows 11 machines. The company had required TPM 2.0 capabilities on all new Windows 10 machines, but the latest version of Windows won't even run if the PC doesn't have a TPM 2.0 security chip.

"With hardware-based isolation security that begins at the chip, Windows 11 stores sensitive data behind additional barriers separated from the operating system," Microsoft wrote in its new report. "As a result, information including encryption keys and user credentials are protected from unauthorized access and tampering."

To provide TPM 2.0 protection directly on the motherboard, Windows 11 machines include the Microsoft Pluton security processor on the system-on-chip. While Pluton is not brand new – it was previewed back in November 2020 – integrating TPM 2.0 capabilities in this way eliminates one attack vector: the bus interface between the CPU and the TPM chip.

Not all Windows 11 machines will have a Pluton chip, but they will all have a TPM 2.0 chip.

**Silicon-Assisted Security**

The silicon-assisted security measures in Windows 11 start with a secure kernel carved out using virtualization-based security (VBS). 

"The isolated VBS environment protects processes, such as security solutions and credential managers, from other processes running in memory," Microsoft wrote. "Even if malware gains access to the main OS kernel, the hypervisor and virtualization hardware help prevent the malware from executing unauthorized code or accessing platform secrets in the VBS environment."

Hypervisor-protected code integrity (HCVI) uses VBS to check the validity of code within the secure VBS environment instead of in the main Windows kernel. Kernel mode code integrity (KMCI), as that's called, fends off attempts to modify drivers and the like. KMCI verifies that all kernel code is properly signed and has not been altered before it allows it to run. HVCI is supported in all versions of Windows 11 and enabled by default in most editions.

A further measure of protection against such attacks as memory corruption and zero-day exploits is offered by hardware-enforced stack protection. 

"Based on Controlflow Enforcement Technology (CET) from Intel and AMD Shadow Stacks, hardware-enforced stack protection is designed to protect against exploit techniques that try to hijack return addresses on the stack," Microsoft explained. The OS does this by creating a "shadow stack," set apart from other stacks, for return addresses.

To protect against physical incursions where an intruder surreptitiously installs malware from a device, Microsoft's line of Secured-core PCs will only run executables signed by "known and approved authorities," keeping external peripherals from accessing memory without authorization.

Even more firmware protection comes from Windows 11's universal implementation of the Unified Extensible Firmware Interface (UEFI) Secure Boot standard. The TPM stores a boot audit log, the Static Root of Trust for Measurement (SRTM), to check whether any attempts to subvert the boot were made.

UEFI is not unique to Windows machines, of course, but Windows 11 adds Dynamic Root of Trust for Measurement (DRTM) that checks the UEFI boot process for suspicious activity before allowing it to continue. Non-PC devices such as the Surface tablet use Firmware Attack Surface Reduction in place of DRTM.

Silicon-assisted security is part of the Pro, Pro Workstation, Enterprise, Pro Education, and Education versions of Windows 11. The Home editions will have some of these protections but not the full slate. See Microsoft's website for comparisons.

Microsoft Brings Zero Trust to Hardware in Windows 11

A Regular Expression Denial of Service (ReDoS) flaw was found in stealjs steal 2.2.4 via the input variable in main.js.

Tag

#amd