[SECURITY] Buffer overflow in libgtop2

I can't reproduce it on current feisty on AMD64:

$ export filename=$(perl -e " print 's'x1000;")
$ cp /bin/sleep $filename
cp: accessing `ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss': File name too long

The cp only succeeds if filename is at most 255 chars long but then g-s-m doesn't crash.

Some filesystems don't support more than 255 chars.
Use this way to reproduce:

$ export dir=$(perl -e " print 's/'x1000;")
$ mkdir -p $dir
$ cp /bin/sleep $dir
$ $dir/sleep 100 &
$ gnome-system-monitor

Thanks, I could reproduce it now.

Here is a part of the backstrace:
(gdb) bt
#0 0x00002ae5d6d34cab in raise () from /lib/libc.so.6
#1 0x00002ae5d6d36660 in abort () from /lib/libc.so.6
#2 0x00002ae5d6d6c67b in ?? () from /lib/libc.so.6
#3 0x00002ae5d6de86ef in __stack_chk_fail () from /lib/libc.so.6
#4 0x00002ae5d29997e6 in glibtop_get_proc_map_s ()
   from /usr/lib/libgtop-2.0.so.7

Here is the output for frame 4 with debug symbols:

(gdb) frame 4
#4 0x00002b24888ee7e6 in glibtop_get_proc_map_s (server=0x2b2488af38a0, buf=0x7fff23c825e0, pid=9755472)
    at procmap.c:229
229 }
(gdb) list
224 buf->number = entry_list->len;
225 buf->size = sizeof (glibtop_map_entry);
226 buf->total = buf->number * buf->size;
227
228 return (glibtop_map_entry*) g_array_free(entry_list, FALSE);
229 }

Here is an analysis of the problem:

The problematic code is in sysdeps/linux/procmap.c: glibtop_get_proc_map_s()

155 char line[1024];
[...]
164 char filename [GLIBTOP_MAP_FILENAME_LEN+1];
165
166 glibtop_map_entry *entry;
167
168 if (!fgets(line, sizeof line, maps))
169 break;
170
171 /* 8 arguments */
172 rv = sscanf(line, PROC_MAPS_FORMAT,
173 &start, &end, flags, &offset,
174 &dev_major, &dev_minor, &inode, filename);

GLIBTOP_MAP_FILENAME_LEN is 215 (include/glibtop/procmap.h)
PROC_MAPS_FORMAT is defined as "%16llx-%16llx %4c %16llx %02hx:%02hx %llu%*[ ]%[^\n]\n"

maps is /proc/<pid>/smaps and the first line looks in this case like
00400000-00404000 r-xp 00000000 08:07 1849138 /home/michael/tmp/s/s/s/s/s/s/s/s/s/s/s/s/s/s/s/s/s/s/s/[...]

After the sscanf 'filename' contains the filename which is much longer than the char array and overflows into the stack.

The gnome bugzilla has already a patch for it:
http://bugzilla.gnome.org/attachment.cgi?id=80254&action=view

Requires urgent fix in Dapper and Breezy. Not exploitable in Edgy and Feisty due to SSP, but I'll fix it in Feisty anyway.

 libgtop2 (2.14.5-0ubuntu2) feisty; urgency=low
 .
   * SECURITY UPDATE: Local arbitrary code execution.
   * Add debian/patches/00upstream-proc_map-overflow.patch:
     - Fix overflow in glibtop_get_proc_map_s() with very long /proc/maps
       entries (user triggerable by creating a process with a large cwd
       string).
     - Patch taken from upstream CVS.
     - Closes: LP#79206

Fixed stables in USN-407-1.