Package: clamav
Version: 0.87-1
Severity: important
Tags: security
I recently stumbled upon a (probably corrupted) DOC file, which caused
clamd (running with ArchiveMaxFiles 10000) to segfault, causing a DoS. After
specifying --max-files=100000 to clamscan, I could also get clamscan to
segfault.
Here is a backtrace I obtained:
#0 0xb7d993a7 in vfprintf () from /lib/tls/libc.so.6
#1 0xb7dbb4e1 in vsnprintf () from /lib/tls/libc.so.6
#2 0xb7e9e7ae in cli_dbgmsg (str=0xb7ee2090 "%34s ") at others.c:122
#3 0xb7ebb8f4 in print_property_name (pname=0xbf0238b0 "\001", size=18) at
ole2_extract.c:186
#4 0xb7ebb961 in print_ole2_property (property=0xbf0238b0) at
ole2_extract.c:197
#5 0xb7ebc87c in ole2_walk_property_tree (fd=3, hdr=0xbf8222fc, dir=0x87aa028
"/tmp/clamav-ad8ca4a99a5aca3d", prop_index=5,
handler=0xb7ebcc14 <handler_writefile>, rec_level=1, file_count=0xbf8222a0,
limits=0x87a1e58) at ole2_extract.c:509
#6 0xb7ebca1b in ole2_walk_property_tree (fd=3, hdr=0xbf8222fc, dir=0x87aa028
"/tmp/clamav-ad8ca4a99a5aca3d", prop_index=2,
handler=0xb7ebcc14 <handler_writefile>, rec_level=1, file_count=0xbf8222a0,
limits=0x87a1e58) at ole2_extract.c:536
#7 0xb7ebca4b in ole2_walk_property_tree (fd=3, hdr=0xbf8222fc, dir=0x87aa028
"/tmp/clamav-ad8ca4a99a5aca3d", prop_index=5,
handler=0xb7ebcc14 <handler_writefile>, rec_level=1, file_count=0xbf8222a0,
limits=0x87a1e58) at ole2_extract.c:538
#8 0xb7ebca1b in ole2_walk_property_tree (fd=3, hdr=0xbf8222fc, dir=0x87aa028
"/tmp/clamav-ad8ca4a99a5aca3d", prop_index=2,
handler=0xb7ebcc14 <handler_writefile>, rec_level=1, file_count=0xbf8222a0,
limits=0x87a1e58) at ole2_extract.c:536
#9 0xb7ebca4b in ole2_walk_property_tree (fd=3, hdr=0xbf8222fc, dir=0x87aa028
"/tmp/clamav-ad8ca4a99a5aca3d", prop_index=5,
handler=0xb7ebcc14 <handler_writefile>, rec_level=1, file_count=0xbf8222a0,
limits=0x87a1e58) at ole2_extract.c:538
#10 0xb7ebca1b in ole2_walk_property_tree (fd=3, hdr=0xbf8222fc, dir=0x87aa028
"/tmp/clamav-ad8ca4a99a5aca3d", prop_index=2,
handler=0xb7ebcc14 <handler_writefile>, rec_level=1, file_count=0xbf8222a0,
limits=0x87a1e58) at ole2_extract.c:536
[...]
#13791 0xb7ebca1b in ole2_walk_property_tree (fd=3, hdr=0xbf8222fc,
dir=0x87aa028 "/tmp/clamav-ad8ca4a99a5aca3d",
prop_index=3, handler=0xb7ebcc14 <handler_writefile>, rec_level=1,
file_count=0xbf8222a0, limits=0x87a1e58)
at ole2_extract.c:536
#13792 0xb7ebc9a1 in ole2_walk_property_tree (fd=3, hdr=0xbf8222fc,
dir=0x87aa028 "/tmp/clamav-ad8ca4a99a5aca3d",
prop_index=0, handler=0xb7ebcc14 <handler_writefile>, rec_level=0,
file_count=0xbf8222a0, limits=0x87a1e58)
at ole2_extract.c:523
#13793 0xb7ebd68c in cli_ole2_extract (fd=3, dirname=0x87aa028
"/tmp/clamav-ad8ca4a99a5aca3d", limits=0x87a1e58)
at ole2_extract.c:826
#13794 0xb7ea7419 in cli_scanole2 (desc=3, virname=0xbf8226bc,
scanned=0x80536fc, root=0x8054720, limits=0x87a1e58,
options=107, arec=1, mrec=0) at scanners.c:1142
#13795 0xb7ea802a in cli_magic_scandesc (desc=3, virname=0xbf8226bc,
scanned=0x80536fc, root=0x8054720, limits=0x87a1e58,
options=107, arec=1, mrec=0) at scanners.c:1454
#13796 0xb7ea8421 in cl_scandesc (desc=3, virname=0xbf8226bc,
scanned=0x80536fc, root=0x8054720, limits=0x87a1e58,
options=107) at scanners.c:1563
#13797 0x0804e6b4 in checkfile (filename=0x87aa018 "KOCH.DOC", root=0x8054720,
limits=0x87a1e58, options=107, printclean=1)
at manager.c:764
#13798 0x0804d77b in scanfile (filename=0x87aa018 "KOCH.DOC", root=0x8054720,
user=0x0, opt=0x8054008, limits=0x87a1e58,
options=107) at manager.c:436
---Type <return> to continue, or q <return> to quit---
#13799 0x0804cf5d in scanmanager (opt=0x8054008) at manager.c:263
#13800 0x0804b40b in clamscan (opt=0x8054008) at clamscan.c:159
#13801 0x0804bcf6 in main (argc=4, argv=0xbf822dd4) at options.c:177
I ran it under gdb, and apparently the problem is that the doc file's property
tree is not actually a tree:
Index Property Prev Next Child
------------------------------------------
0 RootEntry -1 -1 3
3 SummaryInformation 2 4 -1
2 WordDocument 5 -1 -1
5 CompObj 0 2 1083217721
This makes ole2_walk_property_tree bounce between properties 2 5 and 0, until
either MaxFiles limit is reached, or (apparently) stack is overflowed.
I do not yet have the authorization to forward the doc file in question to you,
but I guess any file with such property graph will do.
This segfault occured after 13k+ calls, but the clamd on which I discovered the
problem segfaulted with only about 3500+ calls (I have a strace, but it
contains data I am not authorized to forward). I think the difference can be
explained by different system (sid vs sarge), kernel version and program (clamd
vs clamscan).
I guess the problem can be solved in several ways:
- changing ole2_walk_property_tree to an iterative implementation
- keeping a cache of already visited nodes and short-circuiting on second visit
Either way, a warning should be put in the documentation on any recursive
unpacking algorithm in clamav, so one can choose a saner maxfiles limit.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Versions of packages clamav depends on:
ii clamav-freshclam [clamav-data 0.87-1 downloads clamav virus databases f
ii libc6 2.3.5-6 GNU C Library: Shared libraries an
ii libclamav1 0.87-1 virus scanner library
ii zlib1g 1:1.2.3-4 compression library - runtime
Versions of packages clamav recommends:
pn arj <none> (no description available)
pn unzoo <none> (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
