linux-kernel - Re: [PATCH v2] Introduce a version6 of autofs interface, to fix design error.

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4F9B33BF.908@zytor.com>
Date:	Fri, 27 Apr 2012 17:03:11 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	David Miller <davem@...emloft.net>, mjt@....msk.ru,
	linux-kernel@...r.kernel.org, autofs@...r.kernel.org,
	raven@...maw.net, thomas@...3r.de, stable@...nel.org
Subject: Re: [PATCH v2] Introduce a version6 of autofs interface, to fix design
 error.

On 04/27/2012 04:07 PM, Linus Torvalds wrote:
> 
> The important change is actually to make the read return the size requested.
> 
> So broken user space does a read() with the wrong size - and then
> checks that it gets *exactly* that many bytes. Not more, not less.
> 
> The way to handle that is to
>  - make sure the kernel always writes the maximally padded data
>  - make the packetization simply drop any data that was in the packet
> that the reader didn't ask for.
> 
> This is very much a semantic change, in that any client that tries to
> read the packet with multiple reads (one 4-byte read to see the size,
> followed by one "right-sized" read of the data) would be totally
> screwed. The first read would indeed read the size, but it also -
> because of the packetized interface - would simply drop the data, and
> the next read would read the first bytes of the next packet.
> 
> But that's not what the autofs users actually do anyway. They just
> read the whole packet.  So we can make *them* work. And the new
> interface will be fairly robust (in fact, you could pass it some big
> buffer and just know you always get exactly one packet, and never have
> that whole stupid "sizeof()" at all).
> 

OK, I follow you now.  That would work for autofs; I presume it is not
something we would export to other users though?  If so I'd worry about
opening up new security issues.

Still, I have to admit... we have a grand total of three users of this
interface as far as we know (autofs, systemd, and am-utils if they ever
revved that one to v5.)  Would it really not be better to do the
zero-eating user space fix?

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/