A cross-site request forgery (CSRF) vulnerability in Jenkins Nexus Platform Plugin 3.18.0-03 and earlier allows attackers to send an HTTP request to an attacker-specified URL and parse the response as XML.

This advisory announces vulnerabilities in the following Jenkins deliverables:

*   Analysis Model API Plugin
*   Deployment Dashboard Plugin
*   Dingding JSON Pusher Plugin
*   HTMLResource Plugin
*   Nexus Platform Plugin
*   OpenId Connect Authentication Plugin
*   PaaSLane Estimate Plugin
*   Scriptler Plugin

**Descriptions****DoS vulnerability in Analysis Model API Plugin**

**SECURITY-3327 / CVE-2023-5072**  
**Severity (CVSS):** Medium  
**Affected plugin: analysis-model-api**  
**Description:**

Analysis Model API Plugin 11.11.0 and earlier bundles versions of JSON-Java vulnerable to CVE-2023-5072.

This may allow attackers able to control input to cause a Denial of Service (DoS) by parsing a crafted JSON document.

As of publication, Synopsys Rapid Scan Static is the only plugin the Jenkins security team is aware of whose report parser is potentially affected.

Analysis Model API Plugin 11.13.0 updates JSON-Java to version 20231013, which is unaffected by this issue.

**Arbitrary file deletion vulnerability in Scriptler Plugin**

**SECURITY-3205 / CVE-2023-50764**  
**Severity (CVSS):** High  
**Affected plugin: scriptler**  
**Description:**

Scriptler Plugin 342.v6a\_89fd40f466 and earlier does not restrict a file name query parameter in an HTTP endpoint.

This allows attackers with Scriptler/Configure permission to delete arbitrary files on the Jenkins controller file system.

Scriptler Plugin 344.v5a\_ddb\_5f9e685 ensures that the file being deleted is located in the expected directory.

**Missing permission check in Scriptler Plugin**

**SECURITY-3206 / CVE-2023-50765**  
**Severity (CVSS):** Medium  
**Affected plugin: scriptler**  
**Description:**

Scriptler Plugin 342.v6a\_89fd40f466 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to read the contents of a Groovy script by knowing its ID.

Scriptler Plugin 344.v5a\_ddb\_5f9e685 requires the appropriate permission to read the contents of a Groovy script.

**CSRF vulnerability and missing permission checks in Nexus Platform Plugin allow XXE**

**SECURITY-3204 / CVE-2023-50766 (CSRF), CVE-2023-50767 (missing permission check)**  
**Severity (CVSS):** High  
**Affected plugin: nexus-jenkins-plugin**  
**Description:**

Nexus Platform Plugin 3.18.0-03 and earlier does not perform permission checks in methods implementing form validation.

This allows attackers with Overall/Read permission to send an HTTP request to an attacker-specified URL and parse the response as XML.

Additionally, the plugin does not configure its XML parser to prevent XML external entity (XXE) attacks, so attackers can have Jenkins parse a crafted XML response that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery.

Additionally, these form validation methods do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

Nexus Platform Plugin 3.18.1-01 configures its XML parser to prevent XML external entity (XXE) attacks.

Additionally, POST requests and Overall/Administer permission are required for the affected HTTP endpoints.

Nexus Platform Plugin is not currently distributed by the Jenkins Project due to licensing issues. The fixed version can be downloaded from the Sonatype website.

**CSRF vulnerability and missing permission checks in Nexus Platform Plugin allow capturing credentials**

**SECURITY-3203 / CVE-2023-50768 (CSRF), CVE-2023-50769 (missing permission check)**  
**Severity (CVSS):** Medium  
**Affected plugin: nexus-jenkins-plugin**  
**Description:**

Nexus Platform Plugin 3.18.0-03 and earlier does not perform permission checks in methods implementing form validation.

This allows attackers with Overall/Read permission to connect to an attacker-specified HTTP server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Additionally, these form validation methods do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

Nexus Platform Plugin 3.18.1-01 requires POST requests and Overall/Administer permission for the affected form validation methods.

Nexus Platform Plugin is not currently distributed by the Jenkins Project due to licensing issues. The fixed version can be downloaded from the Sonatype website.

