netdev - Re: bug in passing file descriptors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Oct 2013 11:44:49 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Steve Rago <sar@...-labs.com>
Cc:	Network Development <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Michael Kerrisk-manpages <mtk.manpages@...il.com>,
	Eric Biederman <ebiederm@...ssion.com>
Subject: Re: bug in passing file descriptors

On Mon, Oct 7, 2013 at 11:27 AM, Steve Rago <sar@...-labs.com> wrote:
> Sending this to a larger group at mtk's suggestion.
>
> I recently found a bug with passing file descriptors over Unix domain
> sockets.  The attached program illustrates the problem.  I believe the
> source of the problem is in net/core/scm.c.  In put_cmsg(), cmlen is
> calculated as CMSG_SPACE(len) for the purposes of setting msg_controllen,
> but it probably should be CMSG_LEN(len), at least in this particular case (I
> didn't investigate other use cases).  On a 32-bit platform, a long is a
> 4-byte quantity and the file descriptor is already aligned to a 4-byte
> quantity by placing it after the cmsghdr structure.  On a 64-byte platform,
> however, a long is an 8-byte quantity, and CMSG_SPACE() assumes that len is
> aligned on an 8-byte boundary, which isn't a requirement for passing file
> descriptors (which are 4-byte quantities; see scm_fp_copy() to verify).
> Anyway, the end result is that recvmsg(2) returns with msg_controllen 4
> bytes larger than it should be on a 64-bit platform.  The attached program
> prints out a warning message when this happens.
>
> I've tried this on kernels as old as 2.6.18, so it appears this bug has been
> around for a while.  I originally found it on a 3.2.0 kernel.  Michael
> verified it still exists on a 3.11 kernel.
>
> Let me know if you need any more information

ISTM that, in order for further cmsgs to be correctly decoded, all of
the relevant things need to match.

put_cmsg uses this layout: cmsghdr, padding, payload, padding.
CMSG_SPACE matches that calculation.

scm_detach_fds is the actual code path for SCM_RIGHTS.  It does the same thing.

CMSG_DATA also things that there's possible padding after cmsghdr.

So I think everything's okay.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html