CVE-2009-1255 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-1255): The process_stat function in (1) Memcached before 1.2.8 and (2) MemcacheDB 1.2.0 discloses (a) the contents of /proc/self/maps in response to a stats maps command and (b) memory-allocation statistics in response to a stats malloc command, which allows remote attackers to obtain sensitive information such as the locations of memory regions, and defeat ASLR protection, by sending a command to the daemon's TCP port.
Robin, can we go stable with 1.2.8?
CVE-2009-1494 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-1494): The process_stat function in Memcached 1.2.8 discloses memory-allocation statistics in response to a stats malloc command, which allows remote attackers to obtain potentially sensitive information by sending this command to the daemon's TCP port.
1.3.3-r1 should go to stable. Want the stablereq in this bug, or in a separate one? I'd rank this exploit as fairly low priority, as memcached is meant for use on internal networks only. It would be far more destructive for the attacker to simply flush the cache.
Usually we'd handle stabilization on this bug. It's easier to follow for us and arches.
pppc/ppc64: please see the blocking bug
memcached-1.3.3-r2 stabled on ppc
ppc64 done
rbu: all arches stable
GLSA decision. Upstream is not too clear about the fact that access to the memcached port should be restrcicted. On the other hand, I suspect if unprivileged users were able to retrieve cached object via that port, other data could be disclosed as well. Since the impact is the defeat of ASLR, but not an immediate compromise, I vote NO.
No, too. Closing.
