Location-enabled tech designed to make our lives easier is often exploited by domestic abusers. Refuge, a UK nonprofit, helps women to leave abusive relationships, secure their devices, and stay safe.

Pick up any piece of tech and Emma Pickering knows how it can be used to abuse, harass, and stalk women. Amazon’s Ring home doorbell cameras can monitor when someone leaves the house and who is visiting them. Until recently, Netflix showed the IP addresses where users were logged in, allowing their location to be tracked. Workout apps and websites such as Strava show where and when people are exercising. And abusers often slip small GPS trackers or audio recorders into women’s belongings or attach them to their cars.

“Perpetrators buy them in bulk, and they’ll buy probably 60 very cheaply; they’re very small and discrete,” says Pickering, who works at Refuge, the UK’s largest domestic abuse organization, where she heads a team that helps women secure their devices. Pickering says that in one case “over 200” recording devices were found in a woman’s home.

Refuge launched its Technology-Facilitated Abuse and Economic Empowerment Team in 2017, amid a surge of abusers weaponizing apps, devices, and online services to harm women. The charity helps women and their children leave abusive relationships, providing emergency accommodation, legal help, financial aid, and more. Almost every case now involves technology in some form, Pickering says, and the issue is so serious that every person the organization places into a refuge goes through a tech assessment to secure their accounts. The tech abuse team, which is made up of 11 people, is the only one of its kind in the UK and just one of a handful of similar organizations around the world.

Technology-facilitated abuse can range from harassment via phone call or text message to logging into someone’s social media and email accounts without their permission, which allows abusers to read, delete or send messages. In more extreme cases, they might install “stalkerware” on victims’ phones to monitor every tap and scroll. Nonconsensual image-sharing, commonly known as “revenge porn,” and economic abuse, where money and banking apps may be controlled by an abuser, are also frequent. In August, a report from MPs in the UK concluded that tech abuse is becoming “increasingly common.”

Pickering says her team primarily focuses on helping people in the more severe cases. “Firstly, we need to establish if it’s safe to speak to them on their device,” she says. If it isn’t, Refuge will send women a burner phone and then set them up with a new email address, using the encrypted email service Proton Mail, before sending them extra information. It’s the start of a meticulous process—known as an “attack assessment” by the team—to secure accounts and devices.

“We go through everything,” Pickering says. Refuge will ask the person they are helping to list every device and online account they and any children have. These can easily number into the hundreds. “Within the home, if they’ve fled the relationship, we also need to check anything they’ve left behind to unsync from any devices or accounts that they could still be using back home.” This will include products like Google Home Hubs, and Amazon’s Ring doorbells and Alexa, and it requires checking who set up the devices and is the administrator of the accounts, as well as which names phone contracts are in. From there, a safety plan is created, Pickering says. This can include going through the accounts and checking settings for who has access to them, removing devices connected to accounts, using secure passwords, and setting up measures such as two-factor authentication. On average, Pickering says, it can take three weeks to get through the entire process, although more complex cases take much longer.

“I don’t think people realize how serious it is, the consequences for perpetrators to have access to this information, to see that there’s evidence in someone’s phone that they’re planning to leave a relationship, read emails about financial settlements, child contact orders—it puts someone at really significant risk,” Pickering says. Even for those in nonabusive relationships, the charity has created a digital breakup tool with cybersecurity firm Avast to detail the process of separating everything from delivery apps to gaming accounts from former partners.

While the technology itself isn’t usually the problem—it’s how abusers use it to harass their victims that creates the issues—Pickering says tech companies don’t put enough thought into how their services can be used maliciously. They also don’t put enough effort into preventing such abuses. They’re not “considering having features built in that can mitigate these risks,” she says.

For instance, Apple launched its small AirTag GPS tracker without many safety features, and dozens of people have subsequently reported being tracked by the devices. (The company has made some improvements and is now working with other tracker manufacturers to make it easier to identify trackers someone has placed on your belongings). One of the biggest issues currently, Pickering says, is satellite navigation systems within cars. “My car, for instance, if I drive it somewhere, it’s connected to an app, and I don’t know how many people are on my app, it doesn’t give me notifications,” she says. There are also boundary settings that can alert a vehicle’s owner if it travels beyond a specific set of locations.

Aside from designing products better, tech companies need to make it easier for people to understand the settings on their phone and digital accounts. “Many people come to us and their confidence around tech is very limited,” Pickering says. “We have to do a lot of work with them initially to make them feel comfortable.”

While tech abuse is rising, Pickering aims to increase understanding around the problem and tackle some of the issues at its roots. “We’ve got a really big ambition to train the police,” she says, adding that officers often don’t know what to look for in cases of tech abuse and may not take issues seriously. The Refuge team has already worked with one tech company, which she says she cannot name due to an NDA, to advise on safety. “Amazon and Google could work with us,” Pickering says. “And we could help make sure that their products are developed with safety in mind.”

_This article first appeared in the November/December 2023 issue of WIRED UK._

The Team Helping Women Fight Digital Domestic Abuse

Microsoft has detailed a new campaign in which attackers unsuccessfully attempted to move laterally to a cloud environment through a SQL Server instance.
"The attackers initially exploited a SQL injection vulnerability in an application within the target's environment," security researchers Sunders Bruskin, Hagai Ran Kestenberg, and Fady Nasereldeen said in a Tuesday report.
"This allowed the

Cloud Security / Cyber Threat

Microsoft has detailed a new campaign in which attackers unsuccessfully attempted to move laterally to a cloud environment through a SQL Server instance.

"The attackers initially exploited a SQL injection vulnerability in an application within the target's environment," security researchers Sunders Bruskin, Hagai Ran Kestenberg, and Fady Nasereldeen said in a Tuesday report.

"This allowed the attacker to gain access and elevated permissions on a Microsoft SQL Server instance deployed in Azure Virtual Machine (VM)."

In the next stage, the threat actors leveraged the new permissions to attempt to move laterally to additional cloud resources by abusing the server's cloud identity, which may possess elevated permissions to likely carry out various malicious actions in the cloud that the identity has access to.

Microsoft said it did not find any evidence to suggest that the attackers successfully moved laterally to the cloud resources using the technique.

"Cloud services like Azure use managed identities for allocating identities to the various cloud resources," the researchers said. "Those identities are used for authentication with other cloud resources and services."

The starting point of the attack chain is an SQL injection against the database server that allows the adversary to run queries to gather information about the host, databases, and network configuration.

In the observed intrusions, it's suspected that the application targeted with the SQL injection vulnerability had elevated permissions, which permitted the attackers to enable the xp\_cmdshell option to launch operating system commands to proceed to the next phase.

This included conducting reconnaissance, downloading executables and PowerShell scripts, and setting up persistence via a scheduled task to start a backdoor script.

Data exfiltration is achieved by taking advantage of a publicly accessible tool called webhook\[.\]site in an effort to stay under the radar, since outgoing traffic to the service is deemed legitimate and unlikely to be flagged.

"The attackers tried utilizing the cloud identity of the SQL Server instance by accessing the \[instance metadata service\] and obtaining the cloud identity access key," the researchers said. "The request to IMDS identity's endpoint returns the security credentials (identity token) for the cloud identity."

The ultimate goal of the operation appears to have been to abuse the token to perform various operations on cloud resources, including lateral movement across the cloud environment, although it ended in failure due to an unspecified error.

The development underscores the growing sophistication of cloud-based attack techniques, with bad actors constantly on the lookout for over-privileged processes, accounts, managed identities, and database connections to conduct further malicious activities.

"This is a technique we are familiar with in other cloud services such as VMs and Kubernetes cluster but haven't seen before in SQL Server instances," the researchers concluded.

"Not properly securing cloud identities can expose SQL Server instances and cloud resources to similar risks. This method provides an opportunity for the attackers to achieve greater impact not only on the SQL Server instances but also on the associated cloud resources."

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

Microsoft Warns of Cyber Attacks Attempting to Breach Cloud via SQL Server Instance

Out-of-bounds Read in GitHub repository gpac/gpac prior to v2.2.2-DEV.

