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.


             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: link
Be 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).