Loading ...
Sorry, an error occurred while loading the content.
 

Re: virtual permissions and virtual_gid_maps problems

Expand Messages
  • Jeroen Geilman
    ... I downloaded the 1.3.3c source and confirmed. Passed it on to the ProFTPd authors and they re looking into it. I will also provide them with the below diff
    Message 1 of 19 , Dec 1, 2010
      On 12/01/2010 02:30 PM, Dan wrote:
      >
      > Thanks for your input, as far as proftpd goes:
      >
      > The distribution file available at the main distribution site and all
      > mirrors has been compromised.
      > The new file contains a rootkit.
      >

      I downloaded the 1.3.3c source and confirmed.
      Passed it on to the ProFTPd authors and they're looking into it.
      I will also provide them with the below diff if you don't mind.

      How did you catch this ?
      Is it a FreeBSD checker of some sort, or do you habitually peruse the
      entire source of new programs :)

      I have used Proftpd many years without it being the victim of such
      abuse, though :)

      > Original file:
      > Name: proftpd-1.3.3c.tar.bz2
      > Size: 4166609
      > MD5: 8571bd78874b557e98480ed48e2df1d2
      > SHA256: ea7f02e21f81e6ce79ebde8bbbd334bd269a039ac9137196a35309f791b24db1
      >
      > Compromised file:
      > Name: proftpd-1.3.3c.tar.bz2
      > Size: 4203030
      > MD5: a43df54cc0b16c9e63a1045129d7b144
      > SHA256: d56d6d643534fe618b26807948b3cfe43c02b3f7abf7f4a073778c9c1666d1eb
      >
      > The difference between original and compromised file (rootkit) is
      > attached to this e-mail.
      >
      >
      > Dan.
      >
      >
      >
      > On Wed, 1 Dec 2010, Jeroen Geilman wrote:
      >
      >> On 12/01/2010 01:35 PM, Dan wrote:
      >>>
      >>>
      >>> There is no setgid bit set.
      >>> I had to chmod 777 the /website/vuser directory just so that new
      >>> user creates would work otherwise when it changes uid to some
      >>> virtual id such as 2003, it would not be allowed to create anything
      >>> in the directory to begin with no matter who owned it.
      >>
      >> What does
      >>
      >> namei -m /website/vuser
      >>
      >> say about it ?
      >>
      >> 777 is almost always wrong; logically, it just needs to be chown
      >> :2001 and chmod 775.
      >>
      >>> Its really problematic because even if end user creates the
      >>> /website/vuser/test.com directory ahead of time
      >>
      >> You should not need to do that with vmailboxes.
      >>
      >> Either the MDA or the IMAP server will create them when needed.
      >>
      >>> with correct uid and gid like postfix seems to need to work, the
      >>> uids are an autoincrement field starting at 2002 for each new added
      >>> user, so you can see how this could be cumbersome quickly.
      >>>
      >>> The way postfix is currently working only feasible way to do it
      >>> would be every virtual user on system share same uid then that
      >>> parent directory could be owned by that user.
      >>
      >> That's the usual way to host virtual mailboxes, yes.
      >>
      >>> In that system, every ftp account, imap, pop3, email account would
      >>> be owned by same id.
      >>
      >> The same physical *system* ID, yes.
      >> If this is not what you desire, then using virtual mailbox users
      >> makes no sense for you at all.
      >>
      >> Just use system users, optionally with an invalid shell if you wish
      >> to prevent them logging in.
      >>
      >>> I'm almost considering moving to doing it that way just to avoid
      >>> these issues with postfix, as I'm really trying to see any kind of
      >>> security issues rising from a parent process forking to the same uid
      >>> for everything.
      >>
      >> Minor to non-existent, as long as you don't go around chmodding stuff
      >> to 777.
      >>
      >>> Only one I can see is if ftp users were not chrooted to their
      >>> homedirectory they could go around deleting other users files.
      >>
      >> Use proftpd, it does a virtual chroot.
      >>
      >>> SInce reason I am sharing same gid across all virtual users to begin
      >>> with is to chroot ftp users to their home directory, maybe any
      >>> security risk may be alleviated.
      >>
      >> Yes - use proftpd.
      >>
      >>>
      >>> A correct solution I think however for postfix would be if mkdir
      >>> fails with permission denied errors on parent directory, to change
      >>> uid to root, create directory and change permissions on it.
      >>
      >> Absolutely not.
      >> Postfix wil never execute commands with root privileges unless
      >> specifically configured to do so, and only then in very limited
      >> circumstances.
      >>
      >> Allowing postfix to arbitrarily escalate privileges is fail.
      >>
      >>> I think I may move to sharing same virtual uid and gid for all
      >>> virtual users since ftp chroot is only security risk I can see, and
      >>> if I ever had to move users to a new system and lost permissions on
      >>> all directories would be cumbersome to chown -R each user to
      >>> respective uid again.
      >>
      >> It sounds like you've been unnecessarily complicating things.
      >> Setting up virtual users for multiple services is fairly easy to
      >> accomplish, as long as you have some way of making the userdb
      >> available to all services.
      >>
      >> --
      >> J.
      >>
      >>


      --
      J.
    • Wietse Venema
      ... Apparently, FreeBSD copies the GID of a new directory from its parent, even when the parent does not have sticky/setwhatever bits set. bristle# mkdir
      Message 2 of 19 , Dec 1, 2010
        Dan:
        > Gid inherits top level directory GID?

        Wietse:
        > Turn off the SETGID bit in the PARENT directory.

        Dan:
        > There is no setgid bit set.

        Apparently, FreeBSD copies the GID of a new directory from its
        parent, even when the parent does not have sticky/setwhatever
        bits set.

        bristle# mkdir /var/spool/wietse
        bristle# chown wietse /var/spool/wietse
        bristle# ls -la /var/spool/wietse
        total 4
        drwxr-xr-x 2 wietse wheel 512 Dec 1 09:02 .
        drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
        bristle# su wietse -c 'mkdir /var/spool/wietse/test1'
        bristle# ls -la /var/spool/wietse
        total 6
        drwxr-xr-x 3 wietse wheel 512 Dec 1 09:03 .
        drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
        drwxr-xr-x 2 wietse wheel 512 Dec 1 09:03 test1

        The test1 directory has group wietse, even though my process
        has GID 'wietse'.

        Now, I change the parent directory group to 'wietse'
        and create a new directory:

        bristle# chgrp wietse /var/spool/wietse
        bristle# su wietse -c 'mkdir /var/spool/wietse/test2'
        bristle# ls -la /var/spool/wietse
        total 8
        drwxr-xr-x 4 wietse wietse 512 Dec 1 09:03 .
        drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
        drwxr-xr-x 2 wietse wheel 512 Dec 1 09:03 test1
        drwxr-xr-x 2 wietse wietse 512 Dec 1 09:03 test2

        And test2 has the group of 'wietse'.

        bristle# su wietse -c 'chgrp wietse /var/spool/wietse/test1'
        bristle# ls -la /var/spool/wietse
        total 8
        drwxr-xr-x 4 wietse wietse 512 Dec 1 09:03 .
        drwxr-xr-x 12 root wheel 512 Dec 1 09:02 ..
        drwxr-xr-x 2 wietse wietse 512 Dec 1 09:03 test1
        drwxr-xr-x 2 wietse wietse 512 Dec 1 09:03 test2

        To force the group, change the group after mkdir. This
        does not require switching euid to root.

        Wietse

        In src/util/make_dirs.c:
        if ((ret = mkdir(saved_path, perms)) < 0) {
        if (errno != EEXIST)
        break;
        /* Race condition? */
        if ((ret = stat(saved_path, &st)) < 0)
        break;
        if (!S_ISDIR(st.st_mode)) {
        errno = ENOTDIR;
        ret = -1;
        break;
        }
        }
        ===> if ((ret = chown(saved_path, -1, getegid())) < 0)
        ===> break;


        Wietse
      • lst_hoe02@kwsoft.de
        ... They have corrected it, the infected source for download is replaced, but no warning at all for the ones who already downloaded and now using the
        Message 3 of 19 , Dec 1, 2010
          Zitat von Jeroen Geilman <jeroen@...>:

          > On 12/01/2010 02:30 PM, Dan wrote:
          >>
          >> Thanks for your input, as far as proftpd goes:
          >>
          >> The distribution file available at the main distribution site and all
          >> mirrors has been compromised.
          >> The new file contains a rootkit.
          >>
          >
          > I downloaded the 1.3.3c source and confirmed.
          > Passed it on to the ProFTPd authors and they're looking into it.
          > I will also provide them with the below diff if you don't mind.

          They have corrected it, the "infected" source for download is
          replaced, but no warning at all for the ones who already downloaded
          and now using the trojaned version...

          Not very encouraging to use Proftpd.

          Regards

          Andreas
        • Victor Duchovni
          ... It seems this applies not just to sub-directories, but also to new files: http://www.manpages.info/freebsd/open.2.html When a new file is created it is
          Message 4 of 19 , Dec 1, 2010
            On Wed, Dec 01, 2010 at 10:09:30AM -0500, Wietse Venema wrote:

            > Apparently, FreeBSD copies the GID of a new directory from its
            > parent, even when the parent does not have sticky/setwhatever
            > bits set.

            It seems this applies not just to sub-directories, but also to new
            files:

            http://www.manpages.info/freebsd/open.2.html

            When a new file is created it is given the group of the directory which
            contains it.

            http://www.manpages.info/freebsd/mkdir.2.html

            The directory's owner ID is set to the process's effective user ID. The
            directory's group ID is set to that of the parent directory in which it
            is created.

            And in http://www.manpages.info/freebsd/mount.2.html, we see:

            MNT_SUIDDIR Directories with the SUID bit set chown new files to
            their own owner.

            without any corresponding mechanism to adjust group ownership inheritance.

            The OpenGroup POSIX spec says:

            http://www.opengroup.org/onlinepubs/009695399/functions/mkdir.html

            The directory's user ID shall be set to the process' effective user
            ID. The directory's group ID shall be set to the group ID of the parent
            directory or to the effective group ID of the process. Implementations
            shall provide a way to initialize the directory's group ID to the
            group ID of the parent directory. Implementations may, but need not,
            provide an implementation-defined way to initialize the directory's
            group ID to the effective group ID of the calling process.

            http://www.opengroup.org/onlinepubs/009695399/functions/open.html

            O_CREAT
            ... the user ID of the file shall be set to the effective user
            ID of the process; the group ID of the file shall be set to
            the group ID of the file's parent directory or to the effective
            group ID of the process; ... Implementations shall provide a
            way to initialize the file's group ID to the group ID of the
            parent directory. Implementations may, but need not, provide an
            implementation-defined way to initialize the file's group ID to the
            effective group ID of the calling process.

            --
            Viktor.
          • Voytek Eymont
            ... Andreas, ... Subject: [ProFTPD-announce] ProFTPD ftp.proftpd.org compromise From: TJ Saunders Date: Thu, December 2, 2010 10:43
            Message 5 of 19 , Dec 2, 2010
              On Thu, December 2, 2010 7:20 am, lst_hoe02@... wrote:

              > They have corrected it, the "infected" source for download is
              > replaced, but no warning at all for the ones who already downloaded and now
              > using the trojaned version...
              >
              > Not very encouraging to use Proftpd.

              Andreas,

              fwiw, I got this email today:

              ---------------------------- Original Message ----------------------------
              Subject: [ProFTPD-announce] ProFTPD ftp.proftpd.org compromise
              From: "TJ Saunders" <tj@...>
              Date: Thu, December 2, 2010 10:43 am
              To: proftp-announce@...
              Cc: proftp-devel@...
              proftp-user@...
              --------------------------------------------------------------------------

              -----BEGIN PGP SIGNED MESSAGE-----
              Hash: SHA1

              ProFTPD Compromise Report

              On Sunday, the 28th of November 2010 around 20:00 UTC the main
              distribution server of the ProFTPD project was compromised. The
              attackers most likely used an unpatched security issue in the FTP daemon
              to gain access to the server and used their privileges to replace the
              source files for ProFTPD 1.3.3c with a version which contained a backdoor.
              The unauthorized modification of the source code was noticed by
              Daniel Austin and relayed to the ProFTPD project by Jeroen Geilman on
              Wednesday, December 1 and fixed shortly afterwards.

              The fact that the server acted as the main FTP site for the ProFTPD
              project (ftp.proftpd.org) as well as the rsync distribution server
              (rsync.proftpd.org) for all ProFTPD mirror servers means that anyone who
              downloaded ProFTPD 1.3.3c from one of the official mirrors from 2010-11-28
              to 2010-12-02 will most likely be affected by the problem.

              The backdoor introduced by the attackers allows unauthenticated users
              remote root access to systems which run the maliciously modified version
              of the ProFTPD daemon.

              Users are strongly advised to check systems running the affected code for
              security compromises and compile/run a known good version of the code.
              To verify the integrity of the source files, use the GPG signatures
              available on the FTP servers as well on the ProFTPD homepage at:

              http://www.proftpd.org/md5_pgp.html.
              ---snip-----


              --
              Voytek
            Your message has been successfully submitted and would be delivered to recipients shortly.