Bug 172669 - CVE-2005-4268 cpio large filesize buffer overflow
Summary: CVE-2005-4268 cpio large filesize buffer overflow
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: cpio   
(Show other bugs)
Version: fc3
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Fedora Legacy Bugs
QA Contact:
Whiteboard: impact=low, LEGACY, 3, 4, NEEDSWORK
Keywords: Reopened, Security
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-08 01:13 UTC by Richard Harms
Modified: 2007-04-18 17:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-30 12:10:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fix from upstream (18.10 KB, patch)
2005-11-15 13:49 UTC, Peter Vrabec
no flags Details | Diff
patch fixing buffer overflow on 64bit systems for cpio-2.5 (1.15 KB, application/octet-stream)
2007-02-27 13:55 UTC, Lukas Vrabel
no flags Details

Description Richard Harms 2005-11-08 01:13:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
The latest update to cpio is being killed after a buffer overflow is detected.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
cpio is given a large hierarchy of files and started using "cpio -o --format=crc"

Actual Results:  *** buffer overflow detected ***: cpio terminated
======= Backtrace: =========
======= Memory map: ========
00400000-00418000 r-xp 00000000 fd:00 50430007                           /bin/cpio
00517000-0051a000 rw-p 00017000 fd:00 50430007                           /bin/cpio
0051a000-0053b000 rw-p 0051a000 00:00 0                                  [heap]
3a2e300000-3a2e31a000 r-xp 00000000 fd:00 50003970                       /lib64/ld-2.3.5.so
3a2e419000-3a2e41a000 r--p 00019000 fd:00 50003970                       /lib64/ld-2.3.5.so
3a2e41a000-3a2e41b000 rw-p 0001a000 fd:00 50003970                       /lib64/ld-2.3.5.so
3a2e500000-3a2e62d000 r-xp 00000000 fd:00 50003993                       /lib64/libc-2.3.5.so
3a2e62d000-3a2e72c000 ---p 0012d000 fd:00 50003993                       /lib64/libc-2.3.5.so
3a2e72c000-3a2e730000 r--p 0012c000 fd:00 50003993                       /lib64/libc-2.3.5.so
3a2e730000-3a2e732000 rw-p 00130000 fd:00 50003993                       /lib64/libc-2.3.5.so
3a2e732000-3a2e736000 rw-p 3a2e732000 00:00 0
3a30800000-3a3080d000 r-xp 00000000 fd:00 50004027                       /lib64/libgcc_s-4.0.1-20050727.so.1
3a3080d000-3a3090c000 ---p 0000d000 fd:00 50004027                       /lib64/libgcc_s-4.0.1-20050727.so.1
3a3090c000-3a3090d000 rw-p 0000c000 fd:00 50004027                       /lib64/libgcc_s-4.0.1-20050727.so.1
3a35c00000-3a35c14000 r-xp 00000000 fd:00 50004098                       /lib64/libnsl-2.3.5.so
3a35c14000-3a35d13000 ---p 00014000 fd:00 50004098                       /lib64/libnsl-2.3.5.so
3a35d13000-3a35d14000 r--p 00013000 fd:00 50004098                       /lib64/libnsl-2.3.5.so
3a35d14000-3a35d15000 rw-p 00014000 fd:00 50004098                       /lib64/libnsl-2.3.5.so
3a35d15000-3a35d17000 rw-p 3a35d15000 00:00 0
2aaaaaaab000-2aaaaaaad000 rw-p 2aaaaaaab000 00:00 0
2aaaaaacb000-2aaaaaace000 rw-p 2aaaaaacb000 00:00 0
7fffff9c0000-7fffff9d6000 rw-p 7fffff9c0000 00:00 0                      [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]

Additional info:

Comment 1 Peter Vrabec 2005-11-08 13:52:05 UTC
I can't reproduce it. I created 7.9G archive successfully.

Comment 2 Arjan van de Ven 2005-11-08 14:26:35 UTC
can you reproduce this with the debuginfo rpm installed?

Comment 3 Richard Harms 2005-11-09 04:10:38 UTC
Installed the debuginfo rpm, and ran it under gdb. Here's the results:

