[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120814044926.GF27715@brightrain.aerifal.cx>
Date: Tue, 14 Aug 2012 00:49:27 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Todo for release?
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
