Bug 138063
| Summary: | CAN-2004-0946 buffer overflow in rquotad | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 2.1 | Reporter: | Brian Stein <bstein> |
| Component: | nfs-utils | Assignee: | Brian Stein <bstein> |
| Status: | CLOSED ERRATA | QA Contact: | Ben Levenson <benl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2.1 | CC: | bstevens |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | embargo=20041117:14,impact=moderate | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-01-12 18:48:07 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Found by Arjan; suggested embaro on advisories Nov17 1400UTC My analysis of this issue says it may be able for a remote NFS user to exploit this, but it won't be easy. In order to exploit this issue, the attacker has to control the time they poll rquotad to a very precise interval, which could lead to a 16 byte overflow on a 64 bit system. The ability execute anything of value in those 16 bytes is questionable, since ideally the attacker doesn't have unrestricted access to the server. In theory the attacker will be able to control 64 total bytes of data. This issue also affects RHEL2.1 This should be fixed in nfs-utils-0.3.3-10.src.rpm Removing security sensitive tag An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-014.html |
Description of problem: 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.