Monday, August 20, 2007

CVE-2007-4091 and the Lack of Actionable Info in Vulnerability Disclosures

I was going to blog on something more interesting tonight -- like Cormac McCarthy's Novel, The Road which I read in almost one sitting yesterday evening -- but I got distracted by the new rsync vulnerability disclosed last Wednesday which once again show how little useful information (from the point of view of an end user/administrator) shows up in the disclosures by either the vendors or the finders.

For example:
It still pays to have a look at open source projects.
rsync 2.6.9 contains two off by one stack overflows, one from which the target buffer is next to the
saved frame pointer.
The problematic function is f_name().
Obviously it expects a target buffer size
of MAXPATHLEN bytes. Otherwise
the size parameter calculation to
strlcpy() is wrong.
Lets have a look at f_name() calls within the two following pictures.
An offset is added to the fname buffer
which is of size MAXPATHLEN.
The offset is the stringlen of dir.root
plus one (due to the slash).
Within successfull_send(), the buffer
should be neighbor of the saved

And USN-500-1 is only slightly more useful:

Sebastian Krahmer discovered that rsync contained an off-by-one miscalculation when handling certain file paths. By creating a specially crafted tree of files and tricking an rsync server into processing them, a remote attacker could write a single NULL to stack memory, possibly leading to arbitrary code execution.
So this is only a server issue? In my state of exhaustion (had to work most of the weekend) I am more worried about attacks against the "client?" Like a more trusted centralized server pulling files from many more exposed (less trusted) server. So an attacker creaties a malicious path (greater than 1024) on a remote server (plus whatever else is needed...) to compromise the "rsync client" pulling from the servers? If I'm running rsync+ssh am I just as vulnerable? Is this only an rsyncd issue?

Of course most bug finders could give a shit about real access world issues that ultimately allow risk decisions to be made, and help folks that run systems must be upgraded immediately, which can wait? Or how does this vuln compare to others?
I'm not sure I buy the CVSS 6.8 in the NVD. The NVD entry says this is a pre-auth?

I think you get the point here. More questions than answers. Or do you just blindly update the .deb or RPM? So Ubuntu and Debian have updates out but doesn't look like this is in FreeBSD ports yet and nothing in CVS yet. And the rsync in OSX, can you say 2.6.3

Forget about it.

No comments: