#php

It has been discovered that the Import/Export module is susceptible to broken access control. Regular backend users have access to import functionality which usually only is available to admin users or users having User TSconfig setting options.impexp.enableImportForNonAdminUser explicitly enabled. Database content to be imported however was correctly checked against users’ permissions and not affected. However it was possible to upload files by-passing restrictions of the file abstraction layer (FAL) - however this did not affect executable files which have been correctly secured by fileDenyPattern. Currently the only known vulnerability is to directly inject *.form.yaml files which could be used to trigger the vulnerability of TYPO3-CORE-SA-2018-003 (privilege escalation & SQL injection) - which requires the Form Framework (ext:form) being available on an according website. CVSSv3 scoring is based on this scenario. A valid backend user account is needed in order to exploit this vu...

Due to missing file extensions in $GLOBALS['TYPO3_CONF_VARS']['BE'][‘fileDenyPattern’], backend users are allowed to upload *.phar, *.shtml, *.pl or *.cgi files which can be executed in certain web server setups. A valid backend user account is needed in order to exploit this vulnerability. Derivatives of Debian GNU Linux are handling *.phar files as PHP applications since PHP 7.1 (for unofficial packages) and PHP 7.2 (for official packages). The file extension *.shtml is bound to server side includes which are not enabled per default in most common Linux based distributions. File extension *.pl and *.cgi require additional handlers to be configured which is also not the case in most common distributions (except for /cgi-bin/ location).

When using the TYPO3 backend in order to create new backend user accounts, database records containing insecure or empty credentials might be persisted. When the type of user account is changed - which might be entity type or the admin flag for backend users - the backend form is reloaded in order to reflect changed configuration possibilities. However, this leads to persisting the current state as well, which can result into some of the following: - account contains empty login credentials (username and/or password) - account is incomplete and contains weak credentials (username and/or password) Albeit the functionality provided by the TYPO3 core cannot be used either with empty usernames or empty passwords, it still can be a severe vulnerability to custom authentication service implementations. This weakness cannot be directly exploited and requires interaction on purpose by some backend user having according privileges.

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.

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 (which is the default value according to PHP documentation).

Aquatronica Control System version 5.1.6 has a tcp.php endpoint on the controller that is exposed to unauthenticated attackers over the network. This vulnerability allows remote attackers to send a POST request which can reveal sensitive configuration information, including plaintext passwords. This can lead to unauthorized access and control over the aquarium controller, compromising its security and potentially allowing attackers to manipulate its settings.

This Metasploit module abuses a feature of the sudo command on Progress Flowmon. Certain binary files are allowed to automatically elevate with the sudo command. This is based off of the file name. This includes executing a PHP command with a specific file name. If the file is overwritten with PHP code it can be used to elevate privileges to root. Progress Flowmon up to at least version 12.3.5 is 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.

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.

Symfony 2.0.11 carried a [similar] XXE security fix, however, on review of ZF2 I also noted a vulnerability to XML Entity Expansion (XEE) attacks whereby all extensions making use of libxml2 have no defense against XEE Quadratic Blowup Attacks. The vulnerability is a function of there being no current method of disabling custom entities in PHP (i.e. defined internal to the XML document without using external entities). In a QBA, a long entity can be defined and then referred to multiple times in document elements, creating a memory sink with which Denial Of Service attacks against a host's RAM can be mounted. The use of the LIBXML_NOENT or equivalent option in a dependent extension amplified the impact (it doesn't actually mean "No Entities"). In addition, libxml2's innate defense against the related Exponential or Billion Laugh's XEE attacks is active only so long as the LIBXML_PARSEHUGE is NOT set (it disables libxml2's hardcoded entity recursion limit). No instances of these two opt...