Frauscher Sensortechnik GmbH FDS101 for FAdC/FAdCi v1.4.24 and all previous versions are vulnerable to a remote code execution (RCE) vulnerability via manipulated parameters of the web interface without authentication. This could lead to a full compromise of the FDS101 device.




2023-09-21 08:00 (CEST) VDE-2023-038  

**Frauscher: Multiple Vulnerabilities in FDS101**  
Share: Email | Twitter  

**

Published

**

2023-09-21 08:00 (CEST)

**

Last update

**

2023-09-21 07:26 (CEST)

**Vendor(s)**

Frauscher Sensortechnik GmbH  

**Product(s)**

Article No°

Product Name

Affected Version(s)

FDS101 for FAdC/FAdCi

<= 1.4.24

**

Summary

**

Frauscher Sensortechnik GmbH FDS101 for FAdC/FAdCi v1.4.24 and all previous versions are prone to multiple vulnerabilities which could lead up to a full compromise of the FDS101 device.

**

Vulnerabilities

**

**Last Update**

Sept. 7, 2023, 10:27 a.m.

**Weakness**

Improper Control of Generation of Code ('Code Injection') (CWE-94)

**Summary**

_Frauscher Sensortechnik GmbH FDS101 for FAdC/FAdCi v1.4.24 and all previous versions are vulnerable to a remote code execution (RCE) vulnerability via manipulated parameters of the web interface without authentication. This could lead to a full compromise of the FDS101 device._

**Last Update**

Sept. 7, 2023, 10:27 a.m.

**Weakness**

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (CWE-22)

**Summary**

_Frauscher Sensortechnik GmbH FDS101 for FAdC/FAdCi v1.4.24 and all previous versions are vulnerable to a path traversal vulnerability of the web interface by a crafted URL without authentication. This enables an remote attacker to read all files on the filesystem of the FDS101 device._

**Last Update**

Sept. 7, 2023, 10:28 a.m.

**Weakness**

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE-89)

**Summary**

_Frauscher Sensortechnik GmbH FDS101 for FAdC/FAdCi v1.4.24 and all previous versions are vulnerable to a SQL injection vulnerability via manipulated parameters of the web interface without authentication. The database contains limited, non-critical log information._

**

Impact

**

Please consult the CVE Entries above.

**

Solution

**

**Mitigation**

Security-related application conditions SecRAC

The railway operator must ensure that only authorised personnel or people in the company of authorised personnel have access to the Frauscher Diagnostic System FDS101.

The recommendation is to connect the Frauscher Diagnostic System FDS101 to a network of category 2.

If the Frauscher Diagnostic System FDS101 is connected to a network of category 3 (according to EN 50159:2010), then additional protective measures must be added.

**Remediation**

Update to FDS102 v2.10.1 or higher

**

Reported by

**

CERT@VDE coordinated with Frauscher Sensortechnik GmbH.

CVE-2023-4291: VDE-2023-038 | CERT@VDE

Frauscher Sensortechnik GmbH FDS101 for FAdC/FAdCi v1.4.24 and all previous versions are vulnerable to a path traversal vulnerability of the web interface by a crafted URL without authentication. This enables an remote attacker to read all files on the filesystem of the FDS101 device.


CVE-2023-4152: VDE-2023-038 | CERT@VDE

Frauscher Sensortechnik GmbH FDS101 for FAdC/FAdCi v1.4.24 and all previous versions are vulnerable to a SQL injection vulnerability via manipulated parameters of the web interface without authentication. The database contains limited, non-critical log information.





CVE-2023-4292


Dell SCG Policy Manager 5.16.00.14  contains a broken cryptographic algorithm vulnerability. A remote unauthenticated attacker may potentially exploit this vulnerability by performing MitM attacks and let attackers obtain sensitive information.



**Impact**

High

**Details**

**Third-party Component**

**CVEs**

**More Information**

Spring Boot 

CVE-2023-20883

See NVD for individual scores for each CVE  
http://nvd.nist.gov/  

Apache Tomcat

CVE-2023-34981

See NVD for individual scores for each CVE  
http://nvd.nist.gov/ 

Google Guava

CVE-2023-2976

See NVD for individual scores for each CVE  
http://nvd.nist.gov/ 

Bouncy Castle

CVE-2023-33201

See NVD for individual scores for each CVE  
http://nvd.nist.gov/ 

Azul Systems JRE 1.8

CVE-2023-21930, CVE-2023-21954, CVE-2023-21967, CVE-2023-21939, CVE-2023-21937,  
CVE-2023-21938, CVE-2023-21968

See NVD for individual scores for each CVE  
http://nvd.nist.gov/ 

VMWare Tools

CVE-2023-20867

See NVD for individual scores for each CVE  
http://nvd.nist.gov/ 

**Proprietary Code CVEs**

**Description**

**CVSS Base Score**

**CVSS Vector String**

 CVE-2023-39252

 Dell SCG Policy Manager 5.16.00.14  contains a broken cryptographic algorithm vulnerability. A remote unauthenticated attacker may potentially exploit this vulnerability by performing MitM attacks and let attackers obtain sensitive information.

 5.9 (Medium)

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N 