**Password stored in a recoverable format by OpenId Connect Authentication Plugin**

**SECURITY-3168 / CVE-2023-50770**  
**Severity (CVSS):** Medium  
**Affected plugin: oic-auth**  
**Description:**

OpenId Connect Authentication Plugin provides an anti-lockout feature, which allows administrators to define a local user account that can be used to recover access to Jenkins.

In OpenId Connect Authentication Plugin 2.6 and earlier the password to that account is stored in a recoverable format.

This allows attackers with access to the Jenkins controller file system to recover the plain text password of that account, likely gaining administrator access to Jenkins.

**Open redirect vulnerability in OpenId Connect Authentication Plugin**

**SECURITY-2979 / CVE-2023-50771**  
**Severity (CVSS):** Medium  
**Affected plugin: oic-auth**  
**Description:**

OpenId Connect Authentication Plugin 2.6 and earlier improperly determines that a redirect URL after login is legitimately pointing to Jenkins.

This allows attackers to perform phishing attacks by having users go to a Jenkins URL that will forward them to a different site after successful authentication.

**Tokens stored and displayed in plain text by Dingding JSON Pusher Plugin**

**SECURITY-3184 / CVE-2023-50772 (storage), CVE-2023-50773 (masking)**  
**Severity (CVSS):** Medium  
**Affected plugin: dingding-json-pusher**  
**Description:**

Dingding JSON Pusher Plugin 2.0 and earlier stores access tokens unencrypted in job config.xml files on the Jenkins controller as part of its configuration.

These tokens can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.

Additionally, the job configuration form does not mask these tokens, increasing the potential for attackers to observe and capture them.

**CSRF vulnerability in HTMLResource Plugin allows deleting arbitrary files**

**SECURITY-3183 / CVE-2023-50774**  
**Severity (CVSS):** High  
**Affected plugin: htmlresource**  
**Description:**

HTMLResource Plugin 1.02 and earlier does not require POST requests for an HTTP endpoint, resulting in a cross-site request forgery (CSRF) vulnerability.

This vulnerability allows attackers to delete arbitrary files on the Jenkins controller file system.

**CSRF vulnerability in Deployment Dashboard Plugin**

**SECURITY-3092 / CVE-2023-50775**  
**Severity (CVSS):** Medium  
**Affected plugin: ec2-deployment-dashboard**  
**Description:**

Deployment Dashboard Plugin 1.0.10 and earlier does not require POST requests for an HTTP endpoint, resulting in a cross-site request forgery (CSRF) vulnerability.

This vulnerability allows attackers to copy jobs.

**Tokens stored and displayed in plain text by PaaSLane Estimate Plugin**

**SECURITY-3182 / CVE-2023-50776 (storage), CVE-2023-50777 (masking)**  
**Severity (CVSS):** Medium  
**Affected plugin: paaslane-estimate**  
**Description:**

PaaSLane Estimate Plugin 1.0.4 and earlier stores PaaSLane authentication tokens unencrypted in job config.xml files on the Jenkins controller as part of its configuration.

These tokens can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.

Additionally, the job configuration form does not mask these tokens, increasing the potential for attackers to observe and capture them.

**CSRF vulnerability and missing permission checks in PaaSLane Estimate Plugin**

**SECURITY-3179 / CVE-2023-50778 (CSRF), CVE-2023-50779 (missing permission check)**  
**Severity (CVSS):** Medium  
**Affected plugin: paaslane-estimate**  
**Description:**

PaaSLane Estimate Plugin 1.0.4 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to connect to an attacker-specified URL using an attacker-specified token.

Additionally, these HTTP endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

**Severity**

*   SECURITY-2979: Medium
*   SECURITY-3092: Medium
*   SECURITY-3168: Medium
*   SECURITY-3179: Medium
*   SECURITY-3182: Medium
*   SECURITY-3183: High
*   SECURITY-3184: Medium
*   SECURITY-3203: Medium
*   SECURITY-3204: High
*   SECURITY-3205: High
*   SECURITY-3206: Medium
*   SECURITY-3327: Medium

**Affected Versions**

