This info comes from Josh Bressers at redhat. ---------------------------------------------- This one was found by Arjan van de Ven. struct dqblk { u_int32_t dqb_bhardlimit; /* absolute limit on disk blks alloc */ u_int32_t dqb_bsoftlimit; /* preferred limit on disk blks */ u_int32_t dqb_curblocks; /* current block count */ u_int32_t dqb_ihardlimit; /* maximum # allocated inodes */ u_int32_t dqb_isoftlimit; /* preferred inode limit */ u_int32_t dqb_curinodes; /* current # allocated inodes */ time_t dqb_btime; /* time limit for excessive disk use */ time_t dqb_itime; /* time limit for excessive files */ }; struct rquota { int rq_bsize; bool_t rq_active; u_int rq_bhardlimit; u_int rq_bsoftlimit; u_int rq_curblocks; u_int rq_fhardlimit; u_int rq_fsoftlimit; u_int rq_curfiles; u_int rq_btimeleft; u_int rq_ftimeleft; }; rquota_server.c line 171 has the following memcpy: memcpy((caddr_t *)&result.getquota_rslt_u.gqr_rquota.rq_bhardlimit, (caddr_t *)&dq_dqb, sizeof(struct dqblk)); the goal of the memcpy is to copy the 8 fields from struct dqblk to the last 8 fields of the struct quota. That is, 6 ints and 2 time_t's get copied to 8 ints. On 32 bit machines, that's ok (but ugly) since a time_t is also a 32 bit value; on 64 bit machines time_t is 64 bit though, thus buffer overflowing the stack. This information should be assumed to be public. This issue has been assigned the CVE id CAN-2004-0946. -- JB
I've put a patched -r5 into portage after talking with rphillips. He will do the initial testing then unmask for ~arch before calling for arch maintainers to test. These are the keywords right now. nfs-utils-1.0.6-r4.ebuild: KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sparc x86" nfs-utils-1.0.6-r5.ebuild: KEYWORDS="-*"
These two keyword entries exist in the ebuild atm and this has been sitting in cvs for a week now. KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sparc ~x86" KEYWORDS="-*" rphillips, is this ready for arches to test and mark stable yet?
Yes, looks good here. -r
archs, please mark nfs-utils-1.0.6-r5 stable.
Only 64-bit arches are affected... don't forget to enumerate arches on that GLSA
stable on amd64, allthough the 2nd "-*" keyword masks it
stable on ppc64. There are two KEYWORDS lines. The KEYWORDS="-*" line should be removed? Markus
Marked stable on mips, will take effect once the second KEYWORDS line is removed.
Please the next arch to mark anything please remove the KEYWORDS=-* so it can atleast hit ~arches
hppa/ia64/s390 stable
Stable on alpha.
Stable on sparc and removed the KEYWORDS="-*" line.
back to ebuild status... Ubuntu has reported another vulnerability in USN 36-1 a remote DoS vulnerability seems to exist in utils/statd/statd.c (a patch has reportedly been supplied by SGI) http://cvs.sourceforge.net/viewcvs.py/nfs/nfs-utils/utils/statd/statd.c?r1=1.17&r2=1.18 The Ubuntu changelog reads: + * SECURITY UPDATE: fix remote Denial of Service, fix buffer overflow on 64 + bit architectures + * utils/statd/statd.c (patch from SGI): + - main(): ignore SIGPIPE to continue to run even if a peer prematurely + closes his TCP connection + - drop_privs(): fix uninitialized st.st_gid value when running as root + (not exploitable, but using random group ids might be confusing) + - CAN-2004-1014 + * utils/rquotad/rquota_server.c (Arjan van de Ven): + - getquotainfo(): do not use memcpy() to copy + values from struct dqblk to struct rquota; on 64 bit architectures time_t + is 64 bits wide, but the target fields are only 32 bit, thus causing a + buffer overflow + - CAN-2004-0946 + - NOTE: rpc.quotad is not shipped in the debs by default (this is + contained in the package "quota" which is not affected by this) + + -- Martin Pitt <martin.pitt@canonical.com> Wed, 1 Dec 2004 14:34:34 +0100 All their patches can be found at http://security.ubuntu.com/ubuntu/pool/main/n/nfs-utils/nfs-utils_1.0.6-3ubuntu1.1.diff.gz net-fs, pls provide an updated ebuild with all necessary patches applied
I've commited -r6 to the nfs-utils directory... Arches please test and unmask.
arches, please mark -r6 stable.
sparc tasty.
x86 stable
amd64 done
-r6 stable on alpha.
Stable on mips.
will take a while because: SeJo@powke nfs-utils $ emerge nfs-utils -p These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] net-nds/portmap-5b-r8 [ebuild N ] net-fs/nfs-utils-1.0.6-r6 real 0m4.387s user 0m1.673s sys 0m0.390s SeJo@powke nfs-utils $ emerge nfs-utils Calculating dependencies ...done! >>> emerge (1 of 2) net-nds/portmap-5b-r8 to / >>> md5 src_uri ;-) portmap_5beta.tar.gz >>> Unpacking source... >>> Unpacking portmap_5beta.tar.gz to /var/tmp/portage/portmap-5b-r8/work * Applying portmap_5beta.dif ... [ ok ] * Applying portmap-4.0-malloc.patch ... [ ok ] * Applying portmap-4.0-cleanup.patch ... [ ok ] * Applying portmap-4.0-rpc_user.patch ... [ ok ] * Applying portmap-4.0-sigpipe.patch ... [ ok ] * Applying portmap-5b-include-errno_h.patch ... [ ok ] >>> Source unpacked. gcc -Dperror=xperror -DHOSTS_ACCESS -DCHECK_PORT -DFACILITY=LOG_AUTH -DIGNORE _SIGCHLD -Wall -O2 -pipe -mcpu=7400 -maltivec -mabi=altivec -pipe -c -o po rtmap.o portmap.c portmap.c:41: warning: 'sccsid' defined but not used gcc -Dperror=xperror -DHOSTS_ACCESS -DCHECK_PORT -DFACILITY=LOG_AUTH -DIGNORE _SIGCHLD -Wall -O2 -pipe -mcpu=7400 -maltivec -mabi=altivec -pipe -c -o pm ap_check.o pmap_check.c pmap_check.c:36: warning: 'sccsid' defined but not used gcc -Dperror=xperror -DHOSTS_ACCESS -DCHECK_PORT -DFACILITY=LOG_AUTH -DIGNORE _SIGCHLD -Wall -O2 -pipe -mcpu=7400 -maltivec -mabi=altivec -pipe -c -o fr om_local.o from_local.c from_local.c:39: warning: 'sccsid' defined but not used make: *** No rule to make target `//usr/lib/libwrap.a', needed by `portmap'. St op. !!! ERROR: net-nds/portmap-5b-r8 failed. !!! Function src_compile, Line 58, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. real 0m9.771s user 0m6.365s sys 0m3.055s
sejo: i dont know why you posted an unrelated portmap bug to a nfs-utils bug ... search bugzilla and you'll find the easy answer to that failure :P
Stable on hppa.
ppc, ppc64 : we need you for that GLSA to go out :)
Marked ppc stable.
finaly stable on ppc64 sorry that this took soooo long.. HD gave up and stage1 on new HD didn't like me :-/
arm/ia64/s390 stable
lewk, please send that GLSA, it's ready now... We'll send it tomorrow if you don't show up.
GLSA 200412-08