Program received signal SIGABRT, Aborted.
0x0000003a2e52f280 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003a2e52f280 in raise () from /lib64/libc.so.6
#1  0x0000003a2e530750 in abort () from /lib64/libc.so.6
#2  0x0000003a2e564a7f in __libc_message () from /lib64/libc.so.6
#3  0x0000003a2e5dcb6f in __chk_fail () from /lib64/libc.so.6
#4  0x0000003a2e5dc149 in _IO_str_chk_overflow () from /lib64/libc.so.6
#5  0x0000003a2e567b26 in _IO_default_xsputn_internal () from /lib64/libc.so.6
#6  0x0000003a2e55d532 in _IO_padn_internal () from /lib64/libc.so.6
#7  0x0000003a2e541bca in vfprintf () from /lib64/libc.so.6
#8  0x0000003a2e5dc1f9 in __vsprintf_chk () from /lib64/libc.so.6
#9  0x0000003a2e5dc130 in __sprintf_chk () from /lib64/libc.so.6
#10 0x000000000040534f in write_out_header (file_hdr=0x7fffffb189e0, out_des=1)
at copyout.c:307
#11 0x0000000000405ab9 in process_copy_out () at copyout.c:646
#12 0x0000000000407e3f in main (argc=3, argv=0x7fffffb18bc8) at main.c:765
#13 0x0000003a2e51c3cf in __libc_start_main () from /lib64/libc.so.6
#14 0x0000000000402729 in _start ()
#15 0x00007fffffb18bb8 in ?? ()
#16 0x0000000000000000 in ?? ()

Comment 4 Peter Vrabec 2005-11-09 09:44:35 UTC
Does it work with cpio < 2.6-8.FC4

Comment 5 Richard Harms 2005-11-09 15:52:07 UTC
Tested it with cpio-2.6-7.x86_64.rpm, from the FC4 installation disc, and it
aborts as well.

======= Backtrace: =========

Comment 6 Richard Harms 2005-11-09 19:16:00 UTC
I found the file causing the problem:

[root@dr1 ~]# ls -la /var/log/lastlog
-rw-r--r--  1 root root 1254130450140 Nov  9 11:23 /var/log/lastlog

It looks like the file's size was corrupted at some point. Telling cpio to
backup just this one file is enough to kill it immediately.

Comment 7 Arjan van de Ven 2005-11-10 14:03:12 UTC
      char ascii_header[112];
      sprintf (ascii_header,
               file_hdr->c_ino, file_hdr->c_mode, file_hdr->c_uid,
               file_hdr->c_gid, file_hdr->c_nlink, file_hdr->c_mtime,
             file_hdr->c_filesize, file_hdr->c_dev_maj, file_hdr->c_dev_min,
           file_hdr->c_rdev_maj, file_hdr->c_rdev_min, file_hdr->c_namesize,


cpio assumes the filesize is at most 8 digits in size... and that's not right.
If it's more, this buffer will indeed overflow....

this probably wants to use asprintf() or so

Comment 8 Josh Bressers 2005-11-10 18:07:35 UTC
This issue should also affect FC3.

Please note that this is only a security issue on 64 bit platforms.

Comment 9 Peter Vrabec 2005-11-15 13:49:55 UTC
Created attachment 121061 [details]
fix from upstream

(write_out_header): Rewritten using separate
functions for each file format. Use to_ascii to convert numbers to
ascii representation. Check for overflows and report them if
appropriate. Return 0 if it is OK to proceed with archiving this
file, 1 otherwise. All callers updated.

Comment 10 Peter Vrabec 2005-11-24 12:41:51 UTC

Comment 11 Matthew Miller 2006-10-19 19:44:42 UTC
It's unclear to me if this was ever fixed in RHEL4. It definitely wasn't in FC3.

I don't think security issues should be resolved as CLOSED:RAWHIDE.

Comment 12 Lukas Vrabel 2007-02-27 13:55:29 UTC
Created attachment 148862 [details]
patch fixing buffer overflow on 64bit systems for cpio-2.5

Comment 13 David Eisenstein 2007-03-03 03:42:25 UTC
I'm confused.  For what distribution is this patch in comment #12 to be
applied?  FC3 is no longer supported.

Should this bug be "CLOSED WONTFIX"?  Or reassigned to another product?

Comment 14 Lukas Vrabel 2007-03-21 15:28:20 UTC
this patch can be applied on cpio-2.5 in FC-3

Comment 15 Lukas Vrabel 2007-03-30 12:10:15 UTC
FC3 is not longer supported, bug is resolved in FC5 and FC6

Note You need to log in before you can comment on or make changes to this bug.