*   **Analysis Model API Plugin** up to and including 11.11.0
*   **Deployment Dashboard Plugin** up to and including 1.0.10
*   **Dingding JSON Pusher Plugin** up to and including 2.0
*   **HTMLResource Plugin** up to and including 1.02
*   **Nexus Platform Plugin** up to and including 3.18.0-03
*   **OpenId Connect Authentication Plugin** up to and including 2.6
*   **PaaSLane Estimate Plugin** up to and including 1.0.4
*   **Scriptler Plugin** up to and including 342.v6a\_89fd40f466

**Fix**

*   **Analysis Model API Plugin** should be updated to version 11.13.0
*   **Nexus Platform Plugin** should be updated to version 3.18.1-01
*   **Scriptler Plugin** should be updated to version 344.v5a\_ddb\_5f9e685

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

As of publication of this advisory, no fixes are available for the following plugins:

*   Deployment Dashboard Plugin
*   Dingding JSON Pusher Plugin
*   HTMLResource Plugin
*   OpenId Connect Authentication Plugin
*   PaaSLane Estimate Plugin

Learn why we announce these issues.

**Credit**

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

*   **Andrea Chiera, CloudBees, Inc.** for SECURITY-3179, SECURITY-3182, SECURITY-3183, SECURITY-3184, SECURITY-3203, SECURITY-3204, SECURITY-3205, SECURITY-3206
*   **Kevin Guerroudj, CloudBees, Inc.** for SECURITY-2979, SECURITY-3092
*   **Steve Marlowe <smarlowe@cisco.com> of Cisco ASIG** for SECURITY-3168

CVE-2023-50766: Jenkins Security Advisory 2023-12-13

Jenkins OpenId Connect Authentication Plugin 2.6 and earlier improperly determines that a redirect URL after login is legitimately pointing to Jenkins, allowing attackers to perform phishing attacks.

CVE-2023-50771: Jenkins Security Advisory 2023-12-13

Missing permission checks in Jenkins PaaSLane Estimate Plugin 1.0.4 and earlier allow attackers with Overall/Read permission to connect to an attacker-specified URL using an attacker-specified token.

CVE-2023-50779: Jenkins Security Advisory 2023-12-13

A cross-site request forgery (CSRF) vulnerability in Jenkins HTMLResource Plugin 1.02 and earlier allows attackers to delete arbitrary files on the Jenkins controller file system.

CVE-2023-50774: Jenkins Security Advisory 2023-12-13

Jenkins OpenId Connect Authentication Plugin 2.6 and earlier stores a password of a local user account used as an anti-lockout feature in a recoverable format, allowing attackers with access to the Jenkins controller file system to recover the plain text password of that account, likely gaining administrator access to Jenkins.

CVE-2023-50770: Jenkins Security Advisory 2023-12-13

In OpenBMC 2.9, crafted IPMI messages allow an attacker to cause a denial of service to the BMC via the netipmid (IPMI lan+) interface.

**OpenBMC**

OpenBMC is a Linux distribution for management controllers used in devices such as servers, top of rack switches or RAID appliances. It uses Yocto, OpenEmbedded, systemd, and D-Bus to allow easy customization for your platform.

**Setting up your OpenBMC project****1) Prerequisite**

See the Yocto documentation for the latest requirements

**Ubuntu**

sudo apt install git python3-distutils gcc g++ make file wget \\
    gawk diffstat bzip2 cpio chrpath zstd lz4 bzip2

**Fedora**

sudo dnf install git python3 gcc g++ gawk which bzip2 chrpath cpio \\
    hostname file diffutils diffstat lz4 wget zstd rpcgen patch

**2) Download the source**

git clone https://github.com/openbmc/openbmc
cd openbmc

**3) Target your hardware**

Any build requires an environment set up according to your hardware target. There is a special script in the root of this repository that can be used to configure the environment as needed. The script is called setup and takes the name of your hardware target as an argument.

