Can .zip files have malware _in their structure_?

I've just downloaded a new set of maps for my SatNav (what in US is
called a GPS); it's a 6.7G .zip file.

Can just looking at what's in it - either using Windows' own .zip
handler that's built into explorer, or anything else - trigger any
malware? I'm not talking about _opening_ any of the files (running
executables, opening documents, even looking at pictures), just looking
at the folder and file names, and more particularly dates.

I'd assumed - because of the size - that it might take an age to scan it
with AV; in practice, AVG scanned it in a quite reasonable time, but I
thought I'd ask anyway, as I imagine the answer might be of widespread
interest.

I don't _think_ just _looking_ inside a .zip file should be capable of
_running_ anything. But I could be wrong.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Lucy Worsley takes tea in Jane Austen's Regency Bath. - TV "Choices" listing,
RT 2017-5-27

"J. P. Gilliver (John)" wrote

| Can just looking at what's in it - either using Windows' own .zip
| handler that's built into explorer, or anything else - trigger any
| malware?

I've occasionally received ZIP attachments in email
that seem to be meant as attacks. I've tried reconstituting
the base-64 to see what's in there. I'm thinking maybe it
had PE file markers... but I don't remember now. And I'm
afraid I don't know any more about it. Bu I figured there
must be at least one ZIP program that's vulnerable.

Maybe open it with something like 7-ZIP when you're uncertain.

On 30/01/2020 14.07, J. P. Gilliver (John) wrote:
I've just downloaded a new set of maps for my SatNav (what in US is
called a GPS); it's a 6.7G .zip file.

Can just looking at what's in it - either using Windows' own .zip
handler that's built into explorer, or anything else - trigger any
malware? I'm not talking about _opening_ any of the files (running
executables, opening documents, even looking at pictures), just looking
at the folder and file names, and more particularly dates.

I'd assumed - because of the size - that it might take an age to scan it
with AV; in practice, AVG scanned it in a quite reasonable time, but I
thought I'd ask anyway, as I imagine the answer might be of widespread
interest.

Normally, an AV only analyzes certain file types: those that can be
executed, or files with macros or scripts inside (like office files). A
movie is normally skipped, for instance. I recall there are attacks
based on some vulnerability in photos, but the thing to do is patch the
viewer, dunno if an AV checks for those files (not strictly a virus).


I don't _think_ just _looking_ inside a .zip file should be capable of
_running_ anything. But I could be wrong.

I don't think so. After all, that what has to be done to analyze emails
with attachments.

There were zip bombs: a relatively small zip that when expanded were
huge (I made one by compressing a CD full of zeros, for instance). Such
a file sent by email can crash the spam/virus scanner.

--
Cheers, Carlos.

J. P. Gilliver (John) wrote:
I've just downloaded a new set of maps for my SatNav (what in US is
called a GPS); it's a 6.7G .zip file.

Can just looking at what's in it - either using Windows' own .zip
handler that's built into explorer, or anything else - trigger any
malware? I'm not talking about _opening_ any of the files (running
executables, opening documents, even looking at pictures), just looking
at the folder and file names, and more particularly dates.

I'd assumed - because of the size - that it might take an age to scan it
with AV; in practice, AVG scanned it in a quite reasonable time, but I
thought I'd ask anyway, as I imagine the answer might be of widespread
interest.

I don't _think_ just _looking_ inside a .zip file should be capable of
_running_ anything. But I could be wrong.

ZIP files come in different flavors.

The feature sets tend to be repeated
(different archive formats have the same features).

*******

my_self_extracting_SFX.exe

That's an example of a ZIP file with a small PE at the
beginning of the file, which functions as an unpacker.

Doing that, though, in that way, "attracts attention".
If you emailed that, Google would remove the attachment
(because it's "executable").

That's obviously a bad idea, an idea from a previous
naive era.

*******

normal.zip

Now there should be no PE part, and it comes closer to an
archive format.

This is safer, but could be used to hide an executable
inside, such as README.txt.exe for usage on machines
that have "show file extension" turned off. It still
requires the user to double-click on README.txt.exe, when
they see README.txt on the screen, but the full filename
is not displayed in File Explorer.

There can still be perils associated with the format
that way, which are "normal perils" for a "platform with
a bad default for its file explorer program". Displaying
the extension should *never ever* be turned off. Just as
Autorun on any storage media, should be set to 110% security
level (belt and suspenders, no execution of autorun.inf).

You can't really have a discussion about ZIP, without sooner
or later having to discuss the shortcomings of the platform
(.cab/.zip integration, bad hygiene on file extensions).

Paul

On Thu, 30 Jan 2020 13:07:54 +0000, J. P. Gilliver (John) wrote:
I've just downloaded a new set of maps for my SatNav (what in US is
called a GPS); it's a 6.7G .zip file.

Can just looking at what's in it - either using Windows' own .zip
handler that's built into explorer, or anything else - trigger any
malware? I'm not talking about _opening_ any of the files (running
executables, opening documents, even looking at pictures), just looking
at the folder and file names, and more particularly dates.

I'd assumed - because of the size - that it might take an age to scan it
with AV; in practice, AVG scanned it in a quite reasonable time, but I
thought I'd ask anyway, as I imagine the answer might be of widespread
interest.

I don't _think_ just _looking_ inside a .zip file should be capable of
_running_ anything. But I could be wrong.

Everything can have a malware in it, even if the file doesn't contain
executable code, or interpretable data for execution.

Remember the old (Win95 era) GIF image reader bug? The GIF reader which is
used by MSIE - where GIF data can be designed in such a way to cause the
reader to crash and execute the malware code embedded in the GIF. It caused
a buffer overflow error, but there are other kinds of error which can be
exploited to execute a code. Basically, if a file reader/parser can still
crash, there's a possibility of exploitation.

On 1/30/20 7:07 AM, J. P. Gilliver (John) wrote:

[snip]

I don't _think_ just _looking_ inside a .zip file should be capable of
_running_ anything. But I could be wrong.

It SHOULDNT. but that doesn't mean some zip file handler doesn't. That
reminds me of when people found malware in image files. Files that
should be just DATA.

--
Mark Lloyd
http://notstupid.us/

"Keeping current in your life." - an electric utility

In message , Paul
writes:
[]
ZIP files come in different flavors.
[]
my_self_extracting_SFX.exe

That's an example of a ZIP file with a small PE at the
beginning of the file, which functions as an unpacker.

Oh, anything with .exe would definitely be treated with suspicion here!

Doing that, though, in that way, "attracts attention".
If you emailed that, Google would remove the attachment
(because it's "executable").

(There was a time when you could send benign .exes, by changing the
extension - to .exf, say, or even .txt - and telling the recipient to
rename it back before use; but these days I think such scanners go by
content rather than name. Meaning I now can't send someone a .exe even
if they want it. [Encrypted .zip still worked last time I used it, but
that involves more complexity than I'd want to inflict on some of my
less computer-savvy friends and relations.])
[]
normal.zip

Now there should be no PE part, and it comes closer to an
archive format.

This is safer, but could be used to hide an executable
inside, such as README.txt.exe for usage on machines
that have "show file extension" turned off. It still
requires the user to double-click on README.txt.exe, when
they see README.txt on the screen, but the full filename
is not displayed in File Explorer.

Agreed.

There can still be perils associated with the format
that way, which are "normal perils" for a "platform with
a bad default for its file explorer program". Displaying
the extension should *never ever* be turned off. Just as

Totally agree. I'm amazed MS still (AFAIK) have that default (on W10 as
well as all previous); whatever one may think of their current morals, I
would have thought they'd have changed that one by now - I can't see how
it _benefits_ them not to have changed it.

Autorun on any storage media, should be set to 110% security
level (belt and suspenders, no execution of autorun.inf).

Good policy.

You can't really have a discussion about ZIP, without sooner
or later having to discuss the shortcomings of the platform
(.cab/.zip integration, bad hygiene on file extensions).

Paul
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Subtlety is the art of saying what you think and getting out of the way
before it is understood." - Fortunes

In message , JJ
writes:
[]
Everything can have a malware in it, even if the file doesn't contain
executable code, or interpretable data for execution.

