From owner-freebsd-security@FreeBSD.ORG Mon May 18 17:34:09 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0DDBCB2 for ; Mon, 18 May 2015 17:34:09 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53DDC18C9 for ; Mon, 18 May 2015 17:34:08 +0000 (UTC) X-SubmittedBy: id 100000045929 subject /C=CZ/O=Univerzita+20Karlova+20v+20Praze/CN=Dan+20Lukes/unstructuredName=100000045929 issued by /C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA+20Personal+20CA+202 auth type TLS.MFF Received: from kgw.obluda.cz ([194.108.204.138]) (authenticated) by smtp1.ms.mff.cuni.cz (8.14.9/8.14.9) with ESMTP id t4IHY3n0047124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 18 May 2015 19:34:04 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <555A228B.8080807@obluda.cz> Date: Mon, 18 May 2015 19:34:03 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Forums.FreeBSD.org - SSL Issue? References: <2857899F-802E-4086-AD41-DD76FACD44FB@modirum.com> <05636D22-BBC3-4A15-AC44-0F39FB265CDF@patpro.net> <20150514193706.V69409@sola.nimnet.asn.au> <5554879D.7060601@obluda.cz> <1431697272.3528812.269632617.29548DB0@webmail.messagingengine.com> <5556E5DC.7090809@obluda.cz> <1431894012.1947726.271026057.54BB4786@webmail.messagingengine.com> <55590817.1030507@obluda.cz> <1431900010.1965646.271069369.67E0F082@webmail.messagingengine.com> <55591EE8.9070101@obluda.cz> <1431957148.2823348.271640449.22FB98B2@webmail.messagingengine.com> In-Reply-To: <1431957148.2823348.271640449.22FB98B2@webmail.messagingengine.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 17:34:10 -0000 On 05/18/15 15:52, Mark Felder: > I mean, should we have an SA because our libc supports strcpy and people > can use that and create severe vulnerabilities? No, but we should have SA whenever other system component is using strcpy() the way that may affect system security. System utility 'fetch' is willing negotiate known-to-be-insecure protocol with no warning and by default. Sensitive user's data may be transferred by base system utility via insecure protocol. I consider it bug in fetch code. A system utility must not allow silent transfer of data via known insecure protocol if secure transfer has been requested. I see no reason to keep the issue in the dark, even in the case the issue will not be patched on 8-R & 9-R. OK, I'm former bank IT security officer, so I my expectations related to handling of security issues may be set so high. It seems there is nothing more to say about this (slightly off-)topic. I wish the vulnerability should be disclosed to public, you wish it is not necessary because it's known bug in a protocol design and users doesn't expect secure channel from 'fetch'. Two men, two opinions. It's not necessary to reach consent. Thank you for all comments and responses. Dan