[Esd-l] How to mangle contents of a .zip file?

[Brian Hampton]

I appreciate your response.  My comments are below:

John D. Hardin wrote:

> On Tue, 9 Mar 2004, Brian Hampton wrote:
> 
> 
>>I recently set up .141 so that I could deal with all of the
>>Beagle/Bagle .zip viruses shooting around.  But we do send quite a
>>lot of legitimate executables within .zip files.
> 
> 
> Internally, or with external partners/consultants/etc.?

Probably about 65% internal, 35% external partners.  I am
trying to push our engineers to use email for this less and
less, but while we can post files to ftp or http sites, it is
not convenient for our engineers to use this method (due
to internal procedures).  Most of the executables are quite
small, anyways.

> 
> 
>>I misunderstood the new .zip file features, thinking it would simply
>>mangle the name within the .zip file according to the same
>>MANGLE_EXTENSIONS directive that straight attatchments are subject
>>to.
> 
> 
> Nope. The sanitizer is a single-pass streaming scanner, so it doesn't
> have the ability to go back and alter the contents of attachments.
> 
bummer. ;)

> 
>>Am I correct in my conclusion that the .141 version does not
>>allow me to mangle filenames within .zip files?
> 
> 
> You are correct.
> 
> 
>>I have only been able to poison them thus far.  If so, is this
>>something you would consider in the future?
> 
> 
> Probably not. That's somewhat more intrusive and less reliable than I
> want to make it, not to mention much more resource-intensive. For
> instance, you probably wouldn't be able to enforce such a policy on
> password-protected ZIP files.
> 

I would never push for it to be default behavior, mainly due to
the resource issues.  And I understand that it's a bit more
intrusive than you'd prefer.  I don't think stripping files from
an archive would be a good idea for instance, that could be really
confusing to an end user, no matter what kind of explanation you
included.

If you did include it as an option, I think it might look something
like this.

- an option to poison password protected zip files outright,
   and the ability to explain why in a bounce message.  (enabled
   by default?)
- an option to apply mangle rules to files in the first layer
   of open archives (disabled by default)
- to address performance issues, do not apply mangle rules to
   zip files over a specified file size, thus the admin can find
   the point at which his machine suffers from the load

However, I have not looked into the technical feasability of this
sort of thing- a quick glance at the unzip package leads me to
believe this will require more than a procmail script.

> 
>>I would prefer to not treat an executable differently depending
>>on if it's in a .zip file.  We don't poison much here, we simply
>>defang (because we send so many legit executables around).
> 
> 
> If your policy is that internal users are permitted to send other
> internal users zipped executables, then you need to configure a policy
> for that:
> 
> 1) develop a procmail rule that will identify internal
> source-and-destination messages (ideally based on the IP addresses in
> the Received: headers), and then
> 
> 2) use that rule to select the appropriate policy files, for example,
> not considering zipped .EXE files bad for internal emails
> ($ZIPPED_EXECUTABLES points at a filespec list that does not have
> "*.exe" in it). (You might also want to permit UNzipped executables in
> internal email as well...)
> 
> The sanitizer is configured via environment variables and simple files
> so that you can use the capabilities of procmail for the bulk of
> configuring different policies.
> 

Yeah, I began writing such policies in procmail and then realized
that it was going to be difficult to maintain the list of valid
people/domains that would be allowed to exchange zipped executables.
I figured before I get myself backed into a unmaintainable situation
I'd look for another solution.  I'll probably just have to mangle
.zip files themselves instead.

The reason this whole issue came up is because the sanitizer has
worked so well that people aren't used to getting any kind of dangerous
attachment (excellent work, btw!).  But the latest batch of .zip
viruses that look like they come from me (the admin) fooled a couple
folks.  Busted up my 2 year streak simply using the sanitizer and
educating folks relentlessly.

I may have to put in something like ClamAV in addition to the sanitizer.

brian
> --
>  John Hardin KA7OHZ    ICQ#15735746    http://www.impsec.org/~jhardin/
>  jhardin at impsec.org    FALaholic #11174    pgpk -a jhardin at impsec.org
>  key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
> -----------------------------------------------------------------------
>   "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
>   does quite what I want. I wish Christopher Robin was here."
> 				-- Peter da Silva in a.s.r
> -----------------------------------------------------------------------
>    25 days until the Slovakian Presidential Election