Remember the old (Win95 era) GIF image reader bug? The GIF reader which is
used by MSIE - where GIF data can be designed in such a way to cause the
reader to crash and execute the malware code embedded in the GIF. It caused
a buffer overflow error, but there are other kinds of error which can be

(I thought that was JPEGs, but it might have been GIFs. Or there might
have been a JPEG one too.) It wasn't just MSIE - anything that had been
compiled using some (Microsoft I think) image-processing libraries was
vulnerable.

exploited to execute a code. Basically, if a file reader/parser can still
crash, there's a possibility of exploitation.

I haven't _heard_ of a .zip handler crashing, but I guess anything can.
(The malware writer would have to make it crash in a way that went on to
run his code, but that's certainly plausible.)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Subtlety is the art of saying what you think and getting out of the way
before it is understood." - Fortunes

J. P. Gilliver wrote:

I don't _think_ just _looking_ inside a .zip file should be capable of
_running_ anything. But I could be wrong.

I've heard of "cleverly corrupted" zip files where sections of the data
structure overlap each other, there can be a malicious payload

https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/double-loaded-zip-file-delivers-nanocore

John,

I don't _think_ just _looking_ inside a .zip file should be capable of
_running_ anything.

True. But it /could/ entice the program thats build to peer inside such zip
files to malfunction. You know, the well-known buffer overflows you can
find in most any software ...

Although I'm not aware of zip-file malware that executes just by /looking/,
AFAIK its rather possible to muck around with the folderstructure,
effectivily creating kind of never-ending (file and/or folder) list, which
will (ofcourse) exhaust the resources of any machine and making it crash.

Regards,
Rudy Wieser

"J. P. Gilliver (John)" wrote

| (I thought that was JPEGs, but it might have been GIFs. Or there might
| have been a JPEG one too.) It wasn't just MSIE - anything that had been
| compiled using some (Microsoft I think) image-processing libraries was
| vulnerable.
|

Yes. I think it was a bug in early versions of
gdiplus.dll, if I remember correctly.

Mayayana wrote:
"J. P. Gilliver (John)" wrote

| (I thought that was JPEGs, but it might have been GIFs. Or there might
| have been a JPEG one too.) It wasn't just MSIE - anything that had been
| compiled using some (Microsoft I think) image-processing libraries was
| vulnerable.
|

Yes. I think it was a bug in early versions of
gdiplus.dll, if I remember correctly.

https://searchsecurity.techtarget.co...ies-in-LibTIFF

https://security.stackexchange.com/q...ger-an-exploit

Some of the items date from 2004-2006.

And while GDIplus is getting blamed, the root cause
typically is big companies reusing the Independent JPEG Group
library code without doing a code review. The code needs to
be hardened against stack smashing. There are still CVEs
showing up in 2016 against stuff like that. Multiple libraries
have issues - JPEG, TIFF, GIF, WMF, if it's got letters in the
name, it's been exploited.

Back when the original issues were discovered, it was a wakeup
call against lazy devs just plopping in code they hadn't even
opened and looked at. I think they have processes now, to ensure
the high school intern looks at the code first.

Paul

"J. P. Gilliver (John)" wrote:

I've just downloaded a new set of maps for my SatNav (what in US is
called a GPS); it's a 6.7G .zip file.

Can just looking at what's in it - either using Windows' own .zip
handler that's built into explorer, or anything else - trigger any
malware? I'm not talking about _opening_ any of the files (running
executables, opening documents, even looking at pictures), just looking
at the folder and file names, and more particularly dates.

I'd assumed - because of the size - that it might take an age to scan it
with AV; in practice, AVG scanned it in a quite reasonable time, but I
thought I'd ask anyway, as I imagine the answer might be of widespread
interest.

I don't _think_ just _looking_ inside a .zip file should be capable of
_running_ anything. But I could be wrong.

Is it just a .zip data file, or a self-extracting .exe zip-formatted
file?

With PDF viewers, you have to disable their feature of supporting
automatic commands that can get ran when opening a .pdf file, along with
disabling support for scripts within PDF files. A PDF can also call to
open another file when you load the PDF. A PDF can attempt to
automatically open at attachment (yes, PDFs can have attachments, just
like e-mail) when you load the PDF file. Loading a PDF file can also
have it attempt to connect to a web site. For example, in PDFXchange
Editor, I have:

When document is trying to open a file:
Use Trusted/Untrusted List
(My Trusted/Untrusted List is empty.)

When a document is trying to open an attachment:
Allow PDF(s) and use Trusted/Untrusted List for other
(Opening another PDF as an attachment is okay, because the same settings
apply to it as for the originally loaded PDF file.)

When document is trying to open a site:
Use Trusted/Untrusted List

Javascript
Enable Javascript Actions = DISABLED

ZIP itself has none of this security stupidity. Not all PDF viewers
give you these security options, while some just don't support those PDF
"features". There are no automatic "features" in a .zip archive file.
It's just a file with database structure with records. You would have
to extract and run something inside the .zip file for anything to
happen. Any vulnerability to the ZIP format would be in whichever
viewer you use. For example, in the past, image files could be
malicious by using a vulnerability in the library code used to render
the image. Just viewing the image could run malware, but that depended
on which viewer you used to open the image file. The file isn't itself
malicious acting, but there could be a bug in the program that opens it.

I mentioned that I use PDFXchange Editor to view PDF files, but have it
neutered to kill off the superfluous and security vulnerable features.

https://www.cvedetails.com/cve/CVE-2018-16303/

That's the only one I found regarding a vulnerability with PDFXchange
Editor. The "XML External Entity injection" vulnerability was fixed in
half a month, plus I don't let the program do any external file access.

As for ZIP format, no, it doesn't have a malicious vulnerability, but
some viewers might. For example:

https://nakedsecurity.sophos.com/201...-need-to-know/

A list of affected zip libraries is at:

https://github.com/snyk/zip-slip-vulnerability

That's not the only vulnerability found with 7-Zip. See:

https://www.cvedetails.com/vulnerabi...220/7-zip.html

While Peazip uses a 7-ZIP library, that's to support the .7z archive
file format. Peazip has its own code and its own vulnerabilities (e.g.,
https://nvd.nist.gov/vuln/detail/CVE-2009-2261). Also remember that a
programmer codes based on the functionality they intend.
Vulnerabilities are often not due to bad code but in the programmer not
expecting some anomaly in the database or deliberate abuse. They start
by coding for intended function, like per a Functional Spec (how it
should work) and followed perhaps by an Engineering Spec (how it does
work), and then later have to harden their code against overt abuse.

Windows uses its own zipfldr.dll library with its own vulnerabilities;
https://www.google.com/search?q=zipfldr%20vulnerability.

I don't use zipfldr.dll bundled inside of Windows. I use 7-Zip. I had
used Peazip (which included libs from 7-Zip) until I had to report some
defects, one which was very nasty. The Peazip author fixed it within a
day, but I already switched back to 7-Zip despite its archaic GUI (and
why I might someday go back to Peazip). Was/Is 7-Zip free from
programming defects? Nope.

https://www.cisecurity.org/advisory/...tion_2018-049/

Again, the .zip format isn't the problem. Software has bugs or, in some
cases, means to abuse the code and those are in the viewer/extractors
that you use. Do a Google search on "yourZipHandler vulnerability" to
see how bad it has been, to which versions they apply (to check you have
a later version), and perhaps how to configure the ZIP handler to make
it safer (7-Zip doesn't have any security/safety settings).

Also remember that a vulnerability might not be within the program you
are using but the handler used to support something within that program.
For example, Peazip can display thumbnails of image files within a
compressed archive file. Well, if the image handler has bugs then those
might be vulnerable. Peazip isn't the one vulnerable, but the image
handler could be.

Mayayana,

Yes. I think it was a bug in early versions of
gdiplus.dll, if I remember correctly.

There was also the (IIRC) .WMF file format, which *by design* could carry
executable code to handle a drawing-failure abort. Getting the drawing to
fail was easy enough.

Regards,
Rudy Wieser

On 31/01/2020 02.28, Paul wrote:

....

Back when the original issues were discovered, it was a wakeup
call against lazy devs just plopping in code they hadn't even
opened and looked at. I think they have processes now, to ensure
the high school intern looks at the code first.

LOL :-D

--
Cheers, Carlos.