21

If I download archived data from a possibly untrusted source at which point am I at possible risk of harming my system:

  1. Initially downloading and saving the archived data (still packed)
  2. Unpacking the archived data
  3. Executing any file from the unpacked archive

At point 3 I will obviously be at risk, but what about 1-2?

6
  • 5
    About the best someone can answer without a concrete case is, "it depends". Without details like how you are downloading and how you are unpacking it is hard to say. For example, I believe cURL, Wget and some browsers upack the ZIP for you, unless you take special measures to avoid the behavior. Or, an email client could unpack the ZIP file for you for previewing contents. However, using OpenSSL to fetch it will just save it to the filesystem.
    – user29925
    Jul 17, 2019 at 18:14
  • ...I can't help but ask if you can trust that the source will actually provide the file in step #1, and not do anything else (such as attempt to sneak something into your system instead of or before sending the archive itself). Jul 18, 2019 at 18:33
  • @jww neither cURL nor wget documentation mention that they unpack ZIP files automatically. Could you clarify you statement?
    – AlexD
    Jul 22, 2019 at 19:49
  • @AlexD - I remember seeing the issue in passing on one of the GNU mailing lists. See [Bug-wget] New wget (1.19.2): Unexpected download behaviour for gzip-compressed tarballs (HTTP-header dependent). Wget started decompressing archives automatically. I don't know if it was a new option that was "on by default", or if it was hard coded behavior that cannot be changed, or if it was a mistake.
    – user29925
    Jul 23, 2019 at 1:33
  • @AlexD - I think a more interesting case is Browsers and Email clients. They will prefetch links, start opening files and interpreting content without user interactions. Gutmann warns about the embedded Turing machines in his book Engineering Security, p.197: "A better use of the time and effort required for user education would have been to concentrate on making the types of documents that are sent as attachments purely passive and unable to cause any action on the destination machine."
    – user29925
    Jul 23, 2019 at 2:04

2 Answers 2

25

1 should not present any danger as long as the file is just saved somewhere and no attempts to open it with anything are made. If you view it even with a text editor, there's already a small danger of exploits.

In the case of 2 there are vulnerabilities and exploits, so there are dangers. Some examples of such possible scenarios:

  • Arbitrary file writes caused by .tar.gz archive symbolic link (symlink) vulnerabilities that are exploited because of how Bower (a popular web package manager) extracts such archives

  • CVE-2018-20250 is an absolute path traversal vulnerability in unacev2.dll, the DLL file used by WinRAR to parse ACE archives that has not been updated since 2005. A specially crafted ACE archive can exploit this vulnerability to extract a file to an arbitrary path and bypass the actual destination folder. In its example, CPR is able to extract a malicious file into the Windows Startup folder.

  • CVE-2018-20252 and CVE-2018-20253 are out-of-bounds write vulnerabilities during the parsing of crafted archive formats. Successful exploitation of these CVEs could lead to arbitrary code execution.

  • Zip Slip which attackers might use to target files they can execute remotely, such as parts of a website, or files that a computer or user are likely to run anyway, like popular applications or system files.

  • Helm Chart Archive File Unpacking Path Traversal Vulnerability.

  • CVE-2015-5663 - the file-execution functionality in WinRAR before 5.30 beta 5 allows local users to gain privileges via a Trojan horse file with a name similar to an extension-less filename that was selected by the user.

  • CVE-2005-3262 allows remote attackers to execute arbitrary code via format string specifiers in a UUE/XXE file, which are not properly handled when WinRAR displays diagnostic errors related to an invalid filename

There are plenty more examples and databases with such vulnerabilities and even most of them got fixed in later versions of the software, a risk still exists.

So therefore, [2] is risky and should be handled with care.

