From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 05:48:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26BFBED4 for ; Fri, 11 Apr 2014 05:48:30 +0000 (UTC) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D82D16A2 for ; Fri, 11 Apr 2014 05:48:29 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id hr17so3073285lab.4 for ; Thu, 10 Apr 2014 22:48:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=L8wuIniROSpK1PlTmsUaiwLcJnvpTqFcXl3rLNb/Xz0=; b=EDUYBTm9gCFMHbInTnndEsV3rIcJ1wyfG0qgXEA2dz77RQMsHmUYWtTT5ZbJcQbRAD dp/tr1+qJlXSAr1TzfVY6XKhFITpMUA21nm1Au0+vMgh15Iq4a/MT42JijAgU1h7xUX3 /CLgSPYBzWiOK1izsmObAj82Difw89r56r6mR9bmUdiTsQCQnc1oSiWzY7jSSaSaX7hA 43XrbEmbEzCx2w+T8zOnS5k69bxDCVoF8+XFjZ/zgVSagPb3FWJsFjBNVEfYDF+AVMXF dZatsynL7Q8RgUbiI3B3MHDZaPW9XRRNEeNgv2Q5LO9w/jOJNIYLjghdwH81mSX6joFy l24Q== X-Gm-Message-State: ALoCoQl/5AhmQDsY5rfsXw6gjvvyzt2O8Ttm0SqXggrGzqafE3Q/GtB0bY/fizf4i/RiX40hBd84 X-Received: by 10.152.115.178 with SMTP id jp18mr15105824lab.23.1397195300670; Thu, 10 Apr 2014 22:48:20 -0700 (PDT) MIME-Version: 1.0 Sender: edelkind@episec.com Received: by 10.114.170.194 with HTTP; Thu, 10 Apr 2014 22:48:00 -0700 (PDT) X-Originating-IP: [207.237.190.18] In-Reply-To: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> From: ari edelkind Date: Fri, 11 Apr 2014 01:48:00 -0400 X-Google-Sender-Auth: z8mNwkEe3hoi8iIyWXWOTC_dTA0 Message-ID: Subject: Re: A different proposal To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 05:48:30 -0000 On Thu, Apr 10, 2014 at 6:28 PM, Paul Hoffman wrote: > I have heard from others, less interested in self-aggrandizement than > Theo, that OpenSSL's malloc was significantly to blame. > OpenSSL's simplistic malloc implementation exacerbated the information exposure in this case, so you might well say that it had a hand in the _severity_ of the bug. Depending on your system malloc, using that instead may or may not have yielded any improvement (and in OpenBSD's case, it would have) -- but the cause was an incredibly silly programming bug that had nothing to do with malloc. I'll get to just how silly it was shortly. I'm not saying OpenBSD's is better, > I'll say that: OpenBSD's is better. :) On that note, re-reading my prior mail, i didn't mean to come off as unflattering toward OpenBSD's malloc. They did a pretty good job with it. > Amateurish failure to check the sanity of user-supplied input was to > > blame. > > Yes. > > > Idiotic, error-prone protocol specifications, written by > > non-programmers, were to blame. > > Not in this case. > I'm not sure how you came to this conclusion, but let me explain how i came to mine: The heartbeat protocol structure sits within the SSL3 record. In the code, you know the length of the data at this point. But instead of using the length of this data to determine the size of your payload, the spec _also_ makes the user supply his own length. This practice is error-prone, and i've seen it cause problems before (the SSH2 spec is also full of garbage like this -- in fact, observing a similar protocol in the SSH2 spec is precisely what led me to discover a remote-execution vulnerability in the cryptlib ssh code, circa 2006). Now, the spec tries to make up for this bizarre requirement by telling the programmer to discard the packet if the specified payload length is "too large", but this is essentially passing the buck: if the spec says, "the implementer MUST avoid all memory-related bugs," and the programmer introduces a bug, does this mean the spec authors are absolved because the program is non-compliant? The best way to avoid memory-related bugs is to avoid practices that commonly result in them. The apparent silliness of this bug then comes to a head when you realize that the programmer who introduced the heartbeat bug is the same person who wrote most of the heartbeat RFC. Updates to ports are inherently slower than patches from the OpenSSL team. > My point is not that either ports or distribution are "too slow" for > everyone: it is that if you are sure you need something faster than them, > there is another option. > I didn't claim that the ports update was or will be fast enough for everyone. What i was getting at was that if you want the new version, but a new port hasn't yet been released, you can update the port files in your local ports tree yourself; it takes a rudimentary knowledge of how the port system works. You are, quite literally, installing the most recent version from source (as you suggest), except that you get automatic package management. ari