From owner-freebsd-security@FreeBSD.ORG Mon May 18 18:04:39 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 B1EB38B1 for ; Mon, 18 May 2015 18:04:39 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 801861CC5 for ; Mon, 18 May 2015 18:04:39 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3E9AC20E13 for ; Mon, 18 May 2015 14:04:38 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Mon, 18 May 2015 14:04:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ji2TzdebigY+wg+ DL/G2A1uyxSU=; b=U1cslmQX/PwdlX6sN9NLCT2bD3q46wq7mJRuwlfQo19DtDX vsSAIRLe9s5bQ2GDkFGyQI82VOB1iW8imjIHk738X+iP+RnvPx9yWDNgptPMYUro qu5nZHVmEF3PGn9IZTWmNLabm32yz6RNk+Gc0gdYtp3sHAnnNK2I9QIvbKiI= Received: by web3.nyi.internal (Postfix, from userid 99) id 1F38D10B763; Mon, 18 May 2015 14:04:38 -0400 (EDT) Message-Id: <1431972278.2880231.271899561.7D0CC1CF@webmail.messagingengine.com> X-Sasl-Enc: XKCAhtSInuRIJlG+oujX7EgYzQn33EvwPUrYW26aQj5I 1431972278 From: Mark Felder To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-fd425702 Subject: Re: Forums.FreeBSD.org - SSL Issue? Date: Mon, 18 May 2015 13:04:38 -0500 In-Reply-To: <555A228B.8080807@obluda.cz> 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> <555A228B.8080807@obluda.cz> 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 18:04:39 -0000 On Mon, May 18, 2015, at 12:34, Dan Lukes wrote: > 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 > Fetch also doesn't have a certificate trust store out of the box. It's very dependent on the sysadmin to make good decisions. Much like Apache with mod_ssl will *accept* connections on SSLv3 unless you manually configure the protocols. FYI, you can set SSL_NO_SSL3 and SSL_NO_TLS1 in your env to stop this behavior in fetch. If you add this to your base system image you can lock this down pretty reliably. Keep in mind that changing this default behavior in fetch would be a POLA violation and possibly break scripts for countless users. Comparatively, is the forums HTTPS also a POLA violation? Maybe! I can't decide. :-(