Has been identified a vulnerability in the APT package manager (CVE-2019-3462), what allows an attacker to initiate a spoof of the installed package whether the attacker has control of the repository mirror or can disrupt transit traffic between the user and the repository (MITM attack).
The problem was identified by security researcher Max Justicz, known for detecting vulnerabilities in the APK package manager (Alpine) and in the Packagist, NPM and RubyGems repositories.
The problem It is due to incorrect verification of the fields in the HTTP redirect processing code.
What is the problem?
This vulnerability allows an attacker to substitute his own content in the data transmitted within the HTTP session (Debian and Ubuntu use HTTP and not HTTPS to access the repository, assuming the digital signature is sufficient with matching metadata and packet size.)
The identified vulnerability allows the attacker power replace the transmitted packet, after which APT will perceive it as received from the official mirror and start the installation process.
Through the inclusion in the malicious package of scripts launched during installation, an attacker can achieve the execution of his code on a system with root privileges.
To download data from the repository, APT starts a child process with the implementation of a specific transport and organizes the interaction with this process using a simple text protocol with the division of commands by an empty line.
How do I detect the problem?
The essence of the problem is that the HTTP transport handler, upon receiving a response from the HTTP server with the header "Location:", it requests confirmation of the redirection from the main process.
Completely transferring the content of this header. Due to the lack of cleanliness of the transmitted special characters, an attacker can specify a line break in the "Location:" field.
Since this value will be decoded and transmitted through the communication channel with the main process, the attacker can simulate a different response from the HTTP transport handler and substitute the dummy 201 URI block.
For example, if the attacker substitutes the response when requesting a packet, this substitution will result in the transfer of the next block of data to the main process.
The calculation of hashes for the downloaded files is handled and the main process simply checks this data with hashes from the database of signed packages.
Among the metadata, an attacker can specify any value of test hashes linked in the database to actual signed packages, but it does not actually correspond to the hashes of the transferred file.
The main process will accept the response code replaced by the attack, look for the hash in the database and consider that the packet for which there is a correct digital signature is loaded, although in reality the value of the field with the hash is substituted in the communication channel with the main process using the attack and the file specified in the replaced metadata.
Downloading a malicious package is done by attaching the package to the Release.gpg file, during transfer.
This file has a predictable location on the file system and attaching a package to its startup does not affect the extraction of the digital signature from the repository.
When obtaining data, apt disables worker processes that specialize in the various protocols that will be used for data transfer.
The main process then communicates with these workers via stdin / stdout to tell them what to download and where to put it on the filesystem using a protocol that looks a bit like HTTP.
The main process will then submit its configuration and request a resource and the worker process will respond.
When the HTTP server responds with a redirect, the worker process returns a 103 Redirect instead of a 201 URI Done, and the main process uses this response to figure out which resource to request next.