Expand Up @@ -12676,15 +12676,29 @@ GF\_Err chnl\_box\_read(GF\_Box \*s,GF\_BitStream \*bs) GF\_ChannelLayoutBox \*ptr \= (GF\_ChannelLayoutBox \*) s;  
ISOM\_DECREASE\_SIZE(s, 1) ptr\->layout.stream\_structure \= gf\_bs\_read\_u8(bs); if (ptr\->version\==0) { ptr\->layout.stream\_structure \= gf\_bs\_read\_u8(bs); } else { ptr\->layout.stream\_structure \= gf\_bs\_read\_int(bs, 4); ptr\->layout.format\_ordering \= gf\_bs\_read\_int(bs, 4); ISOM\_DECREASE\_SIZE(s, 1) ptr\->layout.base\_channel\_count \= gf\_bs\_read\_u8(bs); } if (ptr\->layout.stream\_structure & 1) { ISOM\_DECREASE\_SIZE(s, 1) ptr\->layout.definedLayout \= gf\_bs\_read\_u8(bs); if (ptr\->layout.definedLayout\==0) { u32 remain \= (u32) ptr\->size; if (ptr\->layout.stream\_structure & 2) remain\--; ptr\->layout.channels\_count \= 0; u32 nb\_channels \= 0; if (ptr\->version) { ISOM\_DECREASE\_SIZE(s, 1) nb\_channels \= gf\_bs\_read\_u8(bs); } while (remain) { if (ptr\->layout.channels\_count\==64) return GF\_ISOM\_INVALID\_FILE;  
ISOM\_DECREASE\_SIZE(s, 1) ptr\->layout.layouts\[ptr\->layout.channels\_count\].position \= gf\_bs\_read\_u8(bs); remain\--; Expand All @@ -12694,13 +12708,31 @@ GF\_Err chnl\_box\_read(GF\_Box \*s,GF\_BitStream \*bs) ptr\->layout.layouts\[ptr\->layout.channels\_count\].elevation \= gf\_bs\_read\_int(bs, 8); remain\-=3; } ptr\->layout.channels\_count++; if (ptr\->version) { nb\_channels\--; if (!nb\_channels) break; } } } else { ISOM\_DECREASE\_SIZE(s, 8) ptr\->layout.omittedChannelsMap \= gf\_bs\_read\_u64(bs); if (ptr\->version\==0) { ISOM\_DECREASE\_SIZE(s, 8) ptr\->layout.omittedChannelsMap \= gf\_bs\_read\_u64(bs); ptr\->layout.omitted\_channels\_present \= 1; ptr\->layout.channel\_order\_definition \= 0; } else { ISOM\_DECREASE\_SIZE(s, 1) gf\_bs\_read\_int(bs, 4); ptr\->layout.channel\_order\_definition \= gf\_bs\_read\_int(bs, 3); ptr\->layout.omitted\_channels\_present \= gf\_bs\_read\_int(bs, 1); if (ptr\->layout.omitted\_channels\_present) { ISOM\_DECREASE\_SIZE(s, 8) ptr\->layout.omittedChannelsMap \= gf\_bs\_read\_u64(bs); } } } } if (ptr\->layout.stream\_structure & 2) { if ((ptr\->version\==0) && (ptr\->layout.stream\_structure & 2)) { ISOM\_DECREASE\_SIZE(s, 1) ptr\->layout.object\_count \= gf\_bs\_read\_u8(bs); } Expand All @@ -12724,10 +12756,20 @@ GF\_Err chnl\_box\_write(GF\_Box \*s, GF\_BitStream \*bs) if (e) return e;  
gf\_bs\_write\_u8(bs, ptr\->layout.stream\_structure); if (ptr\->version\==0) { gf\_bs\_write\_u8(bs, ptr\->layout.stream\_structure); } else { gf\_bs\_write\_int(bs, ptr\->layout.stream\_structure, 4); gf\_bs\_write\_int(bs, ptr\->layout.format\_ordering, 4); gf\_bs\_write\_u8(bs, ptr\->layout.base\_channel\_count); } if (ptr\->layout.stream\_structure & 1) { gf\_bs\_write\_u8(bs, ptr\->layout.definedLayout); if (ptr\->layout.definedLayout\==0) { u32 i; if (ptr\->version\==1) { gf\_bs\_write\_u8(bs, ptr\->layout.channels\_count); } for (i\=0; i<ptr\->layout.channels\_count; i++) { gf\_bs\_write\_u8(bs, ptr\->layout.layouts\[i\].position); if (ptr\->layout.layouts\[i\].position\==126) { Expand All @@ -12736,10 +12778,18 @@ GF\_Err chnl\_box\_write(GF\_Box \*s, GF\_BitStream \*bs) } } } else { gf\_bs\_write\_u64(bs, ptr\->layout.omittedChannelsMap); if (ptr\->version\==1) { gf\_bs\_write\_int(bs, 0, 4); gf\_bs\_write\_int(bs, ptr\->layout.channel\_order\_definition, 3); gf\_bs\_write\_int(bs, ptr\->layout.omitted\_channels\_present, 1); if (ptr\->layout.omitted\_channels\_present) gf\_bs\_write\_u64(bs, ptr\->layout.omittedChannelsMap); } else { gf\_bs\_write\_u64(bs, ptr\->layout.omittedChannelsMap); } } } if (ptr\->layout.stream\_structure & 2) { if ((ptr\->version\==0) && (ptr\->layout.stream\_structure & 2)) { gf\_bs\_write\_u8(bs, ptr\->layout.object\_count); } return GF\_OK; Expand All @@ -12749,20 +12799,28 @@ GF\_Err chnl\_box\_size(GF\_Box \*s) { GF\_ChannelLayoutBox \*ptr \= (GF\_ChannelLayoutBox \*) s; s\->size += 1; if (ptr\->version\==1) s\->size++; if (ptr\->layout.stream\_structure & 1) { s\->size += 1; if (ptr\->layout.definedLayout\==0) { u32 i; if (ptr\->version\==1) s\->size++; for (i\=0; i<ptr\->layout.channels\_count; i++) { s\->size+=1; if (ptr\->layout.layouts\[i\].position\==126) s\->size+=3; } } else { s\->size += 8; if (ptr\->version\==1) { s\->size += 1; if (ptr\->layout.omitted\_channels\_present) s\->size += 8; } else { s\->size += 8; } } } if (ptr\->layout.stream\_structure & 2) { if ((ptr\->version\==0) && (ptr\->layout.stream\_structure & 2)) { s\->size += 1; } return GF\_OK; Expand Down

CVE-2023-5377: fixed #2606 · gpac/gpac@8e9d6b3

Open Redirect in GitHub repository mosparo/mosparo prior to 1.0.2.

Expand Up

@@ -394,7 +394,7 @@ public function switch(Request $request, Project $project): Response

  

// Redirect back to the originally requested path

$targetPath = $request\->query\->get('targetPath', false);

if ($targetPath) {

if ($targetPath && $this\->isLocalUrl($request, $targetPath)) {

return $this\->redirect($targetPath);

}

  

Expand All

@@ -411,4 +411,22 @@ protected function setActiveProject(Request $request, Project $project): bool

  

return true;

}

  

protected function isLocalUrl(Request $request, $url): bool

{

// If the first character is a slash, the URL is relative (only the path) and is local

if (str\_starts\_with($url, '/')) {

return true;

}

  

// If the URL is absolute but starts with the host of mosparo, we can redirect it.

// Add the slash to prevent a redirect when a similar top-level domain is used.

// For example, mosparo.com should not allow a redirect to mosparo.com.au

if (str\_starts\_with($url, $request\->getSchemeAndHttpHost() . '/')) {

return true;

}

  

// The URL does not match the two checks because it's an external URL; no redirect in that case.

return false;

}

}

CVE-2023-5375: Fixed an open redirect in the project switch functionality. · mosparo/mosparo@9d5da36

A cross-site scripting vulnerability exists in Citadel versions prior to 994. When a malicious user sends an instant message with some JavaScript code, the script may be executed on the web browser of the victim user.

**Commit f0dac5ff** authored Sep 15, 2023 by  **Art Cancro**

Browse files

**webcit: sanitize instant messages against XSS type stuff**

parent 08ba8022

*   Changes 2

Hide whitespace changes

Inline Side-by-side

Supports Markdown

0% or .

You are about to add **0 people** to the discussion. Proceed with caution.

Finish editing this message first!

Please register or sign in to comment

CVE-2023-44272: webcit: sanitize instant messages against XSS type stuff (f0dac5ff) · Commits · citadel / Citadel · GitLab

On CPU 0 the check for the SMCCC workaround is called before SMCCC support has been initialized. This resulted in no speculative execution workarounds being installed on CPU 0.

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-23:14.smccc Security Advisory The FreeBSD Project Topic: arm64 boot CPUs may lack speculative execution protections Category: core Module: arm64 Announced: 2023-10-03 Affects: FreeBSD 13.2 Corrected: 2023-09-25 12:13:47 UTC (stable/13, 13.2-STABLE) 2023-10-03 21:29:11 UTC (releng/13.2, 13.2-RELEASE-p4) CVE Name: CVE-2023-5370 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background To mitigate speculative execution side channel attacks on some AArch64 hardware the kernel can call into the boot firmware using the Secure Monitor Call Calling Convention (SMCCC) mechanism. To decide if the kernel needs to use the SMCCC mitigation on a given CPU it can query the firmware if the SMCCC workaround is present. II. Problem Description On CPU 0 the check for the SMCCC workaround is called before SMCCC support has been initialized. III. Impact No speculative execution workarounds are installed on CPU 0. IV. Workaround No workaround is available. Not all AArch64 CPUs are affected. Systems where CPU 0 has the CSV2 and PSTATE.SSBS processor features are unaffected by the speculative execution attacks. The kernel will print the following under CPU 0 on unaffected CPUs: Processor Features 0 = <...CVS2...> Processor Features 1 = <...PSTATE.SSBS...> The Arm Cortex-A35, Cortex-A53, and Cortex-A55 CPUs are unaffected. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date and reboot. Perform one of the following: 1) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the amd64, i386, or (on FreeBSD 13 and later) arm64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-23:14/smccc.patch # fetch https://security.FreeBSD.org/patches/SA-23:14/smccc.patch.asc # gpg --verify smccc.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details This issue is corrected by the corresponding Git commit hash or Subversion revision number in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/13/ 4df1447f2c76 stable/13-n256420 releng/13.2/ 485912e051bb releng/13.2-n254637 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat Or visit the following URL, replacing NNNNNN with the hash: To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmUclU8ACgkQbljekB8A Gu8zqQ//bCjUB/hXZxypEFmnnnyUPr0Y/pzHd1i7EcIFQubd6kosUw4k2VGzwOsi /BwKU4W/MrUyr/wwSkjJ/lmeA+CRX2TAPWPTPC0umnN58fOXRqhKpVAi0yfho+L9 lYUfdLWM0xS4XWsZk7DapjfN8XznLnn6iQrWmFLmZd0ViJFGkGJcxjdWr7aSs7ZX C8v8GoqFx6GUUdOgRERdpZ/2mxi7ibs9LbCt4PUTwKV8clAmq4w4Mv+q4xfZPSnM nXGrTd+t2G5ZrmEZ9Rq32C9JqGaAaQUTp/NsOw8yQq5YVBXanA12VJLx2kdoVKsj 84e3rJz/QTpXTpgiSkVmWdT3ziZW8Zs9aygvUXyzK6C/s2ZiKd8o65dnF3MGCyJs Y7aNgAS51mX/fgPyXwicF/eYA1nm/1AJAK9J/eUBbsi+hu9DW5XjpiLUYAe10KKf 9XsgJ1vTJMKXIv/UAlN0d78SfSfcGyUCbH0qk7zCzw9XfLYj+r9a7de/vnAc0qtm 8Gh0hqbacA6dqtxrNEDC9R1Tp6inf0YYR6gP5HPjjy96FvfZCGmHk5XUmbmk4C4T UylvLXrO4gJiyBXhdZ3P3Mib6HdMWkLMRh095Y2revdAGMv0BrGs3G+eaMVIgNt2 puELCPfLgJF1ljcHV8svdQcuy0Fea2R2R22cqwsT1vPuKqgmP60= =lOTX -----END PGP SIGNATURE-----

CVE-2023-5370

Before correction, the copy_file_range system call checked only for the CAP_READ and CAP_WRITE capabilities on the input and output file descriptors, respectively.  Using an offset is logically equivalent to seeking, and the system call must additionally require the CAP_SEEK capability.

This incorrect privilege check enabled sandboxed processes with only read or write but no seek capability on a file descriptor to read data from or write data to an arbitrary location within the file corresponding to that file descriptor.

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-23:13.capsicum Security Advisory The FreeBSD Project Topic: copy\_file\_range insufficient capability rights check Category: core Module: capsicum Announced: 2023-10-03 Credits: David Chisnall Affects: FreeBSD 13.2 Corrected: 2023-10-02 16:00:27 UTC (stable/13, 13.2-STABLE) 2023-10-03 21:24:41 UTC (releng/13.2, 13.2-RELEASE-p4) CVE Name: CVE-2023-5369 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background Capsicum is a lightweight OS capability and sandbox framework. It provides two kernel primatives, capability mode and capabilities. Capabilities limit operations that can be performed on file descriptors. copy\_file\_range is a system call that performs a kernel copy of a byte range from one file to another or within one file. copy\_file\_range accepts optional pointers to offsets for the input and output file descriptors. II. Problem Description The syscall checked only for the CAP\_READ and CAP\_WRITE capabilities on the input and output file descriptors, respectively. Using an offset is logically equivalent to seeking, and the syscall must additionally require the CAP\_SEEK capability. III. Impact A sandboxed process with only read or write but no seek capability on a file descriptor may be able to read data from or write data to an arbitrary location within the file corresponding to that file descriptor. IV. Workaround No workaround is available. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot. Perform one of the following: 1) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the amd64, i386, or (on FreeBSD 13 and later) arm64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-23:13/capsicum.patch # fetch https://security.FreeBSD.org/patches/SA-23:13/capsicum.patch.asc # gpg --verify capsicum.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details This issue is corrected by the corresponding Git commit hash or Subversion revision number in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/13/ 3f0ce63828dc stable/13-n256458 releng/13.2/ 2d23f6c33431 releng/13.2-n254636 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat Or visit the following URL, replacing NNNNNN with the hash: To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmUclU0ACgkQbljekB8A Gu/a3Q//aXO1+HdImFnqAzKEto8E97DEv6vB2HUZAoxrmwSX9VNjkrIo9Z9+LRyL q7WXMcok1OPQCCE3ad+g05eqXwnmJ55CpToP/jEXrOOZRDInK0Z5owZbwVpmyAmW zF/+xoEjcw90H7ReIQQ3+TNGDf025tCoXlTQKdzWtNN6BcY3px4zuDYHPUKgMwSv XJDrjYWBzBede00CnlolwmsBorjvZvRMfllTIpiVTlmtD73s+sRDI7rc768MY0RZ gCplCL9S9EkIGL8XJhDWB2+TsG7nvwrUII5M2u0Db252IK7nmgty4l03PtYotx4p jH/a3oXWKeqExGHJaqNcaUwS6xdu+pvMRuJgY4mH6rd+uvOMbC5jvac3FopSlmXq aVIctA2LCRomyYmVDsWXIGLcBT5cAOhsqkrw+JE0kA/k2Pl6NDNK7HNgo6Fj01TR lVf91A1mTsDJxfymU4SWB/KGgImAnR9e7gHUo4gLZCNyYXvcnFa/ntHoswNZ+12L e/b4+PnHts2X4/+I4K6qdF522yzF/vpyF6UjfwAGtT6qmbmGyW9VbDcn6TIL9I3p IDKJCWeHPBfyspWua2hCUIi3/EwpSFvIECPad3hFT6cej1pZ6hfJt8XT0ma82QGp ocbh3tb3E1phSGvgZitk8J0oyWDehuck3YfZ+6nHMwzPBgmr6Lo= =lS69 -----END PGP SIGNATURE-----

CVE-2023-5369

On an msdosfs filesystem, the 'truncate' or 'ftruncate' system calls under certain circumstances populate the additional space in the file with unallocated data from the underlying disk device, rather than zero bytes.

This may permit a user with write access to files on a msdosfs filesystem to read unintended data (e.g. from a previously deleted file).

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-23:12.msdosfs Security Advisory The FreeBSD Project Topic: msdosfs data disclosure Category: core Module: msdosfs (FAT) file system driver Announced: 2023-10-03 Credits: Maxim Suhanov Affects: All supported versions of FreeBSD. Corrected: 2023-07-18 05:46:13 UTC (stable/13, 13.2-STABLE) 2023-10-03 21:23:40 UTC (releng/13.2, 13.2-RELEASE-p4) 2023-09-11 18:51:21 UTC (stable/12, 12.4-STABLE) 2023-10-03 22:15:40 UTC (releng/12.4, 12.4-RELEASE-p6) CVE Name: CVE-2023-5368 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The msdosfs driver provides read and write access to MS-DOS (FAT) file systems. Systems may be configured to allow unprivileged users to have read and write access to mounted msdosfs file systems. II. Problem Description In certain cases using the truncate or ftruncate system call to extend a file size populates the additional space in the file with unallocated data from the underlying disk device, rather than zero bytes. III. Impact A user with write access to files on a msdosfs file system may be able to read unintended data (for example, from a previously deleted file). IV. Workaround No workaround is available. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot. Perform one of the following: 1) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the amd64, i386, or (on FreeBSD 13 and later) arm64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. \[FreeBSD 13.2\] # fetch https://security.FreeBSD.org/patches/SA-23:12/msdosfs.13.2.patch # fetch https://security.FreeBSD.org/patches/SA-23:12/msdosfs.13.2.patch.asc # gpg --verify msdosfs.13.2.patch.asc \[FreeBSD 12.4\] # fetch https://security.FreeBSD.org/patches/SA-23:12/msdosfs.12.4.patch # fetch https://security.FreeBSD.org/patches/SA-23:12/msdosfs.12.4.patch.asc # gpg --verify msdosfs.12.4.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details This issue is corrected by the corresponding Git commit hash or Subversion revision number in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/13/ 868f3eadc5e0 stable/13-n255824 releng/13.2/ 7d08a7e6908b releng/13.2-n254635 stable/12/ r373207 releng/12.4/ r373233 - ------------------------------------------------------------------------- For FreeBSD 13 and later: Run the following command to see which files were modified by a particular commit: # git show --stat Or visit the following URL, replacing NNNNNN with the hash: To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD For FreeBSD 12 and earlier: Run the following command to see which files were modified by a particular revision, replacing NNNNNN with the revision number: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmUclUoACgkQbljekB8A Gu9CSw/9G+9cwxNruCQaEOcNGCIUdOe9itmZzVJKVtIIWqXZhq+unXRS0D2YDMdA EKkfGj6GYaPnFlRe7T3cfrqUFhlNMb4Na5SW0wJp8HUqhKzKB4/SNZSs+iXNQE2z WdhYFl582Gg2+vuoije4Z9Idl0WYPqXHXyRC7TCtSwUHDwRsU9jA6g/GNM0X+0dl mOzFxFSSGoORF5aJYtp91KeNwGdNwORc75k6xxMWGGDc0sba9Fbupfrjc/XQ8SaQ tYil3Eomh/cbYOKneppGQo9ohY+PAC1u/2XxRBxXYFCDtNLed4SGEWp4pLKjq2QM X8jkDooTPLwDiVaM6Cps54PmUI3YBrYKSpt3Z1SdTHWyh0hDtpAJb/1f/sPUu90D oWCiFI5p6oZjFNJxskZZ8T6xFgjqiII70ULfHQ3GxGhMZ0Pe5QyzmqIFGvkn0UtX uGechgeL+jwqnyviIFyfVTGORmbcWj60WHajUAVUbb5aF/WV5QS0XDOLhTFkeY/P WQjOBFAH/pf93ahUnA0NuDqAe5yX/3NEXLzMg8bnSBDJRIPRWsPfIE3lqWl0zNmD sdtsugBS74zTM3MUn/Lq5MdtozuvEWK6Hs60i1wuiTMT39X8oE89r5LLVgTyc0Tj 2nML+7TKutMqWgeRvYsXBp6VtEiZd9Qc6nx8FWtSq8UMODa57C8= =T0YO -----END PGP SIGNATURE-----

