Summary: | <app-admin/syslog-ng-2.1.3 no chdir() before chroot() (CVE-2008-5110) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | stupendoussteve |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mr_bones_ |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505791 | ||
Whiteboard: | B4 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
stupendoussteve
2008-11-17 22:04:14 UTC
Seems this bug has been overlooked for some time. I just investigated this issue. Here are my results: Debian's patch suggests using chdir(chroot_dir) and then chroot(chroot_dir). The thread on openwall linked in comment #0, however, raises some concerns about race conditions and suggests using either chdir(chroot_dir) and then chroot("."), or chroot(chroot_dir) first and then chdir("/"). Upstream used the latter approach and also solved all the other concerns raised in the openwall thread. This leads us to the fixed versions: 2.0.* until 2.0.9 is vulnerable, 2.0.10 is fixed. 2.1.* until 2.1.2 is vulnerable, 2.1.3 is fixed. 2.1.3 is already stable on all arches, so no stabilization needs to be done here. Since the issue at hand is only exploitable with another separate vulnerability, I don't think a GLSA is necessary. In fact, I wasn't even able to find a detailed (upstream) advisory about this. not a vulnerability in itself, but this is a high profile daemon and bringing visibility to this kind of vulnerability is a good thing. GLSA 200907-10 |