The script needs to be sourced while in the top directory of the OpenBMC repository clone, and, if run without arguments, will display the list of supported hardware targets, see the following example:

    $ . setup <machine> [build_dir]
    Target machine must be specified. Use one of:
    
    bletchley               mori                    s8036
    dl360poc                mtjade                  swift
    e3c246d4i               mtmitchell              tatlin-archive-x86
    ethanolx                nicole                  tiogapass
    evb-ast2500             olympus-nuvoton         transformers
    evb-ast2600             on5263m5                vegman-n110
    evb-npcm750             p10bmc                  vegman-rx20
    f0b                     palmetto                vegman-sx20
    fp5280g2                qcom-dc-scm-v1          witherspoon
    g220a                   quanta-q71l             witherspoon-tacoma
    gbs                     romed8hm3               x11spi
    greatlakes              romulus                 yosemitev2
    gsj                     s2600wf                 zaius
    kudo                    s6q
    lannister               s7106
    

Once you know the target (e.g. romulus), source the setup script as follows:

**4) Build**

bitbake obmc-phosphor-image

Additional details can be found in the docs repository.

**OpenBMC Development**

The OpenBMC community maintains a set of tutorials new users can go through to get up to speed on OpenBMC development out here

**Build Validation and Testing**

Commits submitted by members of the OpenBMC GitHub community are compiled and tested via our Jenkins server. Commits are run through two levels of testing. At the repository level the makefile make check directive is run. At the system level, the commit is built into a firmware image and run with an arm-softmmu QEMU model against a barrage of CI tests.

Commits submitted by non-members do not automatically proceed through CI testing. After visual inspection of the commit, a CI run can be manually performed by the reviewer.

Automated testing against the QEMU model along with supported systems are performed. The OpenBMC project uses the Robot Framework for all automation. Our complete test repository can be found here.

**Submitting Patches**

Support of additional hardware and software packages is always welcome. Please follow the contributing guidelines when making a submission. It is expected that contributions contain test cases.

**Bug Reporting**

Issues are managed on GitHub. It is recommended you search through the issues before opening a new one.

**Questions**

First, please do a search on the internet. There's a good chance your question has already been asked.

For general questions, please use the openbmc tag on Stack Overflow. Please review the discussion on Stack Overflow licensing before posting any code.

For technical discussions, please see contact info below for Discord and mailing list information. Please don't file an issue to ask a question. You'll get faster results by using the mailing list or Discord.

**Will OpenBMC run on my Acme Server Corp. XYZ5000 motherboard?**

This is a common question, particularly regarding boards from popular COTS (commercial off-the-shelf) vendors such as Supermicro and ASRock. You can see the list of supported boards by running . setup (with no further arguments) in the root of the OpenBMC source tree. Most of the platforms supported by OpenBMC are specialized servers operated by companies running large datacenters, but some more generic COTS servers are supported to varying degrees.

If your motherboard is not listed in the output of . setup it is not currently supported. Porting OpenBMC to a new platform is a non-trivial undertaking, ideally done with the assistance of schematics and other documentation from the manufacturer (it is not completely infeasible to take on a porting effort without documentation via reverse engineering, but it is considerably more difficult, and probably involves a greater risk of hardware damage).

**However**, even if your motherboard is among those listed in the output of . setup, there are two significant caveats to bear in mind. First, not all ports are equally mature -- some platforms are better supported than others, and functionality on some "supported" boards may be fairly limited. Second, support for a motherboard is not the same as support for a complete system -- in particular, fan control is critically dependent on not just the motherboard but also the fans connected to it and the chassis that the board and fans are housed in, both of which can vary dramatically between systems using the same board model. So while you may be able to compile and install an OpenBMC build on your system and get some basic functionality, rough edges (such as your cooling fans running continuously at full throttle) are likely.

**Features of OpenBMC****Feature List**

*   Host management: Power, Cooling, LEDs, Inventory, Events, Watchdog
*   Full IPMI 2.0 Compliance with DCMI
*   Code Update Support for multiple BMC/BIOS images
*   Web-based user interface
*   REST interfaces
*   D-Bus based interfaces
*   SSH based SOL
*   Remote KVM
*   Hardware Simulation
*   Automated Testing
*   User management
*   Virtual media

**Features In Progress**

*   OpenCompute Redfish Compliance
*   Verified Boot

**Features Requested but need help**

*   OpenBMC performance monitoring

**Finding out more**

Dive deeper into OpenBMC by opening the docs repository.

**Technical Steering Committee**

The Technical Steering Committee (TSC) guides the project. Members are:

*   Roxanne Clarke, IBM
*   Nancy Yuen, Google
*   Patrick Williams, Meta
*   Terry Duncan, Intel
*   Sagar Dharia, Microsoft
*   Samer El-Haj-Mahmoud, Arm

**Contact**

*   Mail: openbmc@lists.ozlabs.org https://lists.ozlabs.org/listinfo/openbmc
*   Discord: https://discord.gg/69Km47zH98

CVE-2021-39295: GitHub - openbmc/openbmc: OpenBMC Distribution

Copy_from_user on 64-bit versions of the Linux kernel does not implement the __uaccess_begin_nospec allowing a user to bypass the "access_ok" check and pass a kernel pointer to copy_from_user(). This would allow an attacker to leak information. We recommend upgrading beyond commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47

Expand Up @@ -65,117 +65,13 @@ copy\_to\_user\_mcsafe(void \*to, const void \*from, unsigned len) static \_\_always\_inline \_\_must\_check unsigned long raw\_copy\_from\_user(void \*dst, const void \_\_user \*src, unsigned long size) { int ret = 0;  
if (!\_\_builtin\_constant\_p(size)) return copy\_user\_generic(dst, (\_\_force void \*)src, size); switch (size) { case 1: \_\_uaccess\_begin\_nospec(); \_\_get\_user\_asm\_nozero(\*(u8 \*)dst, (u8 \_\_user \*)src, ret, "b", "b", "\=q", 1); \_\_uaccess\_end(); return ret; case 2: \_\_uaccess\_begin\_nospec(); \_\_get\_user\_asm\_nozero(\*(u16 \*)dst, (u16 \_\_user \*)src, ret, "w", "w", "\=r", 2); \_\_uaccess\_end(); return ret; case 4: \_\_uaccess\_begin\_nospec(); \_\_get\_user\_asm\_nozero(\*(u32 \*)dst, (u32 \_\_user \*)src, ret, "l", "k", "\=r", 4); \_\_uaccess\_end(); return ret; case 8: \_\_uaccess\_begin\_nospec(); \_\_get\_user\_asm\_nozero(\*(u64 \*)dst, (u64 \_\_user \*)src, ret, "q", "", "\=r", 8); \_\_uaccess\_end(); return ret; case 10: \_\_uaccess\_begin\_nospec(); \_\_get\_user\_asm\_nozero(\*(u64 \*)dst, (u64 \_\_user \*)src, ret, "q", "", "\=r", 10); if (likely(!ret)) \_\_get\_user\_asm\_nozero(\*(u16 \*)(8 + (char \*)dst), (u16 \_\_user \*)(8 + (char \_\_user \*)src), ret, "w", "w", "\=r", 2); \_\_uaccess\_end(); return ret; case 16: \_\_uaccess\_begin\_nospec(); \_\_get\_user\_asm\_nozero(\*(u64 \*)dst, (u64 \_\_user \*)src, ret, "q", "", "\=r", 16); if (likely(!ret)) \_\_get\_user\_asm\_nozero(\*(u64 \*)(8 + (char \*)dst), (u64 \_\_user \*)(8 + (char \_\_user \*)src), ret, "q", "", "\=r", 8); \_\_uaccess\_end(); return ret; default: return copy\_user\_generic(dst, (\_\_force void \*)src, size); } return copy\_user\_generic(dst, (\_\_force void \*)src, size); }  
static \_\_always\_inline \_\_must\_check unsigned long raw\_copy\_to\_user(void \_\_user \*dst, const void \*src, unsigned long size) { int ret = 0;  
if (!\_\_builtin\_constant\_p(size)) return copy\_user\_generic((\_\_force void \*)dst, src, size); switch (size) { case 1: \_\_uaccess\_begin(); \_\_put\_user\_asm(\*(u8 \*)src, (u8 \_\_user \*)dst, ret, "b", "b", "iq", 1); \_\_uaccess\_end(); return ret; case 2: \_\_uaccess\_begin(); \_\_put\_user\_asm(\*(u16 \*)src, (u16 \_\_user \*)dst, ret, "w", "w", "ir", 2); \_\_uaccess\_end(); return ret; case 4: \_\_uaccess\_begin(); \_\_put\_user\_asm(\*(u32 \*)src, (u32 \_\_user \*)dst, ret, "l", "k", "ir", 4); \_\_uaccess\_end(); return ret; case 8: \_\_uaccess\_begin(); \_\_put\_user\_asm(\*(u64 \*)src, (u64 \_\_user \*)dst, ret, "q", "", "er", 8); \_\_uaccess\_end(); return ret; case 10: \_\_uaccess\_begin(); \_\_put\_user\_asm(\*(u64 \*)src, (u64 \_\_user \*)dst, ret, "q", "", "er", 10); if (likely(!ret)) { asm("":::"memory"); \_\_put\_user\_asm(4\[(u16 \*)src\], 4 + (u16 \_\_user \*)dst, ret, "w", "w", "ir", 2); } \_\_uaccess\_end(); return ret; case 16: \_\_uaccess\_begin(); \_\_put\_user\_asm(\*(u64 \*)src, (u64 \_\_user \*)dst, ret, "q", "", "er", 16); if (likely(!ret)) { asm("":::"memory"); \_\_put\_user\_asm(1\[(u64 \*)src\], 1 + (u64 \_\_user \*)dst, ret, "q", "", "er", 8); } \_\_uaccess\_end(); return ret; default: return copy\_user\_generic((\_\_force void \*)dst, src, size); } return copy\_user\_generic((\_\_force void \*)dst, src, size); }  
static \_\_always\_inline \_\_must\_check Expand Down

CVE-2023-0459: x86: get rid of small constant size cases in raw_copy_{to,from}_user() · torvalds/linux@4b842e4

Adobe Acrobat and Reader versions , 2019.021.20056 and earlier, 2017.011.30152 and earlier, 2017.011.30155 and earlier version, 2017.011.30152 and earlier, and 2015.006.30505 and earlier have a heap overflow vulnerability. Successful exploitation could lead to arbitrary code execution .

Security update available for Adobe Acrobat and Reader | APSB19-55

**Bulletin ID**

**Date Published**

**Priority**

APSB19-55

December 10, 2019

2

Adobe has released security updates for Adobe Acrobat and Reader for Windows and macOS. These updates address critical and  important vulnerabilities.  Successful exploitation could lead to arbitrary code execution in the context of the current user.    

Adobe recommends users update their software installations to the latest versions by following the instructions below.    

The latest product versions are available to end users via one of the following methods:    

*   Users can update their product installations manually by choosing Help > Check for Updates.     
    
*   The products will update automatically, without requiring user intervention, when updates are detected.      
    
*   The full Acrobat Reader installer can be downloaded from the Acrobat Reader Download Center.     
    

For IT administrators (managed environments):     

*   Download the enterprise installers from ftp://ftp.adobe.com/pub/adobe/, or refer to the specific release note version for links to installers.     
    
*   Install updates via your preferred methodology, such as AIP-GPO, bootstrapper, SCUP/SCCM (Windows), or on macOS, Apple Remote Desktop and SSH.     
    

Adobe categorizes these updates with the following priority ratings and recommends users update their installation to the newest version:    

**Vulnerability Category**

**Vulnerability Impact**

**Severity**

**CVE Number**

Out-of-Bounds Read  

Information Disclosure  

Important   

CVE-2019-16449  

CVE-2019-16456

CVE-2019-16457

CVE-2019-16458

CVE-2019-16461

CVE-2019-16465

Out-of-Bounds Write 

Arbitrary Code Execution   

Critical

CVE-2019-16450

CVE-2019-16454

Use After Free   

Arbitrary Code Execution     

Critical

CVE-2019-16445

CVE-2019-16448

CVE-2019-16452

CVE-2019-16459

CVE-2019-16464

CVE-2019-16471  

Heap Overflow 

Arbitrary Code Execution     

Critical

CVE-2019-16451

Buffer Error

Arbitrary Code Execution     

Critical

CVE-2019-16462

CVE-2019-16470  

Untrusted Pointer Dereference

Arbitrary Code Execution 

Critical

CVE-2019-16446

CVE-2019-16455

CVE-2019-16460

CVE-2019-16463

Binary Planting (default folder privilege escalation) 

Privilege Escalation

Important 

CVE-2019-16444

Security Bypass