CVE-2023-5368

An arbitrary file upload vulnerability in the component /admin/plugin.php of Emlog Pro v2.2.0 allows attackers to execute arbitrary code via uploading a crafted PHP file.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2023-44974: emlog/Plugin-getshell.md at main · yangliukk/emlog

Nothings stb 2.28 was discovered to contain a Null Pointer Dereference via the function stbi__convert_format. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted pic file.

**Null Pointer Dereference vulnerability in nothings/stb**

​ Nothings/stb, an image processing library, has a **Null Pointer Dereference** vulnerability in the stbi\_\_convert\_format function, stb\_image.h 2.28(https://github.com/nothings/stb/blob/master/stb\_image.h). This function is called in stbi\_\_pic\_load and is used to parse files in the pic image format. And stbi\_\_pic\_load is called by stbi\_load\_from\_memory.

**Vulnerability causes**

static void \*stbi\_\_pic\_load(stbi\_\_context \*s,int \*px,int \*py,int \*comp,int req\_comp, stbi\_\_result\_info \*ri)
{
   stbi\_uc \*result;
   int i, x,y, internal\_comp;
   STBI\_NOTUSED(ri);

   if (!comp) comp = &internal\_comp;

   for (i=0; i<92; ++i)
      stbi\_\_get8(s);

   x = stbi\_\_get16be(s);
   y = stbi\_\_get16be(s);

   if (y > STBI\_MAX\_DIMENSIONS) return stbi\_\_errpuc("too large","Very large image (corrupt?)");
   if (x > STBI\_MAX\_DIMENSIONS) return stbi\_\_errpuc("too large","Very large image (corrupt?)");

   if (stbi\_\_at\_eof(s))  return stbi\_\_errpuc("bad file","file too short (pic header)");
   if (!stbi\_\_mad3sizes\_valid(x, y, 4, 0)) return stbi\_\_errpuc("too large", "PIC image too large to decode");

   stbi\_\_get32be(s); //skip \`ratio'
   stbi\_\_get16be(s); //skip \`fields'
   stbi\_\_get16be(s); //skip \`pad'

   // intermediate buffer is RGBA
   result = (stbi\_uc \*) stbi\_\_malloc\_mad3(x, y, 4, 0);
   if (!result) return stbi\_\_errpuc("outofmem", "Out of memory");
   memset(result, 0xff, x\*y\*4);

   if (!stbi\_\_pic\_load\_core(s,x,y,comp, result)) {
      STBI\_FREE(result);
      result=0;
   }
   \*px = x;
   \*py = y;
   if (req\_comp == 0) req\_comp = \*comp;
   result=stbi\_\_convert\_format(result,4,req\_comp,x,y);

   return result;
}

​ We can see that the "**result**" variable is assigned NULL after STBI\_FREE and is used again by stbi\_\_convert\_format.

static unsigned char \*stbi\_\_convert\_format(unsigned char \*data, int img\_n, int req\_comp, unsigned int x, unsigned int y)
{
   int i,j;
   unsigned char \*good;

   if (req\_comp == img\_n) return data;
   STBI\_ASSERT(req\_comp >= 1 && req\_comp <= 4);

   good = (unsigned char \*) stbi\_\_malloc\_mad3(req\_comp, x, y, 0);
   if (good == NULL) {
      STBI\_FREE(data);
      return stbi\_\_errpuc("outofmem", "Out of memory");
   }

   for (j=0; j < (int) y; ++j) {
      unsigned char \*src  = data + j \* x \* img\_n   ;
      unsigned char \*dest = good + j \* x \* req\_comp;

      #define STBI\_\_COMBO(a,b)  ((a)\*8+(b))
      #define STBI\_\_CASE(a,b)   case STBI\_\_COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
      // convert source image with img\_n components to one with req\_comp components;
      // avoid switch per pixel, so use switch per scanline and massive macros
      switch (STBI\_\_COMBO(img\_n, req\_comp)) {
         STBI\_\_CASE(1,2) { dest\[0\]=src\[0\]; dest\[1\]=255;                                     } break;
         STBI\_\_CASE(1,3) { dest\[0\]=dest\[1\]=dest\[2\]=src\[0\];                                  } break;
         STBI\_\_CASE(1,4) { dest\[0\]=dest\[1\]=dest\[2\]=src\[0\]; dest\[3\]=255;                     } break;
         STBI\_\_CASE(2,1) { dest\[0\]=src\[0\];                                                  } break;
         STBI\_\_CASE(2,3) { dest\[0\]=dest\[1\]=dest\[2\]=src\[0\];                                  } break;
         STBI\_\_CASE(2,4) { dest\[0\]=dest\[1\]=dest\[2\]=src\[0\]; dest\[3\]=src\[1\];                  } break;
         STBI\_\_CASE(3,4) { dest\[0\]=src\[0\];dest\[1\]=src\[1\];dest\[2\]=src\[2\];dest\[3\]=255;        } break;
         STBI\_\_CASE(3,1) { dest\[0\]=stbi\_\_compute\_y(src\[0\],src\[1\],src\[2\]);                   } break;
         STBI\_\_CASE(3,2) { dest\[0\]=stbi\_\_compute\_y(src\[0\],src\[1\],src\[2\]); dest\[1\] = 255;    } break;
         STBI\_\_CASE(4,1) { dest\[0\]=stbi\_\_compute\_y(src\[0\],src\[1\],src\[2\]);                   } break;
         STBI\_\_CASE(4,2) { dest\[0\]=stbi\_\_compute\_y(src\[0\],src\[1\],src\[2\]); dest\[1\] = src\[3\]; } break;
         STBI\_\_CASE(4,3) { dest\[0\]=src\[0\];dest\[1\]=src\[1\];dest\[2\]=src\[2\];                    } break;
         default: STBI\_ASSERT(0); STBI\_FREE(data); STBI\_FREE(good); return stbi\_\_errpuc("unsupported", "Unsupported format conversion");
      }
      #undef STBI\_\_CASE
   }

   STBI\_FREE(data);
   return good;
}

​ The "**result**" variable will be used again as the "**data**" variable inside stbi\_\_convert\_format, when the "**data**" variable is already a null pointer, and using it again will result in a null pointer dereference.

**Vulnerability reproduce**

​ The environment is shown below.

​ In the "null\_example" folder, use the following command.

​ or

​ We can see the "core dumped".

**Impact**

Denial of service attack

​ Here the "**result**" variable is assigned as a null pointer.

​ Here the null pointer is used as the base address, at which point an error occurs.

Tag

#git