Package: jhead Version: 2.84-2 Severity: normal Using the zzuf fuzzer, it is fairly easy to get jhead to crash with a segmentation fault. I guess this is due to lack of validation of various exif header fields.
Here's an example: (good file) http://www.noloop.net/bugs/jhead/001/hello.jpeg Corrupted with "zzuf -c -v -s 148 cat hello.jpeg > hello-s148.jpeg": (corrupt file) http://www.noloop.net/bugs/jhead/001/hello-s148.jpeg gdb trace (when running against a non-stripped binary compiled from the jhead source deb): jhead-2.84/jhead hello-s148.jpeg Nonfatal Error : 'hello-s148.jpeg' Suspicious offset of first IFD value Program received signal SIGSEGV, Segmentation fault. 0x0804cc30 in Get16u (Short=0x865e1c1) at exif.c:319 319 return (((uchar *)Short)[1] << 8) | ((uchar *)Short)[0]; #0 0x0804cc30 in Get16u (Short=0x865e1c1) at exif.c:319 No locals. #1 0x0804d0a3 in ProcessExifDir (DirStart=0x865e1c1 <Address 0x865e1c1 out of bounds>, OffsetBase=0x825e1b8 "II*", ExifLength=126, NestingLevel=0) at exif.c:464 de = 10 a = -1208602636 NumDirEntries = -1208601216 ThumbnailOffset = 0 ThumbnailSize = 0 IndentString = "\000", ' ' <repeats 24 times> #2 0x0804e539 in process_EXIF (ExifSection=0x825e1b0 "", length=134) at exif.c:996 FirstOffset = 4194313 ExifHeader = "Exif\000\000" #3 0x0804bdc3 in ReadJpegSections (infile=0x825e048, ReadMode=READ_METADATA) at jpgfile.c:235 marker = 225 ll = 134 lh = 0 Data = (uchar *) 0x825e1b0 "" itemlen = 134 got = 132 a = 1 HaveCom = 0 #4 0x0804c020 in ReadJpegFile (FileName=0xbfdbc927 "hello-s148.jpeg", ReadMode=READ_METADATA) at jpgfile.c:322 infile = (FILE *) 0x825e048 ret = 134516080 #5 0x08049f81 in ProcessFile (FileName=0xbfdbc927 "hello-s148.jpeg") at jhead.c:815 Modified = 0 ReadMode = READ_METADATA #6 0x0804b6ee in main (argc=2, argv=0xbfdbad44) at jhead.c:1618 argn = 1 arg = 0xbfdbc927 "hello-s148.jpeg" I guess in this particular case, the problem is on exif.c circa line 986, the "FirstOffset" value is taken at face value (although a warning is printed). Looks like the segfault is caused by an invalid pointer memory read, so I guess that's not exploitable(?), but I thought I'd report this anyway. There were also problems with the IPTC parser not validating its length fields; I forgot to keep an example around, but running zzuf on any .jpeg file with an IPTC section should reproduce the problem fairly easy. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.29.4 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=nb_NO.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages jhead depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libjpeg-progs 6b-14 Programs for manipulating JPEG fil jhead recommends no packages. jhead suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