Arbitrary Code Execution

Critical

CVE-2019-16453

Adobe would like to thank the following individuals and organizations for reporting the relevant issues and for working with Adobe to help protect our customers:    

*   Mateusz Jurczyk of Google Project Zero & Anonymous working with Trend Micro Zero Day Initiative (CVE-2019-16451)
*   Honc (章哲瑜) (CVE-2019-16444) 
*   Ke Liu of Tencent Security Xuanwu Lab. (CVE-2019-16445, CVE-2019-16449, CVE-2019-16450, CVE-2019-16454, CVE-2019-16471)
*   Sung Ta (@Mipu94) of SEFCOM Lab, Arizona State University (CVE-2019-16446, CVE-2019-16448) 
*   Aleksandar Nikolic of Cisco Talos (CVE-2019-16463)
*   Technical support team of HTBLA Leonding (CVE-2019-16453) 
*   Haikuo Xie of Baidu Security Lab (CVE-2019-16461)
*   Bit of STAR Labs (CVE-2019-16452) 
*   Xinyu Wan and Yiwei Zhang from Renmin University of China (CVE-2019-16455, CVE-2019-16460, CVE-2019-16462)
*   Bo Qu of Palo Alto Networks and Heige of Knownsec 404 Security Team (CVE-2019-16456) 
*   Zhibin Zhang of Palo Alto Networks (CVE-2019-16457)
*   Qi Deng, Ken Hsu of Palo Alto Networks (CVE-2019-16458) 
*   Lexuan Sun, Hao Cai of Palo Alto Networks (CVE-2019-16459)
*   Yue Guan, Haozhe Zhang of Palo Alto Networks (CVE-2019-16464) 
*   Hui Gao of Palo Alto networks (CVE-2019-16465)
*   Zhibin Zhang, Yue Guan of Palo Alto Networks (CVE-2019-16465)
*   Zhangqing and Zhiyuan Wang from cdsrc of Qihoo 360 (CVE-2019-16470)

March 26, 2020: Added acknowledgement for CVE-2019-16471, CVE-2019-16470

.

CVE-2019-16451: Adobe Security Bulletin

Provides autonomous and uninterrupted monitoring of unmanned IT locations at scale.

**AUSTIN, Texas, April 19, 2022**—RF Code, a pioneer of automated, real-time physical asset lifecycle management and environmental monitoring solutions for data centers, today announced the launch of Sentry, the company's first Software-as-a-Service (SaaS) innovation for decentralized edge computing locations. Sentry provides autonomous and uninterrupted monitoring of unmanned IT locations at scale. With deep intelligence and real-time notifications, Sentry makes it easier for IT professionals to monitor all of their remote IT spaces without being on-site.

"I can honestly say the Sentry device from RF Code will be an industry game-changer," said John Fletcher, Lead Technology Analyst for a major U.S. retail IT firm. "You get three monitoring devices in one unit ... temperature, humidity, and camera monitoring. Sentry is very easy to set up and cost-effective for our team's budget. It has real-time visual access and rich data of each IT environment that we're monitoring. It also has thermal scanning so I can check any room that houses critical IT equipment for potential hotspots that would cause an outage in the future.”

With the increased adoption of IoT devices, autonomous vehicles, as well as new work-from-anywhere (WFA) models, data center functions are moving to the edge to support these compute-intensive, zero-latency applications, and the demands of an increasingly remote workforce. By implementing a decentralized architecture, organizations like retailers, hospitals, hotels, manufacturers, and banks can improve localized computing power for end-users and the applications they need to drive business.

Without real-time environmental and critical asset monitoring tools in place, these unmanned and unmonitored IT spaces can be costly. Unplanned downtime, theft, and breaches can hurt an organization's bottom line costing thousands of dollars a minute.

"We developed Sentry as a way to meet the needs of a broader, underserved edge market with a simple, scalable, and affordable real-time IT asset and environmental monitoring solution," said Dale Quayle, CEO, RF Code. "Enterprises of all sizes need the ability to see, hear, and secure these edge environments as though they're onsite and Sentry makes it easier to prevent, mitigate, or remediate IT situations that threaten to disrupt normal business operations—from air quality and overheating to unauthorized access and other potential threats."