**Proprietary Code CVEs**

**Description**

**CVSS Base Score**

**CVSS Vector String**

 CVE-2023-39252

 Dell SCG Policy Manager 5.16.00.14  contains a broken cryptographic algorithm vulnerability. A remote unauthenticated attacker may potentially exploit this vulnerability by performing MitM attacks and let attackers obtain sensitive information.

 5.9 (Medium)

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N 

Dell Technologies recommends all customers consider both the CVSS base score and any relevant temporal and environmental scores that may impact the potential severity associated with a particular security vulnerability.

**Affected Products and Remediation**

**CVEs Addressed**

**Product** 

**Affected Versions**

**Remediated Versions**

**Link**

CVE-2023-20867, CVE-2023-20883, CVE-2023-21930, CVE-2023-21954, CVE-2023-21967, CVE-2023-21939, CVE-2023-21937, CVE-2023-21938, CVE-2023-21968,  
CVE-2023-2976, CVE-2023-33201, CVE-2023-34981, CVE-2023-39252

 SCG Policy Manager

 5.16.00.14

 5.18.00.00

Support for Secure Connect Gateway - Virtual Edition | Drivers & Downloads | Dell US

**CVEs Addressed**

**Product** 

**Affected Versions**

**Remediated Versions**

**Link**

CVE-2023-20867, CVE-2023-20883, CVE-2023-21930, CVE-2023-21954, CVE-2023-21967, CVE-2023-21939, CVE-2023-21937, CVE-2023-21938, CVE-2023-21968,  
CVE-2023-2976, CVE-2023-33201, CVE-2023-34981, CVE-2023-39252

 SCG Policy Manager

 5.16.00.14

 5.18.00.00

Support for Secure Connect Gateway - Virtual Edition | Drivers & Downloads | Dell US

**Workarounds and Mitigations**

None

**Revision History**

Revision

Date

Description

1.0

2023-09-20

Initial Release

**Related Information**

Dell Security Advisories and Notices  
Dell Vulnerability Response Policy  
CVSS Scoring Guide

CVE-2023-39252: DSA-2023-321: Security Update for Dell Secure Connect Gateway Security Policy Manager Vulnerabilities

Composer before 2016-02-10 allows cache poisoning from other projects built on the same host. This results in attacker-controlled code entering a server-side build process. The issue occurs because of the way that dist packages are cached. The cache key is derived from the package name, the dist type, and certain other data from the package repository (which may simply be a commit hash, and thus can be found by an attacker). Versions through 1.0.0-alpha11 are affected, and 1.0.0 is unaffected.

Skip to content

GitLab

Next

*   *   Why GitLab
    *   Pricing
    *   Contact Sales
    *   Explore
    
*   Why GitLab
*   Pricing
*   Contact Sales
*   Explore

*   Sign in
*   Get free trial

*   GitLab.org
*   GitLab Advisory Database Open Source Edition
*   Repository

*   advisories-community
*   packagist
*   composer
*   composer
*   **CVE-2015-8371.yml**

Find file Blame History Permalink

*   advisory sync: 2021-10-30 · 16628388
    
    🤖 GitLab Bot 🤖 authored Oct 30, 2021
    
    16628388

CVE-2015-8371: packagist/composer/composer/CVE-2015-8371.yml · main · GitLab.org / GitLab Advisory Database Open Source Edition · GitLab

The Tungstenite crate through 0.20.0 for Rust allows remote attackers to cause a denial of service (minutes of CPU consumption) via an excessive length of an HTTP header in a client handshake. The length affects both how many times a parse is attempted (e.g., thousands of times) and the average amount of data for each parse attempt (e.g., millions of bytes).

I work on an application that depends on tungstenite and is intended to offer server-side ws:// support to untrusted clients over the public Internet. There are hundreds of instances of the server application operated independently by our community members, and it's not feasible to have other devices (e.g., web application firewalls) protect them. We want to avoid situations where a small number of malicious HTTP requests can devour server CPU resources.

I'm seeing that a single HTTP request (i.e., before the "upgrade: websocket" happens) with any long header can cause request processing to take several **minutes** or more. For example, testing on a low-cost Ubuntu 23.04 VPS as the server, if the header is 20 million characters, there's more than 99% CPU consumption for five minutes. Similar results have been seen by multiple persons on various Linux systems with tungstenite 0.20.0. Relative to this tungstenite source code

