Olaf Kirch from Oracle found two issues in open-iscsi 1) iscsid provides a management interface using an AF_LOCAL socket. To prevent unauthorized users from messing with it, it checks for the client's uid by doing a getsockopt(SO_PEERCRED). Unfortunately, it performs this operation on the *listening* socket, rather than the newly accepted connection. This will always return a uid of 0, effectively allowing everyone to perform management operations on the iSCSI initiator. It currently appears as if the impact is limited to DoS, as there's no obvious way for an attacker to retrieve eg passwords, or gain privilege. There's a whole lot of code though, so maybe there's a buffer overflow lurking somewhere that can be exploited. However, at a minimum this allows an attacker to shoot down iscsid, or tear down individual iSCSI connections. CVE-2007-3099 2) iscsid uses a rather fanciful logging mechanism, where the main process logs to a shared memory area, from where a child process picks up the messages and feeds them to syslog. This is protected by a semaphore created with mode 0666. This allows anyone to up the semaphore. iscsid will block on the next attempt to log something, and hang indefinitely. CVE-2007-3100 Should be public later today, marking as embargoed for now.
Created attachment 156720 [details] cve-2007-3099 patch
Created attachment 156721 [details] cve-2007-3100 patch
now public, removing embargo
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2007-0497.html Fedora: https://admin.fedoraproject.org/updates/F7/FEDORA-2007-0543