public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dan.j.rosenberg at gmail dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12625] New: mntent operations provide no indication of failure due to RLIMIT_FSIZE Date: Wed, 30 Mar 2011 19:19:00 -0000 [thread overview] Message-ID: <bug-12625-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=12625 Summary: mntent operations provide no indication of failure due to RLIMIT_FSIZE Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper.fsp@gmail.com ReportedBy: dan.j.rosenberg@gmail.com See thread on oss-security mailing list [1] for additional reference. This issue has been assigned CVE-2011-1089. Essentially every setuid mount helper, including util-linux mount, fails to handle a low RLIMIT_FSIZE. Since addmntent() uses fprintf() without a corresponding fflush(), it will return success even in the case when the actual write will fail due to the resource limit. And then endmntent() always returns 1, so that's no help. As a result, these helpers can be used to write corrupted entries into /etc/mtab. Rather than forcing every setuid mount helper to explicitly alter resource limits prior to calling addmntent(), etc., it would be better if addmntent() attempted to flush and return failure based on the success of the fflush(), as suggested by Tomas Hoger: if (fprintf (stream, "%s %s %s %s %d %d\n", ...) < 0) return 1; return (fflush(stream) == 0 ? 0 : 1); [1] http://www.openwall.com/lists/oss-security/2011/03/04/9 [2] http://www.openwall.com/lists/oss-security/2011/03/07/9 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next reply other threads:[~2011-03-30 19:19 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-03-30 19:19 dan.j.rosenberg at gmail dot com [this message] 2011-03-31 9:31 ` [Bug libc/12625] " thoger at redhat dot com 2011-03-31 9:31 ` thoger at redhat dot com 2011-04-01 12:33 ` ludwig.nussel at suse dot de 2011-04-18 1:05 ` drepper.fsp at gmail dot com 2011-04-18 13:46 ` thoger at redhat dot com 2011-04-19 13:20 ` pasky at suse dot cz 2011-05-12 3:40 ` drepper.fsp at gmail dot com 2011-05-12 10:15 ` thoger at redhat dot com 2011-05-12 20:10 ` drepper.fsp at gmail dot com 2014-06-13 10:57 ` fweimer at redhat dot com 2014-06-13 11:23 ` joseph at codesourcery dot com 2014-06-13 11:30 ` fweimer at redhat dot com 2014-06-13 11:39 ` [Bug libc/12625] mntent operations provide no indication of failure due to RLIMIT_FSIZE (CVE-2011-1089) fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-12625-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).