FreshPorts - VuXML

Typo3 core team reports:

It has been discovered that the output of field validation errors in the Form Framework is vulnerable to cross-site scripting.

It has been discovered that t3:// URL handling and typolink functionality are vulnerable to cross-site scripting. Not only regular backend forms are affected but also frontend extensions which use the rendering with typolink.

It has been discovered that the output table listing in the Files backend module is vulnerable to cross-site scripting when a file extension contains malicious sequences. Access to the file system of the server - either directly or through synchronization - is required to exploit the vulnerability.

It has been discovered that the extraction of manually uploaded ZIP archives in Extension Manager is vulnerable to directory traversal. Admin privileges are required in order to exploit this vulnerability. Since TYPO3 v9 LTS, System Maintainer privileges are required as well.

Failing to properly escape user submitted content, class QueryGenerator is vulnerable to SQL injection. Having system extension ext:lowlevel installed and a valid backend user having administrator privileges are required to exploit this vulnerability.

It has been discovered that classes QueryGenerator and QueryView are vulnerable to insecure deserialization. Requirements for successfully exploiting this vulnerability (one of the following): - having system extension ext:lowlevel (Backend Module: DB Check) installed and valid backend user having administrator privileges - having system extension ext:sys_action installed and valid backend user having limited privileges

TYPO3 allows to upload files either in the backend user interface as well as in custom developed extensions. To reduce the possibility to upload potential malicious code TYPO3 uses the fileDenyPattern to deny e.g. user submitted PHP scripts from being persisted. Besides that it is possible for any editor to upload file assets using the file module (fileadmin) or changing their avatar image shown in the TYPO3 backend. Per default TYPO3 allows to upload and store HTML and SVG files as well using the mentioned functionalities. Custom extension implementations probably would also accept those files when only the fileDenyPattern is evaluated. Since HTML and SVG files - which might contain executable JavaScript code per W3C standard - could be directly displayed in web clients, the whole web application is exposed to be vulnerable concerning Cross-Site Scripting. Currently the following scenarios are known - given an authenticated regular editor is able to upload files using the TYPO3 backend: - directly target a potential victim to a known public resource in a URL, e.g. /fileadmin/malicious.svg or /fileadmin/malicious.html - using the TypoScript content object “SVG” (implemented in class ScalableVectorGraphicsContentObject) having renderMode set to inline for SVG files (available since TYPO3 v9.0) - custom implementations that directly output and render markup of HTML and SVG files SVG files that are embedded using an img src=”malicious.svg” tag are not vulnerable since potential scripts are not executed in these scenarios (see https://www.w3.org/wiki/SVG_Security). The icon API of TYPO3 is not scope of this announcement since SVG icons need to be registered using an individual implementation, which is not considered as user submitted content.

It has been discovered that request handling in Extbase can be vulnerable to insecure deserialization. User submitted payload has to be signed with a corresponding HMAC-SHA1 using the sensitive TYPO3 encryptionKey as secret - invalid or unsigned payload is not deserialized. However, since sensitive information could have been leaked by accident (e.g. in repositories or in commonly known and unprotected backup files), there is the possibility that attackers know the private encryptionKey and are able to calculate the required HMAC-SHA1 to allow a malicious payload to be deserialized. Requirements for successfully exploiting this vulnerability (all of the following): - rendering at least one Extbase plugin in the frontend - encryptionKey has been leaked (from LocalConfiguration.php or corresponding .env file).

< 8.7.30

< 9.5.13

Typo3 core team reports:

CKEditor 4.11 fixes an XSS vulnerability in the HTML parser reported by maxarr. The vulnerability stemmed from the fact that it was possible to execute XSS inside the CKEditor source area after persuading the victim to: (i) switch CKEditor to source mode, then (ii) paste a specially crafted HTML code, prepared by the attacker, into the opened CKEditor source area, and (iii) switch back to WYSIWYG mode. Although this is an unlikely scenario, we recommend to upgrade to the latest editor version.

Failing to properly encode user input, online media asset rendering (*.youtube and *.vimeo files) is vulnerable to cross-site scripting. A valid backend user account or write access on the server system (e.g. SFTP) is needed in order to exploit this vulnerability.

Failing to properly encode user input, notifications shown in modal windows in the TYPO3 backend are vulnerable to cross-site scripting. A valid backend user account is needed in order to exploit this vulnerability.

Failing to properly encode user input, login status display is vulnerable to cross-site scripting in the website frontend. A valid user account is needed in order to exploit this vulnerability - either a backend user or a frontend user having the possibility to modify their user profile.

Template patterns that are affected are:

• ###FEUSER_[fieldName]### using system extension felogin
• for regular frontend rendering (pattern can be defined individually using TypoScript setting config.USERNAME_substToken)

It has been discovered that cookies created in the Install Tool are not hardened to be submitted only via HTTP. In combination with other vulnerabilities such as cross-site scripting it can lead to hijacking an active and valid session in the Install Tool.

The Install Tool exposes the current TYPO3 version number to non-authenticated users.

Online Media Asset Handling (*.youtube and *.vimeo files) in the TYPO3 backend is vulnerable to denial of service. Putting large files with according file extensions results in high consumption of system resources. This can lead to exceeding limits of the current PHP process which results in a dysfunctional backend component. A valid backend user account or write access on the server system (e.g. SFTP) is needed in order to exploit this vulnerability.

TYPO3’s built-in record registration functionality (aka “basic shopping cart”) using recs URL parameters is vulnerable to denial of service. Failing to properly ensure that anonymous user sessions are valid, attackers can use this vulnerability in order to create an arbitrary amount of individual session-data records in the database.

< 8.7.21

< 9.5.2

Typo3 core team reports:

It has been discovered that TYPO3’s Salted Password system extension (which is a mandatory system component) is vulnerable to Authentication Bypass when using hashing methods which are related by PHP class inheritance. In standard TYPO3 core distributions stored passwords using the blowfish hashing algorithm can be overridden when using MD5 as the default hashing algorithm by just knowing a valid username. Per default the Portable PHP hashing algorithm (PHPass) is used which is not vulnerable.

Phar files (formerly known as "PHP archives") can act als self extracting archives which leads to the fact that source code is executed when Phar files are invoked. The Phar file format is not limited to be stored with a dedicated file extension - "bundle.phar" would be valid as well as "bundle.txt" would be. This way, Phar files can be obfuscated as image or text file which would not be denied from being uploaded and persisted to a TYPO3 installation. Due to a missing sanitization of user input, those Phar files can be invoked by manipulated URLs in TYPO3 backend forms. A valid backend user account is needed to exploit this vulnerability. In theory the attack vector would be possible in the TYPO3 frontend as well, however no functional exploit has been identified so far.

Failing to properly dissociate system related configuration from user generated configuration, the Form Framework (system extension "form") is vulnerable to SQL injection and Privilege Escalation. Basically instructions can be persisted to a form definition file that were not configured to be modified - this applies to definitions managed using the form editor module as well as direct file upload using the regular file list module. A valid backend user account as well as having system extension form activated are needed in order to exploit this vulnerability.

It has been discovered that the Form Framework (system extension "form") is vulnerable to Insecure Deserialization when being used with the additional PHP PECL package “yaml”, which is capable of unserializing YAML contents to PHP objects. A valid backend user account as well as having PHP setting "yaml.decode_php" enabled is needed to exploit this vulnerability.

< 7.6.30

< 8.7.17