Package: slocate Severity: important Tags: security patch CAN-2005-2499 describes a security hole in slocate:
slocate before 2.7 does not properly process very long paths, which allows
local users to cause a denial of service (updatedb exit and incomplete slocate
database) via a certain crafted directory structure.
Note that the "before 2.7" is wrong. Also, very little information about
the actual problem is available, the only technical information I could
find was inside the updated source package for slocate that Red Hat released,
which has this patch:
--- slocate-2.7/main.c.long 2005-08-09 01:04:39.000000000 +0200
+++ slocate-2.7/main.c 2005-08-09 01:08:51.000000000 +0200
@@ -1078,8 +1078,12 @@
if (!file)
break;
-
- if (file->fts_info != FTS_DP && file->fts_info != FTS_NS) {
+
+ /* fts_read () from glibc fails with EOVERFLOW when fts_pathlen
+ would overflow the u_short file->fts_pathlen. */
+ if (file->fts_info == FTS_D && file->fts_pathlen > 32768)
+ fts_set(dir,file,FTS_SKIP);
+ else if (file->fts_info != FTS_DP && file->fts_info != FTS_NS) {
if ((EXCLUDE && !match_exclude(file->fts_path,"")) ||
!EXCLUDE)
frcode(fd,file->fts_path,"");
If I read this right this patch still allows hiding files deep in a
directory hierarchy where slocate will give up looking for them, which
could be construed as a security risk if root expects to be able to use
slocate to find all of a user's files. However, that is apparently
better than the existing failure mode if no size checking is done.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
--
see shy jo
signature.asc
Description: Digital signature
