Plexo Downloader Vulnerability

Daniel Carr, MSW

Sep 23

5 min read

Plexo is a new download manager built around an unusual capability: it can divide one file into chunks and retrieve those chunks simultaneously through several internet connections. Wi Fi, Ethernet, and tethered mobile data can all participate in the same transfer when they provide genuinely separate routes to the internet. Many people are wondering: is Plexo safe?

While reviewing the current Plexo downloader implementation, ElseBoard found a security weakness in the way the application handles redirects. This is a true Plexo Downloader vulnerability. A download that begins with an encrypted https:// address can be redirected to an unencrypted http:// address, and Plexo appears to follow that transition automatically without warning the user that transport security has been lost.

This is not evidence of remote control, malware inside Plexo, or an arbitrary code execution vulnerability. It is a transport integrity problem. Under the right conditions, a file that a user believes is being retrieved through HTTPS can spend the actual download phase traveling over HTTP.

Plexo automatically follows download redirects

Redirects are normal on the modern web. A download page may point at one address before sending the client to a storage server, content delivery network, regional mirror, or version specific file.

Plexo accounts for this behavior deliberately. During its initial examination of a download address, the application follows as many as five redirects before deciding which file it will retrieve. The chunk downloading system independently follows redirects as well.

The implementation selects its network client from the protocol of each new destination. When the current address begins with HTTPS, Plexo uses Node's HTTPS request system. When it does not, the downloader falls back to the HTTP request path.

What appears to be absent is a rule preventing an HTTPS origin from redirecting Plexo to HTTP.

An HTTPS link can therefore become an HTTP download

Consider a user beginning with an address such as:

https://downloads.example.com/program.exe

The server can respond with a redirect whose destination is:

http://cdn.example.com/program.exe

Plexo's redirect logic constructs a new destination from the Location response and continues following it. The probe does not appear to compare the security level of the original URL with the destination URL before accepting the redirect.

Once probing finishes, Plexo returns the final redirected URL to the application. The download is then started against that destination.

If the final destination is HTTP, the original HTTPS connection protected only the beginning of the redirect chain. The file itself can subsequently cross the network without TLS encryption.

Why the downgrade changes file integrity

HTTPS does more than conceal downloaded bytes. TLS authenticates the remote server and protects the traffic from modification while it moves between the server and the user.

Plain HTTP provides neither guarantee.

An attacker with the ability to interfere with the unencrypted portion of the connection could potentially alter the bytes returned by that HTTP server. The practical conditions depend heavily on the network involved, so this should not be interpreted as a claim that ordinary Plexo downloads can be remotely replaced at will.

The narrower finding is that Plexo allows the secure transport guarantee established by the original HTTPS URL to disappear during a redirect without presenting an obvious decision to the user.

Browsers have spent years adding increasingly visible treatment for insecure downloads and transitions. A dedicated download manager benefits from preserving the same security expectation when a user intentionally begins with an HTTPS address.

Plexo does perform integrity checks, but they solve a different problem

Plexo contains considerably more download integrity logic than a simplistic multi connection downloader.

Individual chunks are checked against the byte ranges requested from the server. Plexo rejects malformed partial responses, verifies expected lengths, tracks file size, and monitors ETag and Last-Modified values so that different versions of a remotely changing file are not accidentally assembled together.

The project also contains tests specifically intended to prevent Plexo from completing a download assembled from incompatible versions of the same remote file. Those protections address consistency between the pieces Plexo receives. They do not cryptographically authenticate the downloaded file.

An attacker capable of controlling an unencrypted HTTP transfer can potentially return internally consistent data. File size, range responses, ETag values, and modification dates can all be made consistent with the replacement content.

Plexo does not currently appear to calculate a trusted publisher supplied cryptographic hash for arbitrary downloads and compare the completed file against that independent value. Its existing integrity system therefore cannot substitute for HTTPS authentication.

The initial HTTPS connection still provides protection

The weakness has a meaningful limitation. An ordinary network observer cannot modify the original HTTPS response and simply invent an HTTP redirect without first defeating TLS.

A downgrade therefore requires the legitimate HTTPS server to provide an HTTP redirect, a redirect service or endpoint to become compromised, or some equivalent situation in which the secure side of the connection legitimately instructs Plexo to continue over HTTP.

Once that transition occurs, the remaining HTTP transfer no longer receives the protection of the original encrypted connection.

This makes the issue substantially narrower than a universal man in the middle vulnerability. It is nevertheless a security boundary that a download manager can enforce locally without depending on every server in a redirect chain to make the safest choice.

Plexo already treats other untrusted download information cautiously

The redirect behavior stands out because other sections of Plexo show deliberate defensive handling.

Remote servers can suggest filenames through HTTP headers, but Plexo sanitizes those names before creating local files. Directory separators are replaced so a server supplied filename cannot simply escape the selected download folder through a path such as ../../file.

The project's tests explicitly include a path traversal filename case. Windows reserved names and characters with filesystem significance receive additional handling.

Plexo also restricts external links opened from its Electron interface to HTTP and HTTPS schemes rather than passing arbitrary protocol handlers to the operating system. A comment in the implementation explicitly identifies arbitrary external schemes as an Electron security risk.

These choices indicate that Plexo is already treating server controlled input as something requiring boundaries. Redirect transport security appears to be one boundary that has not yet received equivalent enforcement.

The fix could preserve compatibility without blocking legitimate downloads

Plexo would not necessarily need to prohibit every HTTPS to HTTP redirect.

The application could reject the downgrade by default and explain why the transfer stopped. Another approach could display the final destination and require explicit confirmation before continuing over an unencrypted connection.

A stricter mode could require every redirect originating from HTTPS to remain on HTTPS. Users deliberately downloading from an HTTP address could continue doing so, since there would be no secure connection to downgrade in the first place.

The central change would be preserving the security expectation associated with the URL the user originally supplied.

Is Plexo safe?

The finding does not support describing Plexo itself as malicious or broadly unsafe. The current project includes several thoughtful protections around downloaded files, range validation, filenames, version changes, Electron links, and recovery from interrupted transfers.

The security concern is specific to redirect handling. A user can provide an HTTPS download address and ultimately receive the file through HTTP without Plexo clearly preserving or enforcing the original transport security level.

Most downloads may never encounter such a redirect. Sites that keep the complete redirect chain on HTTPS are unaffected.

For a download manager, however, transport integrity is part of the product's trust boundary. Plexo is already verifying that the pieces of a file fit together correctly. Preventing those pieces from silently moving onto an unauthenticated connection would extend that same defensive approach to the network carrying them.