Package: slocate
Version: 3.1-1
Severity: important
Tags: patch, security
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0227 says:
"slocate 3.1 does not properly manage database entries that specify names
of files in protected directories, which allows local users to obtain
the names of private files. NOTE: another researcher reports that the
issue is not present in slocate 2.7."
I've confirmed this; 2.7 (correctly) does not behave this way. Attached
is the patch I'm using in Ubuntu, which restores the deep access()
checks, as done in 2.7.
--
Kees Cook @outflux.net
--- slocate-3.1.orig/src/utils.c
+++ slocate-3.1/src/utils.c
@@ -524,6 +524,7 @@
{
struct stat path_stat;
int ret = 0;
+ char *path_copy = NULL;
char *ptr = NULL;
if (lstat(path, &path_stat) == -1)
@@ -532,15 +533,25 @@
if (!S_ISLNK(path_stat.st_mode)) {
if (access(path, F_OK) != 0)
goto EXIT;
- } else if ((ptr = rindex(path, '/'))) {
- *ptr = 0;
- if (access(path, F_OK) == 0)
- ret = 1;
- *ptr = '/';
- goto EXIT;
}
+ /* "path" is const, so we shouldn't modify it. Also, for speed,
+ * I suspect strdup/free is less expensive than the deep access
+ * checks... */
+ if (!(path_copy = strdup(path)))
+ goto EXIT;
+
ret = 1;
+
+ /* Each directory leading to the file (symlink or not) must be
+ * readable for us to allow it to be listed in search results. */
+ while (ret && (ptr=rindex(path_copy,'/'))) {
+ *ptr=0;
+ if (*path_copy && access(path_copy, R_OK) != 0)
+ ret = 0;
+ }
+ free(path_copy);
+
EXIT:
return ret;
}
