From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1582 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Todo for release? Date: Tue, 14 Aug 2012 00:49:27 -0400 Message-ID: <20120814044926.GF27715@brightrain.aerifal.cx> References: <20120813185329.GA20024@brightrain.aerifal.cx> <20120813213154.GI20243@port70.net> <20120813222058.GB8817@openwall.com> <20120814014652.GC27715@brightrain.aerifal.cx> <20120814021317.GA10036@openwall.com> <20120814023508.GD27715@brightrain.aerifal.cx> <20120814024903.GA10188@openwall.com> <20120814025805.GE27715@brightrain.aerifal.cx> <20120814033514.GA10324@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1344919714 15959 80.91.229.3 (14 Aug 2012 04:48:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Aug 2012 04:48:34 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1583-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 14 06:48:35 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T193O-0004ry-Qc for gllmg-musl@plane.gmane.org; Tue, 14 Aug 2012 06:48:30 +0200 Original-Received: (qmail 26075 invoked by uid 550); 14 Aug 2012 04:48:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26063 invoked from network); 14 Aug 2012 04:48:28 -0000 Content-Disposition: inline In-Reply-To: <20120814033514.GA10324@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1582 Archived-At: On Tue, Aug 14, 2012 at 07:35:14AM +0400, Solar Designer wrote: > I guess many daemons written in C limit the length at a few kilobytes - > which may allow for about 100 times greater than intended (by sysadmin) > crypt() running time. For md5crypt and sha*crypt, the first slowdown > occurs between length 15 and 16. > > Then, it does not take explicit realloc() for just the password string > to support arbitrarily long passwords. The daemon may be using an > abstraction layer for all strings - e.g., qmail, Postfix, and vsftpd > have such dynamic string libraries of their own, and overall this is > good (it avoids buffer overflows and artificial limits in other places). I disagree. Avoiding artificial limits almost always means creating difficult-to-debug corner cases when resources are exhausted. It was a popular mantra of the GNU folks in the 80s and 90s, when they boasted how superior their system was to Unix with its hard-coded limits. Of course traditional Unices did have very bad, very low arbitrary limits, and this is what allowed the GNU philosophy to look good, but on a conceptual level, the difference was that the traditional tools with arbitrary limits were able to promise that they would ALWAYS work on conforming input (e.g. text files that met the line-length limit), whereas the GNU utilities would work, well, whenever they didn't run out of memory. Back to the point about logins and daemons that run as root prior to authentication: I consider it a moderate-level security bug for any such program to allow unbounded resource allocation by an unauthenticated client or prior to dropping privileges to the authenticated uses. I'm also pretty cold to the idea of "safe string libraries". Just recently I got to looking inside the MaraDNS code, and its string library, promoted as being extremely secure, just fails to handle allocation failures at all. Sadly this kind of attitude seems to be common. My idea of a safe string library is snprintf. If you use plain C strings, most of them in fixed-size buffers, and never use any function but snprintf (with the correct length argument) to write to them, you're not going to have string overflow exploits. And your code is going to be a lot simpler and more robust than code that's trying to emulate Python/JavaScript/etc.-style strings in C... > I don't know if vsftpd would in fact pass arbitrarily long passwords to > crypt() - this is worth checking. I actually just checked DropBear, and had a hard time finding if/how it limits the length, but it turned out to be a simple 35000-byte limit on packet size in the packet reception code. Presumably the vast majority of that can be the password, if an attacker so desired. > Finally, some services are written in languages that support dynamically > allocated strings natively. I recall that OpenStack's Python code was > patched to impose a limit of 4096 chars on passwords recently, > specifically in response to risks like what we're discussing here. > (And 4096 is still a lot - may allow for some attacks.) This is a great example of why the idea that higher-level languages are more secure than C is such a fallacy... Different language idioms just lead to different things that are easy to get wrong in security-critical ways if you're not careful... Perhaps an ideal language without security issues could be designed, but it would require scrapping the idea that you can pretend resources are infinite and that the runtime magically manages object lifetimes for you. Rich