[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

SubRPC vulnerability: is Debian libc6 affected?



Recently several glibc vulnerabilities have been published, and there is
only some disjoint information about their status for Debian here and
there. Maybe this bunch of issues is worth one combined DSA that will
explain what is fixed?

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0391

   Integer overflow in xdr_array function in RPC servers for operating
   systems that use libc, glibc, or other code based on SunRPC including
                          ^^^^^
   dietlibc, allows remote attackers to execute arbitrary code by
   passing a large number of arguments to xdr_array through RPC services
   such as rpc.cmsd and dmispd.

There are 3 DSAs (142, 143, 146) fixing this bug in other packages, but
I haven't found any statement from Debian Security Team or from glibc
maintainer, except following notice already mentioned on this list:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155529&repeatmerged=yes

   > calloc() contains an integer overflow which means that in some
   > cases, the allocated buffer is too small. See the following page
   > for details:
   > 
   > http://cert.uni-stuttgart.de/advisories/calloc.php
   <...>

   Currently, woody and potato fixed packages have been uploaded to
   security.d.o (same update as the xdr bug was fixed in). Sid(unstable)
   is coming soon.

Is "the xdr bug" the one mentioned in CAN-2002-0391? BTW calloc() bug
also went below radar, while to me it seems serious enough to be worth
mention.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0684

   Buffer overflow in DNS resolver functions that perform lookup of
   network names and addresses, as used in BIND 4.9.8 and ported to
   glibc 2.2.5 and earlier, allows remote malicious DNS servers to
   execute arbitrary code through a subroutine used by functions such as
   getnetbyname and getnetbyaddr.

It looks like it is fixed in glibc 2.2.5-8, but again, it never made
into official announcement.

-- 
Dmitry Borodaenko



Reply to: