| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
From: steve_scholz at sybari.com (Steve Scholz)
Subject: Re: Multiple AV Vendor Incorrect
CRC32BypassVulnerability.
" Nor, anything else in the archive was modified!"
You changed the bit that determines if the zip is encrypted!
In Local file header if you modify "general purpose
bit flag" 7th & 8'th byte of a zip archive with \x2f
You changed bit 0 by making the above changes.
general purpose bit flag: (2 bytes)
Bit 0: If set, indicates that the file is encrypted.
(For Method 6 - Imploding)
Bit 1: If the compression method used was type 6,
Imploding, then this bit, if set, indicates
an 8K sliding dictionary was used. If clear,
then a 4K sliding dictionary was used.
Bit 2: If the compression method used was type 6,
Imploding, then this bit, if set, indicates
3 Shannon-Fano trees were used to encode the
sliding dictionary output. If clear, then 2
Shannon-Fano trees were used.
(For Methods 8 and 9 - Deflating)
Bit 2 Bit 1
0 0 Normal (-en) compression option was used.
0 1 Maximum (-exx/-ex) compression option was used.
1 0 Fast (-ef) compression option was used.
1 1 Super Fast (-es) compression option was used.
Note: Bits 1 and 2 are undefined if the compression
method is any other.
Bit 3: If this bit is set, the fields crc-32, compressed
size and uncompressed size are set to zero in the
local header. The correct values are put in the
data descriptor immediately following the compressed
data. (Note: PKZIP version 2.04g for DOS only
recognizes this bit for method 8 compression, newer
versions of PKZIP recognize this bit for any
compression method.)
Bit 4: Reserved for use with method 8, for enhanced
deflating.
Bit 5: If this bit is set, this indicates that the file is
compressed patched data. (Note: Requires PKZIP
version 2.70 or greater)
Bit 6: Strong encryption. If this bit is set, you should
set the version needed to extract value to at least
50 and you must also set bit 0. If AES encryption
is used, the version needed to extract value must
be at least 51.
Bit 7: Currently unused.
Bit 8: Currently unused.
Bit 9: Currently unused.
Bit 10: Currently unused.
Bit 11: Currently unused.
Bit 12: Reserved by PKWARE for enhanced compression.
Bit 13: Used when encrypting the Central Directory to indicate
selected data values in the Local Header are masked to
hide their actual values. See the section describing
the Strong Encryption Specification for details.
Bit 14: Reserved by PKWARE.
Bit 15: Reserved by PKWARE.
By doing this you did flip the bit that determines if a pkzip type file
is considered encrypted. While the file itself might not be you made the
program think that it is.
I believe this counts as changing something in the archive please
correct me if I am wrong. And since all encrypted files can contain
viruses with a password in the email it would be a very good idea to
delete encrypted zip files from emails.
As I have already stated Antigen by default has the ability to do such a
thing. Also even if the archive is not encrypted and the header info has
been changed to trick the decompression utility to believe it is then it
should be deleted.
While it might be a vulnerability if the file is extracted which it has
to be to be executed the desktop scanner will detect it at that time.
Multiple layers of defense is your best option
As far as number 3 Antigen detects Eicar.
Antigen for SMTP found long_coment.zip->eicar.com.txt infected with the
EICAR test string virus.
The file is currently Removed. The message, "test", was
sent from Steve Test and was discovered in SMTP Messages\Internal
located at Sybari Software/SYB-NY-ASD.
Number 1.
Well you had both the crc change and the change to the general purpose
bit flag combined. Once I changed this back to 00 00 as a normal non
encrypted archive would be while leaving your crc change in place
Antigen detected it with no problem.
Antigen for SMTP found crc.zip->eicar.com infected with
EICAR_Test_file_not_a_virus virus.
The file is currently Removed. The message, "test", was sent from Steve
Test and was discovered in SMTP Messages\Internal located at Sybari
Software/SYB-NY-ASD. I have included my version of your crc.zip the
password is crc please let me know if this is what you intended for the
file to do. Also feel free to contact me or give me a phone number I can
contact you by so I can see if there is anything else that you do not
think Antigen is doing correctly.
Steve Scholz
Corporate Sales Engineer-North America
Sybari Software, Inc.
631-630-8556 Direct
516-903-2464 Mobile
Email: Steve_scholz@...ari.com
MSN IM:Steve_Scholz@....com (email never checked)
-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of bipin
gautam
Sent: Friday, March 11, 2005 9:33 PM
To: full-disclosure@...ts.grok.org.uk; vuldb@...urityfocus.com
Cc: vuln@...unia.com
Subject: RE: [Full-disclosure] Re: Multiple AV Vendor Incorrect
CRC32BypassVulnerability.
1'st issue: Could anyone verify the existance of both
vulnebrility in *Symantec products* cauz it seems like
symantec engineers got the *old* broken file that i
reported lately and couldn't reproduce the thing. I
tried reporting the issue but the message had a broken
eicarta string so i think the message wasn't deliverd!
I uploaded a wrong file before and the same old file
kept on comming from the servers cache. I was able to
transperently extract the broken CRC archive using
Download accelerator Plus(5.3) with just a warning
message.
2'nd issue: NOP, the zip file wasn't "ACTUALLY"
encrypted. Nor, anything else in the archive was
modified! The archive can be normally be extracted by
any unzip utility. I did tested it with winrar 3.2 &
with default zip manager of winxp (sp2).
3'rd issue(NEW): Well, tested with F-prot, DrWeb,
*Symantec 8.0 long ago... lately verified it using
virustotal.com If you have a long archive coment... in
a zip archive these AV can't detect virus embedded in
it. though a frend of mine reported me symantec 8.1 is
immune to the bug.
POC:
http://www.geocities.com/visitbipin/long_coment.zip
--- Randall M <randallm@...mail.com> wrote:
> I scanned the file with McAfee 8.0i and it end up
> stating that it couldn't
> scan the EICAR.COM file because it was encrypted.
> Was this your
> Intention?
>
> ------------------------------
--- Steve Scholz <steve_scholz@...ari.com> wrote:
> You are correct by doing this you are marking the
> zip file as encrypted.
>
> Your option at this time is to turn on the feature
> delete encrypted
> compressed files.
>
> Steve Scholz
> Corporate Sales Engineer-North America
> Sybari Software, Inc.
> 631-630-8556 Direct
> 516-903-2464 Mobile
>
> Email: Steve_scholz@...ari.com
>
> -----Original Message-----
> From: full-disclosure-bounces@...ts.grok.org.uk
> Subject: [Full-disclosure] Re: Multiple AV Vendor
> Incorrect CRC32
> BypassVulnerability.
>
> In Local file header if you modify "general purpose
> bit flag" 7th & 8'th byte of a zip archive with \x2f
> ie: "\" F-port, Kaspersky, Mcafee, Norman, Sybari,
> Symantec seem to skip the file marking it as
> clean!!!
> This was discoverd during the analysis of "Multiple
> AV
> Vendor Incorrect CRC32 Bypass Vulnerability."
>
> Quick/rough conclusion were drawn using
> www.virustotal.com
>
> poc: http://www.geocities.com/visitbipin/gpbf.zip
>
> regards,
> bipin gautam
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://www.secunia.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crc changed.zip
Type: application/x-zip-compressed
Size: 338 bytes
Desc: crc changed.zip
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050311/21140547/crcchanged.bin
Powered by blists - more mailing lists