Sentry is easy to install and can be deployed in 20 minutes—all without the need for an on-site IT team, providing real-time visibility and remote monitoring from anywhere. Sentry's SaaS model makes it more affordable for organizations to monitor several IT locations at scale.

For more information and to see how Sentry monitors and secures remote edge locations, please visit http://rfcode.com/sentry.

**About RF Code**  
RF Code is an innovator of autonomous critical asset intelligence solutions. RF Code's real-time, active RFID technology improves IT asset tracking accuracy, full lifecycle management, and inventory utilization at data centers and edge locations. Autonomous IT asset data tracking and enhancement help RF Code customers slash manual error costs, optimize processes, maintain uptime, and comply with regulatory requirements. With patented wire-free active RFID sensors, open APIs, and real-time reporting capabilities, RF Code can be easily integrated with existing IT, facilities, and business systems.

RF Code is based in Austin, TX, and serves more than 200 organizations worldwide including Fortune 500, systems integrators, and value-added resellers. Additional information can be found at http://www.rfcode.com.

  

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

RF Code Announces Sentry, a New Edge Solution for Remote Locations

Faulty invitation mechanism enabled ‘package planting’ attacks

Faulty invitation mechanism enabled ‘package planting’ attacks

Open source software developers’ reputations could be abused to spread malicious NPM packages without their knowledge or consent, security researchers have revealed.

On April 26, the cybersecurity team at Aqua’s Team Nautilus published a security advisory on the issue, which “allowed threat actors to masquerade a malicious package as legitimate and trick unsuspecting developers into installing it”.

Until recently, GitHub’s NPM platform allowed any developer to be added to a project as a maintainer without their permission – a potential blind spot that threat actors could readily weaponize.

YOU MAY ALSO LIKE IBM database updates address critical vulnerabilities in third-party XML parser

If an attacker “carefully handpicks” trusted and popular maintainers, then adds them – without their approval – to a malicious package, this could make a package appear legitimate and encourage users to download it, said the researchers.

This technique has been dubbed “package planting” by Team Nautilus.

**Logic flaw**

“For instance, the package lodash is highly popular and credible,” the researchers say. “If we add its owners Mathias, jdalton, and bnjmnt4n to a new, malicious package, many developers may be tricked into thinking that this package is legitimate and even appealing.”

Lodash, a JavaScript library for utility functions, has been downloaded over 42 million times and has more than 154,000 dependents.

Developers whose reputations are exploited in this way would not be made aware that they were added as package maintainers due to a logic flaw in NPM’s invitation mechanism.

Furthermore, a threat actor could, in theory, add a popular maintainer to a malicious package and then report them for illicit activities – potentially undermining their reputation.

The logic issue was reported to GitHub’s bug bounty platform via HackerOne on February 10, and a fix was deployed on April 26 in the form of a new confirmation mechanism.

Read more of the latest software supply chain attack news

Adding a new maintainer to an NPM project without their approval is no longer possible.

“It’s important to use reliable sources for any third-party components and to secure your environment with solutions that can detect software supply chain threats such as package planting,” the researchers commented.

“NPM users should check that all the packages that are listed under their name truly belong to them, to make sure they weren’t added to any projects without their consent.”

**Package Analysis project**

In related news, on April 28, Google announced its support for the Open Source Security Foundation's (OpenSSF) Package Analysis project, a prototype scheme for clamping down on the propagation of malicious NPM packages.

The Package Analysis program is being developed to dynamically scan uploaded NPM packages for malicious signatures and to “identify when previously safe software begins acting suspiciously”.

Google is a member of OpenSSF. The tech giant conducted a study of 200 malicious NPM packages uploaded over the course of a month and found that most attacks are based on typosquatting and dependency confusion techniques.

“This effort is meant to improve the security of open source software by detecting malicious behavior, informing consumers selecting packages, and providing researchers with data about the ecosystem,” OpenSSF says. “Though the project has been in development for a while, it has only recently become useful following extensive modifications based on initial experiences.”

The Daily Swig has reached out to GitHub and Aqua with additional queries and we will update this story if and when we hear back.

RELATED Socket: New tool takes a proactive approach to prevent OSS supply chain attacks

Search

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