pub fn single\_round<Obj: TryParse\>(mut self) -> Result<RoundResult<Obj, Stream\>\> {

trace!("Doing handshake round.");

match self.state {

HandshakeState::Reading(mut buf) => {

let read = buf.read\_from(&mut self.stream).no\_block()?;

match read {

Some(0) => Err(Error::Protocol(ProtocolError::HandshakeIncomplete)),

Some(\_) => Ok(if let Some((size, obj)) = Obj::try\_parse(Buf::chunk(&buf))? {

buf.advance(size);

RoundResult::StageFinished(StageResult::DoneReading {

result: obj,

stream: self.stream,

tail: buf.into\_vec(),

})

} else {

RoundResult::Incomplete(HandshakeMachine {

I'm seeing more than 4000 calls each to single\_round, try\_parse, and RoundResult::Incomplete. Looking at buf.len() here

fn try\_parse(buf: &\[u8\]) -> Result<Option<(usize, Self)\>\> {

let mut hbuffer = \[httparse::EMPTY\_HEADER; MAX\_HEADERS\];

I see a value between 100 and 200 on the first call, and the observed value gradually increases until it gets to 20 million after more than 4000 calls, five minutes later. At that point, a client that sent all the required headers gets an "HTTP/1.1 101 Switching Protocols" response with connection, upgrade, and sec-websocket-accept response headers. (If the client didn't send the required request headers, for example sending only My-Long-Header: followed by 20 million characters, the five minutes of CPU time still happens but of course "Switching Protocols" isn't allowed by tungstenite.)

We're able to work around this by checking for a large total header size (and dropping the client's connection) before any of tungstenite's code is called. However, maybe many other crates that depend on tungstenite could experience excessive CPU consumption if people can send long HTTP request headers.

The question is: should this issue be resolved within tungstenite, e.g., by rejecting long header lines (maybe in a configurable way) sooner, by avoiding calls to try\_parse until a complete header line (ending with \\n) is read, or by making some other change?

I don't think the issue can be attributed to the httparse crate - RFC 7230 3.2.5 allows unlimited header sizes, but tungstenite (in its role as code to implement a server) could choose an upper bound.

Is this a vulnerability in tungstenite, or is tungstenite simply not intended to remain performant when a header has millions of characters?

CVE-2023-43669: denial of service with long HTTP request header · Issue #376 · snapview/tungstenite-rs

Contao 3.x before 3.5.32 allows XSS via the unsubscribe module in the frontend newsletter extension.

A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.

This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.

ֿInjecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.

Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.

The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.

**Types of attacks**

There are a few methods by which XSS can be manipulated:

Type

Origin

Description

**Stored**

Server

The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.

**Reflected**

Server

The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.

**DOM-based**

Client

The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.

**Mutated**

The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.

**Affected environments**

The following environments are susceptible to an XSS attack:

*   Web servers
*   Application servers
*   Web application environments

**How to prevent**

This section describes the top best practices designed to specifically protect your code:

*   Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
*   Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL encoded equivalents.
*   Give users the option to disable client-side scripts.
*   Redirect invalid requests.
*   Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
*   Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
*   Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.

CVE-2018-5478: Snyk Vulnerability Database | Snyk

web\ViewAction in Yii (aka Yii2) 2.x before 2.0.5 allows attackers to execute any local .php file via a relative path in the view parameeter.

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

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

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

**Provide feedback**

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

Sign up

CVE-2015-5467: security-advisories/yiisoft/yii2-dev/CVE-2015-5467.yaml at master · FriendsOfPHP/security-advisories

SimpleImportProduct Prestashop Module v6.2.9 was discovered to contain a SQL injection vulnerability via the key parameter at send.php.

This blog post details an SQL Injection we found within SimpleImportProduct, a Prestashop module developed by MyPrestaModules. In modules/simpleimportproduct/send.php there is the following code:

      if ( Tools::getValue('remove') == true){  
        $key = Tools::getValue('key');  
        $key = pSQL($key);  
        Db::getInstance()->delete('simpleimport_tasks', "import_settings=$key");
    

This is vulnerable to SQL injection which allows an attacker to extract data from the database.  
The key parameter does get sanitized by pSQL() but when it’s put in the query it’s not surrounded by quotes so an attacker can still manipulate the query. This is a similar situation to an SQLi I found in a different Prestashop module.

Adding quotes around the key would be sufficient to patch this SQLi:

    Db::getInstance()->delete('simpleimport_tasks', "import_settings='$key'");
    

**Proof of Concept**

To test this we used SQLmap on a local Prestashop install. Care should be taken when testing for this as it is within a DELETE SQL query and can result in records getting deleted. SQLMap command:

    sqlmap -u "http://localhost:8080/modules/simpleimportproduct/send.php?ajax=true&remove=true&key=1*" --threads=10 --random-agent --dbms=mysql --level=5 --risk=3 --tables  
    

It’s a “blind” SQLi as it doesnt affect the contents of the page so information is extracted using SLEEP() to change the time it takes to respond.

**Timeline**

Date

Action

10/07/2023

Issue discovered during a pentest

12/07/2023

Reported issue to MyPrestaModules

29/07/2023

Requested CVE from MITRE

??/08/2023

Patch released

28/08/2023

Number CVE-2023-39675 assigned

07/09/2023

Blog post released

CVE-2023-39675: SQLi in SimpleImportProduct Prestashop Module CVE-2023-39675

Cross Site Scripting (XSS) vulnerability in Netbox 3.5.1, allows attackers to execute arbitrary code via Name field in device-roles/add function.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account