11
  • 22
    Another interesting threat of unpacking untrusted archives are zip bombs: Specially crafted archives which seem small but unpack to huge amounts of data.
    – Philipp
    Jul 17, 2019 at 8:11
  • 7
    I think it would be even more rare (and bordering on extreme paranoia), but it might be possible that the act of downloading (or copying) the file could exploit a vulnerability in a web browser/wget/curl/rsync/etc. I'm not sure if there's ever been an example of this.
    – mbrig
    Jul 17, 2019 at 16:36
  • 5
    If the system has an antivirus installed, the archive itself could be crafted to exploit a bug in the file-scanning routines that run when the file is downloaded too. See for example some of the CVEs for Windows Defender: cvedetails.com/vulnerability-list/vendor_id-26/product_id-9767/… Jul 17, 2019 at 18:14
  • 1
    @mbrig Well, in the end points 1 and 2 are mostly "identical" from a security perspective. They both deal with programs handling data in some way. If we include the possibility of bugs that allow an attacker to perform arbitrary code execution it can happen in both case 1 and 2. Downloading a file may be a "simpler" action with less chances of errors, but if you think at all the bugs in networking software (think heartbleed for example...) it's absolutely not out of this world. If you don't care about software bugs then opening a file in a text editor is fine, only execution is an issue.
    – Bakuriu
    Jul 17, 2019 at 18:34
  • 3
    Depending on the system, thumbnailers, previewers, and indexers could be exploited.
    – forest
    Jul 18, 2019 at 1:59
9

In theory all of these places could be exploited. I am not going to go into specific exploits available as these change constantly with archive format and moving tech:

Initially downloading and saving the archived data (still packed)

It is unlikely but it is possible that your download manager / web browser does have some kind of exploit. You say the source is untrusted therefore the server could try and attack your download program using exploits in its implementation or weaknesses in the file transfer protocol you are using. These exploits are rare but not unheard of. But fundamentally unless you are certain your software is entirely unexploitable any network connection with a malicious server could result in an attack.

You can somewhat mitigate this by sandboxing the download software with only minimal permissions and access needed to the location you wish to download to and the network stack. This mostly mitigates this weakness assuming your OS permission model or sandboxing software do not also have exploits.

Unpacking the archived data

There are numerous attacks over the years involving using poisoned archive files to run arbitrary code on a system by exploiting weaknesses in the archive format or decompression software. These are probably more common than the above weakness.

The main protections are again making sure to give the extraction program minimal permissions and potentially sand-boxing it to ensure it can do minimal damage if it is attacked successfully. Caveats above apply.

Executing any file from the unpacked archive

This is obviously enormously risky, and the same issues as running and malicious software applies. It is relatively easy for software when run explicitly to break many sandboxes and permission system protections so all bets are off. You can have some safety running the software in a hardened VM but this still doesnt fully protect you short of using an airgapped machine to run the programs which is then destroyed.

TLDR

All of these steps are fairly risky, but each successive step is probably more dangerous than the last.

7
  • 1
    When downloading, a system should only read and write ASCII blocks so there is no content interpreted and you can't sabotage that in any way. The process which leads to the download is the one that can actually be exploited. So you don't practically use the actual archive for exploiting, therefore this type of risk is unrelated to the initial question.
    – Overmind
    Jul 18, 2019 at 8:11
  • @Overmind some download-managers could peak at the first bytes of the binary file to guess mime-type (if not correctly provided by the server) a vulnerability in this code could be exploited by a specially crafted file.
    – Falco
    Jul 18, 2019 at 9:48
  • If you craft that it will become an invalid archive (if there was one in the 1st place) so we practically have a crafted file designed against a specific DM (download manager), not a true archive / not archived data as the topic suggested.
    – Overmind
    Jul 18, 2019 at 11:47
  • 1
    @Overmind: Download data is binary, not ASCII.
    – JRE
    Jul 18, 2019 at 14:20
  • 1
    On many systems the download stage is also where any potential malicious code gets it's first crack at the attack surface presented by the hosts anti-malware solution (at least on hosts running a realtime anti-malware service) since those do often accept bytes from the network stack in real time and does pass them as arguments to complex functions. Granted this sort of code is generally audited to a higher standard than most and often attempts are made to sandbox it to limit the scope of exploits should they be found but exploitable bugs can still creep in so there is a non zero risk here too.
    – MttJocy
    Jul 18, 2019 at 17:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .