From owner-freebsd-security@freebsd.org Sun Apr 24 14:30:55 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 812CBB1A4C6 for ; Sun, 24 Apr 2016 14:30:55 +0000 (UTC) (envelope-from rustamabd@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30830126D for ; Sun, 24 Apr 2016 14:30:55 +0000 (UTC) (envelope-from rustamabd@gmail.com) Received: by mail-vk0-x234.google.com with SMTP id t129so188062674vkg.2 for ; Sun, 24 Apr 2016 07:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=kVU14WDs3WFUDzdMrwhB5l/ASG9EqQrkqnWKVrwy/Ms=; b=Pebjm36dI07Qd/bynk/Kfhl36XCoeU9k845TcvLgPEh+XrkE0Dv+RE325OdzqaUOKl uUSjxwMrjudo1XZvV6GD373RO2xbapoYH0gJQKcK1cmaLXUIuOGSnQFU1VLgAJiSRa4H qpr3jOh+i1gXsf3+kakxp7r+yH+Lnl/yzFxdsPcq6+TQ0BMXP9uVxks4nhZyxDe3XhQh UnH3lBGSOO8e/eAPaXdcIg3sRPY9wEaS/slWQfEKOWXeMIxsjP/hFw+rhynGeNZEXmG4 1XsNcsoK3mYiJJxvv6Ow3AvoogJtWHuSDUixRsZ4RSoU+ae6BfK585veCPf1wvL7pe1c U10w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=kVU14WDs3WFUDzdMrwhB5l/ASG9EqQrkqnWKVrwy/Ms=; b=RRF9IHg6LT25gEW0pUXz1rXZlFyJbYrkfNx45OQL1VAZw95cIF1Wwe2zDAYuSKaa5U g5QYyoi1jufspE5Q5V+2VMLeNSGXirbSHUGVV63mdmcAm2ZJzJNUn23T7n51BHDaQLqA zEqwos0sl6TmaEnkGbHnnxnxemISN3AhmxnskCbzkekhJqcJfQgZgfesO/HRxaojgf6h VGsMooSfQrFeilwiWRHpeMIOnr3MzT+biiLI6AvCGEfMP+PW5o5CHnOLySD41/dwnZaw a9Ips6LSiE8trQgA84md4ynmpi9LBkq6QH3CFyL8Fm6jm7XhuLRLXEiCWea/v6kOPJd+ L6Wg== X-Gm-Message-State: AOPr4FXNvHwLWqHlFVZodby18Zlr/6CY6EHy4QOlckij24H8k0IDhldRfnJiIVBGy5L/S313DG4CtkQCjNdU8A== MIME-Version: 1.0 X-Received: by 10.31.108.90 with SMTP id h87mr17110053vkc.156.1461508254061; Sun, 24 Apr 2016 07:30:54 -0700 (PDT) Received: by 10.176.1.21 with HTTP; Sun, 24 Apr 2016 07:30:54 -0700 (PDT) Date: Sun, 24 Apr 2016 16:30:54 +0200 Message-ID: Subject: Signal 11 dumps in telnetd (freebsd 10.3 release) From: Rustam To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 14:30:55 -0000 I got a couple of dozen dumps in /usr/libexec/telnetd (signal 11), and I'm wondering what those could be. FreeBSD 10.3-RELEASE, built from source. Dump stack trace: telrcv+333 ttloop+7C doit+1687 main+64D Dump is at address 0x0000000000404713: .text:0004046E2 loc_4046E2: .text:0004046E2 test byte ptr cs:diagnostic, 10h ; jumptable 0004046DB cases 11,12 .text:0004046E9 jz short loc_4046F7 .text:0004046EB mov edi, offset fmt ; "td: recv IAC" .text:0004046F0 mov esi, ebx ; option .text:0004046F2 call printoption .text:0004046F7 loc_4046F7: .text:0004046F7 call ptyflush .text:0004046FC call init_termbuf .text:000404701 cmp ebx, 0F7h .text:000404707 mov eax, 6199D8h .text:00040470C cmovz rax, r14 .text:000404710 mov rax, [rax] .text:000404713 mov al, [rax] ; <========== Signal 11 HERE .text:000404715 cmp al, 0FFh .text:000404717 jz loc_40495A ; jumptable 0004046DB default case .text:00040471D mov rcx, cs:pfrontp .text:000404724 lea rdx, [rcx+1] .text:000404728 mov cs:pfrontp, rdx .text:00040472F mov [rcx], al .text:000404731 mov cs:telrcv_state, 0 .text:00040473B jmp loc_4049A0 Regards, Rustam From owner-freebsd-security@freebsd.org Mon Apr 25 22:15:36 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50C13B1CB34 for ; Mon, 25 Apr 2016 22:15:36 +0000 (UTC) (envelope-from zingelman@fnal.gov) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0131.outbound.protection.outlook.com [23.103.201.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B880A1246 for ; Mon, 25 Apr 2016 22:15:34 +0000 (UTC) (envelope-from zingelman@fnal.gov) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fermicloud.onmicrosoft.com; s=selector1-fnal-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=47sQnCfFvpL+H2v4+zuEImLPxrDGfSNkEc/Q3xKhSsY=; b=J48oZNAMptWZUJlslZD/3FcnMTc8gFfqQWTENDXNf8TjY43NU6biyG1RTrk54xIA2YC1CbLgKzpFet1opGnpqljGyziXwE6NYSiSrS7LEsk8pfo0zEnZaUKzZCUmC0W8cxU9lA3HIBwMEK1PqIqJ6Bp8kl017HfBk+b7JTj81T4= Received: from BY2PR09CA0044.namprd09.prod.outlook.com (10.242.234.172) by BY2PR09MB1096.namprd09.prod.outlook.com (10.166.116.16) with Microsoft SMTP Server (TLS) id 15.1.477.8; Mon, 25 Apr 2016 19:42:37 +0000 Received: from BN1BFFO11FD006.protection.gbl (2a01:111:f400:7c10::1:167) by BY2PR09CA0044.outlook.office365.com (2a01:111:e400:2c2c::44) with Microsoft SMTP Server (TLS) id 15.1.477.8 via Frontend Transport; Mon, 25 Apr 2016 19:42:37 +0000 Authentication-Results: spf=softfail (sender IP is 131.225.70.95) smtp.mailfrom=fnal.gov; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=fnal.gov; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning fnal.gov discourages use of 131.225.70.95 as permitted sender) Received: from smtp-ux-prd2.fnal.gov (131.225.70.95) by BN1BFFO11FD006.mail.protection.outlook.com (10.58.144.69) with Microsoft SMTP Server (TLS) id 15.1.472.8 via Frontend Transport; Mon, 25 Apr 2016 19:42:37 +0000 Received: from nova.fnal.gov (nova.fnal.gov [131.225.121.207]) by smtp-ux-prd2.fnal.gov (Postfix) with SMTP id 5E9631409A8; Mon, 25 Apr 2016 14:42:36 -0500 (CDT) Received: from nova.fnal.gov (localhost [127.0.0.1]) by nova.fnal.gov (8.14.4+Sun/8.14.4) with ESMTP id u3PJgaTq016216; Mon, 25 Apr 2016 14:42:36 -0500 (CDT) Received: from localhost (tez@localhost) by nova.fnal.gov (8.14.4+Sun/8.14.4/Submit) with ESMTP id u3PJgZ2w016213; Mon, 25 Apr 2016 14:42:36 -0500 (CDT) X-Authentication-Warning: nova.fnal.gov: tez owned process doing -bs Date: Mon, 25 Apr 2016 14:42:35 -0500 From: Tim Zingelman X-X-Sender: tez@nova.fnal.gov Reply-To: Tim Zingelman To: Rustam CC: "freebsd-security@freebsd.org" Subject: Re: Signal 11 dumps in telnetd (freebsd 10.3 release) In-Reply-To: <6c6961526afe4f8b947fa11d585befd3@BY2PR09MB0754.namprd09.prod.outlook.com> Message-ID: References: <6c6961526afe4f8b947fa11d585befd3@BY2PR09MB0754.namprd09.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-559023410-959030623-1461613355=:16065" X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.225.70.95; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(24454002)(189002)(199003)(43066003)(105596002)(106466001)(15975445007)(76506005)(57986006)(5008740100001)(6806005)(84326002)(1411001)(1220700001)(2476003)(1096002)(19580395003)(19580405001)(86362001)(4326007)(11100500001)(586003)(3450700001)(110136002)(5001970100001)(2950100001)(189998001)(512954002)(53806999)(50986999)(76176999)(54356999)(2906002)(87936001)(568964002)(5890100001)(4610100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR09MB1096; H:smtp-ux-prd2.fnal.gov; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD006; 1:v665pO+6dqy8a7vEhRPx8Z1FBLMl5lpNBJGDbXnvs6GgexDX0n7fCwABG+kEVznt/ruuAh/ut8gLQEEOMhxTKP6tLlMbFSEtTvvCUP7bbvZwbhuivevWMBauslZs3bineSIfwoM01LwKWei9p8Uzf7rFm+NE+7St570F+XyTc+bX3g01VeckLrWNXUdIStSRaAqBecL6+5Q3yN2SmVjPEKBOjGm2EgrymxWLWTI3/Sx3dsj80t6YKP8dthxH5VJp/HHUhEmldGP3KMnCYeG4Y208Y5yJYWuFKjeLFRnvZ35PChiXBe+p/TtFnFvSxtOR+jWIng4XQl2n65U9CBnYW7xLARL9k5TGJiMjwWn+ItBd+2qlA9xZiTkL5WgwQpZkZS9vCriDv+xgCNPwHg20qhbykaJEhB344icfuHRa8Ic3b5mGfmxZ0eJXy/6Hgj2Ghk/JR4FGpQ5HmsXGSP/PzyZuLUqzrOS7Hu8eTAmgZ0o4o8pji8HxgwHepChBmIFGrl2Bd3HO9DvxNS0LtaZpMV2d1RRDvL5gJoFlb2MFXYMZ5bDrVdyJuLECK3NJqBVt X-MS-Office365-Filtering-Correlation-Id: d86825e0-6c63-47a9-7b33-08d36d41c18f X-Microsoft-Exchange-Diagnostics: 1; BY2PR09MB1096; 2:QIEMnmCJ4WdtnF5iPfiYg7MX0jtA3eFDsG5s3VxNzG7aToPPo1yr+pRO9z/TC+ZMXn1xMlAye2tuYJN44EnIhmIAQSHKbb3W3BNbJHQUX8ub+ilrf+TX/Mu/+gSEdMO//zQmPDsg5AZQ2VVa41PDUXVNsMLV/CGOplZzXpyVstwm4paS/qAt4F9nK5EbZURx; 3:a6Ajak7bj3xPeorV18eY/JL7H3IUD4wR/Lq4OXeQadvoKFSER6I48C1xdP9uHkqu4e0IniRFwom3fRO3V02lNbcY2utZTqiWxGVBN7ln40zVegpeiEjuz8uj3ftyn1daCqfP8yVViT+yRxY5HaBIxRCfdRREUNSy6244RKnEAK1a5nLflZohyoNCTv2OM9cQ7ryUPukqE8Hb3qDaQ3M2Qxe/gpT80FgTpJRaHC+YUOQ=; 25:0yLPPlve3Zzwnq3L3AtU0Va6FWTkpbMhPA55q/lnBMlf/jwOrtZe/KUIA0uXFvXFZtgQ7Gp6LQJdOtnEmKOV5jGesEGHETP2HLftELG4N+3frk4JNIU4DjHm8oTGFs61lhTgEMNU5ZU+l8abSp7ieWg2hpD2cTXbsnuLs0pr/SjAzBFwufeFw/3eNWTkkVs6cmL+kUaLcilCoXqAK5A+y0JmZNzvTYKNjQTEuqEbi0B9u0y/CUZEFjQd1HbKtxYZfAQU0rAKgKPoE/sBnMJ0QtiumFIc+8VZYgOlHIRyosJKgOKUqCv7QBXX/xwn/ahIMg7pmObbZ/8ZY+WWxPVwojdVQgB4jP63dYake8bFJ/vYCCOQCAeg9pxv9xkpAvq5 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB1096; X-Microsoft-Exchange-Diagnostics: 1; BY2PR09MB1096; 20:gpfZWRbBvx4es1xUzniVfesvim0OFj3zaXym5qmtWxmUaxxZ2WJggqMeCrlOL8QHa96hPHmGFIIxwC0i857CfsEdgstvapKh3mSBhsGzlPsjxh+v4q15OeT/LDfw27qo2moW0fWWzl7YCiiIDv8vw/Gse0SXeM9+0AMFB+55w8n9hLxUX9OSYoiTNscun8Nn9PsCMLb1rxoV/p4sp1z7dbEUQyTkPDljUA5RV7XIhMIaKS4rSvhxuw6QyIXS39izdCJUbZdFD01EOFKLupWaKEm4YEE27EpSca5PrVomr1XFhUh4YLlC9j44U+HlaUapRoNQlnpj1bi90KqZDSDCVnsL+h1l+IGXIC5CLCMUrnAO0kIZ6wC6j0zfA1n5/3Cf7liV3q0RRQ9CrNHklN0cmem4qLNqDv2ps5IFLVd6ji58v4I+fqcF/Qeom7WdgAUozWk5Ps9ejBaAe3sPSbcjutN9hhxiiYYt4WnwkX13m5CGaqqb5cvUKrdwV0sp+oij X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415293)(102615271)(9101521072)(601004)(2401047)(13018025)(13024025)(8121501046)(5005006)(13023025)(13017025)(13015025)(3002001)(10201501046)(6055026); SRVR:BY2PR09MB1096; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB1096; X-Microsoft-Exchange-Diagnostics: 1; BY2PR09MB1096; 4:zvkT/DpKWMnZZTwx9+7xKzBktkqYF9nw1x9nbwLFLZ8FpyRhVQb/27DTIBoRnguguu7aiOQSpQY+4GfbqVXQSAfD+Xxaa8Z3t18ewoys7cAgvS4bzX77I14VqzQB5ZDM4FPneI5mJsEo9CkY4NlIcf43+2AIZ1I3lSSHX6pgUysw10UK1Ap4sP4NQVBSH18rSUBfyto5GD3wpGl+1wnIARRJtKPObGVTPx8vyhtJcyiTCaEdoQdwJc6QCh4SYu0++gkbEkkj5UJyd8y4k98gfTvwvOud9eKcIaBLVuDQjKwYxLLELcKYRMrCKhRMkn1xfHOei7NAoEupKdLl7+1peoS87yKa0/oi2GFy+pDrzEMF1bX1xWvZHcJ93Igcx2IxGpVjp8lyN5dgtp+Dfx5Y5koMMxtQmJJeCkmJrFribTP8WgKRrEDNzXF2cCl1Sf9EQ8ptVwN2tXHWIlrYCiZhn71Dgxt7JVLYikEGZDF4llpTuY7wy4BwlgZRlWeSOgKYR65GVSp3d2/Ui/chex7Pzcjq19/EFjaf2KVPqlKJazM= X-Forefront-PRVS: 0923977CCA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR09MB1096; 23:ddPoSXsWivau6Je0rdNu8y95kyK4dA3z/xscTiIhi?= =?us-ascii?Q?mqIXDpSsenqa4EjHp6hZv7KHriOXffL9gk7luTp80g4bWBowNv7IVhPsOsXf?= =?us-ascii?Q?0JBexaDYkYAJVXBJrrY8zW3m9cDB0z2Frc/5DUDxgT20mNL8pNHPaoHkRIft?= =?us-ascii?Q?q+FWjsBLsebi/pz2PwqhHFR6Dsiawtx9QfEkxdl8g0X+3A3bw389ltYB9eP4?= =?us-ascii?Q?hjI0q2ZyDGC3FG5pfznZEoyYog2E3Kh9FwVnoLDCVJcGVOTBDxl2tF+uWHc8?= =?us-ascii?Q?mf2velnuQT08Le5qOa7dW0sjMjxjlkciyz3eMt1ZRkJlSmoL3H9p2HcsD78R?= =?us-ascii?Q?mw6+T6Ec6ZROkeU4F6Gvf30THW24YAeZXz1m9q72PfsywwTqbUJLWzzOjXIn?= =?us-ascii?Q?+sO/KYfWmHik8ZJYZlSNApQLiMOIfz3ybmCxRPtLFThLoTN1uDKBeRPjTkQK?= =?us-ascii?Q?8N2YpjTwgF/xjmxCn8PLe0mZ/ZBhvQg6gIjwSAvnga1MWLWoO7lTF9L5m22C?= =?us-ascii?Q?F8clvb9i4kDBvKFBxPV85nKuyilbd3JfK+eZpaHkSpxBcjauOcxlg06HmnV3?= =?us-ascii?Q?JSHEop3n6PelUrdGqZfVuJVn9bxoxqG1J1jwymotZaeb1PKpfGU5RPrHRKpN?= =?us-ascii?Q?QMVdj+0euTs44U09wusMi2POJlupr99pqGELrBCR7oHjmYF/LnpGbCZcrNAJ?= =?us-ascii?Q?MHkwcIZNzad8aynK9TvGUiA1PH5G8pEqtRDcyON4bk9QSQJ2Mg7plepALxMw?= =?us-ascii?Q?WxsyzbJ3jDMEU1t8n5MHlEETB1HZJYiT3RbJY/DCQJQ15pX00j5yi9T4L2ei?= =?us-ascii?Q?e5GcuKMDYiIzeeMpVHjIHflMqiwLPiZLrPhqhWo300/LMIFTB443yE9ghkwQ?= =?us-ascii?Q?ZwxltVMNDT9YRviVIhHPYCp41kUb44lXqNGmsNYOoKqYvjckYJUNyRWVqzU6?= =?us-ascii?Q?B6lToTia0LE0nZLfX1P1uTPBY7gBobGNbBPJt4FF/MPNajFJ9Cctbj3xDvAj?= =?us-ascii?Q?vVVmgeI3AJ010/j5d91yVqN31VAt/OqJwhjkfWaQn15P2zVEuztjjCXUH58Z?= =?us-ascii?Q?T8Zzmc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR09MB1096; 5:rf3WsznBXuCqA0a2LpkKTRsh2lSlthGFOpB8/M86GUbF2cr+pNMPSAR1mBoaEjWx7XRiMUMB42vetk/Sa0rh7GX07MFLLRI3I7o3ha/VwoN78G3llikJVX8pDyNsm1BWWBPDoMrknYdc977vuZxfWA==; 24:ojelMFhbZ+6vaMVsFwfOQrpU/ctQ62beE6IaoxGvrW2x0Drlqw9XRp5c7AvvvCm0lE7DdMRH3USiy4yMMMmcBt3YIxpcdd8ETicC+7ElHLg=; 7:wro+JSzlELxqN0sYbpf9Rke18sfGrY+iQcvIHRXB8bVaZ4R6LzS1IAukdon5FlehnL1fpdW92g4ZpMut4TNNKNpHfW7gb0sIGeOnuA8OS/XLMVqlYgxZc63zCOu36sLI1eqWdXGsrkquALddBG5mcalzn165CPNmIrDGiEe31LGGPiF4RsVjynfOWVHSnw4p SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: fnal.gov X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2016 19:42:37.4739 (UTC) X-MS-Exchange-CrossTenant-Id: 9d5f83d3-d338-4fd3-b1c9-b7d94d70255a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=9d5f83d3-d338-4fd3-b1c9-b7d94d70255a; Ip=[131.225.70.95]; Helo=[smtp-ux-prd2.fnal.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB1096 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 22:15:36 -0000 ---559023410-959030623-1461613355=:16065 Content-Type: text/plain; charset="US-ASCII"; format=flowed See if the attached patch helps. It applies cleanly to ports/security/krb5-appl, but may need adjustment for the base system telnetd. - Tim On Sun, 24 Apr 2016, Rustam wrote: > I got a couple of dozen dumps in /usr/libexec/telnetd (signal 11), and I'm > wondering what those could be. > > FreeBSD 10.3-RELEASE, built from source. > > Dump stack trace: > telrcv+333 > ttloop+7C > doit+1687 > main+64D > > Dump is at address 0x0000000000404713: > > .text:0004046E2 loc_4046E2: > .text:0004046E2 test byte ptr cs:diagnostic, 10h ; jumptable > 0004046DB cases 11,12 > .text:0004046E9 jz short loc_4046F7 > .text:0004046EB mov edi, offset fmt ; "td: recv IAC" > .text:0004046F0 mov esi, ebx ; option > .text:0004046F2 call printoption > .text:0004046F7 loc_4046F7: > .text:0004046F7 call ptyflush > .text:0004046FC call init_termbuf > .text:000404701 cmp ebx, 0F7h > .text:000404707 mov eax, 6199D8h > .text:00040470C cmovz rax, r14 > .text:000404710 mov rax, [rax] > .text:000404713 mov al, [rax] ; <========== Signal 11 HERE > .text:000404715 cmp al, 0FFh > .text:000404717 jz loc_40495A ; jumptable 0004046DB > default case > .text:00040471D mov rcx, cs:pfrontp > .text:000404724 lea rdx, [rcx+1] > .text:000404728 mov cs:pfrontp, rdx > .text:00040472F mov [rcx], al > .text:000404731 mov cs:telrcv_state, 0 > .text:00040473B jmp loc_4049A0 > > > Regards, > > Rustam > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > ---559023410-959030623-1461613355=:16065 Content-Type: text/plain; charset="US-ASCII"; name="patch-telnet__telnetd__state.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="patch-telnet__telnetd__state.c" LS0tIHRlbG5ldC90ZWxuZXRkL3N0YXRlLmMub3JpZwkyMDE2LTAyLTE5IDE0 OjQ0OjU3LjAwMDAwMDAwMCAtMDYwMA0KKysrIHRlbG5ldC90ZWxuZXRkL3N0 YXRlLmMJMjAxNi0wMi0xOSAxNDo0Nzo0NC4wMDAwMDAwMDAgLTA2MDANCkBA IC0yMjcsMTYgKzIyNywxOCBAQA0KIAkJCWNhc2UgRUM6DQogCQkJY2FzZSBF TDoNCiAJCQkgICAgew0KLQkJCQljY190IGNoOw0KKwkJCQljY190IGNoID0g KGNjX3QpKF9QT1NJWF9WRElTQUJMRSk7DQogDQogCQkJCURJQUcoVERfT1BU SU9OUywNCiAJCQkJCXByaW50b3B0aW9uKCJ0ZDogcmVjdiBJQUMiLCBjKSk7 DQogCQkJCXB0eWZsdXNoKCk7CS8qIGhhbGYtaGVhcnRlZCAqLw0KIAkJCQlp bml0X3Rlcm1idWYoKTsNCiAJCQkJaWYgKGMgPT0gRUMpDQotCQkJCQljaCA9 ICpzbGN0YWJbU0xDX0VDXS5zcHRyOw0KKwkJCQkJaWYgKHNsY3RhYltTTENf RUNdLnNwdHIpDQorCQkJCQkgIGNoID0gKnNsY3RhYltTTENfRUNdLnNwdHI7 DQogCQkJCWVsc2UNCi0JCQkJCWNoID0gKnNsY3RhYltTTENfRUxdLnNwdHI7 DQorCQkJCQlpZiAoc2xjdGFiW1NMQ19FTF0uc3B0cikNCisJCQkJCSAgY2gg PSAqc2xjdGFiW1NMQ19FTF0uc3B0cjsNCiAJCQkJaWYgKGNoICE9IChjY190 KShfUE9TSVhfVkRJU0FCTEUpKQ0KIAkJCQkJKnBmcm9udHArKyA9ICh1bnNp Z25lZCBjaGFyKWNoOw0KIAkJCQlicmVhazsNCg== ---559023410-959030623-1461613355=:16065-- From owner-freebsd-security@freebsd.org Tue Apr 26 03:13:07 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1F80B0DB1D for ; Tue, 26 Apr 2016 03:13:07 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 864661F93 for ; Tue, 26 Apr 2016 03:13:07 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-ca3ff70000004b9e-3d-571edb8d1378 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 6A.01.19358.D8BDE175; Mon, 25 Apr 2016 23:07:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u3Q37vLG006428; Mon, 25 Apr 2016 23:07:57 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u3Q37s8T005284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Apr 2016 23:07:56 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u3Q37rvQ009678; Mon, 25 Apr 2016 23:07:53 -0400 (EDT) Date: Mon, 25 Apr 2016 23:07:53 -0400 (EDT) From: Benjamin Kaduk To: Tim Zingelman cc: Rustam , "freebsd-security@freebsd.org" Subject: Re: Signal 11 dumps in telnetd (freebsd 10.3 release) In-Reply-To: Message-ID: References: <6c6961526afe4f8b947fa11d585befd3@BY2PR09MB0754.namprd09.prod.outlook.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nott7Wy7cYFazrUXPpidsFk3T2tgt 3v6ewurA7LHhzG0mjxmf5rN47Jx1lz2AOYrLJiU1J7MstUjfLoErY/K5+WwFm5gq3vRPZ2tg /MrYxcjJISFgInFz7T3mLkYuDiGBNiaJF6sOsEA4GxklGqa1QTmHmCT2bH7HCOE0MEosX/CL HaSfRUBbYsbzh2A2m4CKxMw3G9lAbBEBNYl3E9vA4swCGRJ3Z08Gs4UF7CSaP7WD1XAC2a9u gqzj5OAVcJR4eO4/G8SCDkaJg6fugBWJCuhIrN4/BapIUOLkzCcsEEO1JJZP38YygVFgFpLU LCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIzS/RSU0o3MYJClVOSfwfjnAbvQ4wC HIxKPLwKy+TChVgTy4orcw8xSnIwKYny/pkMFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCq34O KMebklhZlVqUD5OS5mBREudlZGBgEBJITyxJzU5NLUgtgsnKcHAoSfBK3AJqFCxKTU+tSMvM KUFIM3FwggznARq+9CbI8OKCxNzizHSI/ClGXY4FP26vZRJiycvPS5US590FUiQAUpRRmgc3 B5xidjOpvmIUB3pLmHciyDoeYHqCm/QKaAkT0JLLh2RBlpQkIqSkGhhtdP6V+iqzX9koNK+l ftWmPUHT8/O7GtuWz2ic+WPRlI+v9r2O2/pMtSp1bb57xxmPdY/9S58eOscqU1DRkcx5TTer 5PPtWo9fhxWu/JCM/MvnoBKlxsjyOGiWoZ3yFZ8LOxJy9jyZHi+y4WD3qbJ99m5rVvEl6JVf arTJnqx4ZmnVnYM6j/yUWIozEg21mIuKEwHhiZIpDAMAAA== X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 03:13:07 -0000 On Mon, 25 Apr 2016, Tim Zingelman wrote: > See if the attached patch helps. > > It applies cleanly to ports/security/krb5-appl, but may need adjustment for > the base system telnetd. [Obligatory note that krb5-appl is unmaintained upstream, due to insecure crypto, among other things.] -Ben From owner-freebsd-security@freebsd.org Fri Apr 29 08:29:53 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA7C0B20F03 for ; Fri, 29 Apr 2016 08:29:53 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E1E7C196B; Fri, 29 Apr 2016 08:29:53 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1035) id DB31D1769; Fri, 29 Apr 2016 08:29:53 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20160429082953.DB31D1769@freefall.freebsd.org> Date: Fri, 29 Apr 2016 08:29:53 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 08:29:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-16:16.ntp Security Advisory The FreeBSD Project Topic: Multiple vulnerabilities of ntp Category: contrib Module: ntp Announced: 2016-04-29 Credits: Network Time Foundation and various contributors listed below Affects: All supported versions of FreeBSD. Corrected: 2016-04-27 15:24:33 UTC (stable/10, 10.3-STABLE) 2016-04-29 08:02:31 UTC (releng/10.3, 10.3-RELEASE-p1) 2016-04-29 08:02:31 UTC (releng/10.2, 10.2-RELEASE-p15) 2016-04-29 08:02:31 UTC (releng/10.1, 10.1-RELEASE-p32) 2016-04-27 15:25:18 UTC (stable/9, 9.3-STABLE) 2016-04-29 08:02:31 UTC (releng/9.3, 9.3-RELEASE-p40) CVE Name: CVE-2016-1547, CVE-2016-1548, CVE-2016-1549, CVE-2016-1550, CVE-2016-1551, CVE-2016-2516, CVE-2016-2517, CVE-2016-2518, CVE-2016-2519 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP) used to synchronize the time of a computer system to a reference time source. II. Problem Description Multiple vulnerabilities have been discovered in the NTP suite: On OSes (FreeBSD not affected) that allows packets claiming to be from 127.0.0.0/8 that arrive over physical network, if ntpd is configured to use a reference clock, an attacker can inject packets over the network that look like they are coming from that reference clock. [CVE-2016-1551, Reported by Matt Street and others of Cisco ASIG] If a system is set up to use a trustedkey, and if one is not using the feature introduced in ntp-4.2.8p6 allowing an optional 4th field in the ntp.keys file to specify which IPs can serve time, a malicious authenticated peer -- i.e. one where the attacker knows the private symmetric key -- can create arbitrarily-many ephemeral associations in order to win the clock selection of ntpd and modify a victim's clock. [CVE-2016-1549, Reported by Matthew Van Gundy of Cisco ASIG] If ntpd was expressly configured to allow for remote configuration (this is not common), a malicious user who knows the controlkey for ntpq or the requestkey for ntpdc (if mode7 is expressly enabled) can create a session with ntpd and if an existing association is unconfigured using the same IP twice on the unconfig directive line, ntpd will abort. [CVE-2016-2516, Reported by Yihan Lian of the Cloud Security Team, Qihoo 360] If ntpd was expressly configured to allow for remote configuration (this is not common), a malicious user who knows the controlkey for ntpq or the requestkey for ntpdc (if mode7 is expressly enabled) can create a session with ntpd and then send a crafted packet to ntpd that will change the value of the trustedkey, controlkey, or requestkey to a value that will prevent any subsequent authentication with ntpd until ntpd is restarted. [CVE-2016-2517, Reported by Yihan Lian of the Cloud Security Team, Qihoo 360] Using a crafted packet to create a peer association with hmode > 7 causes the MATCH_ASSOC() lookup to make an out-of-bounds reference. [CVE-2016-2518, Reported by Yihan Lian of the Cloud Security Team, Qihoo 360] ntpq and ntpdc can be used to store and retrieve information in ntpd. It is possible to store a data value that is larger than the size of the buffer that the ctl_getitem() function of ntpd uses to report the return value. If the length of the requested data value returned by ctl_getitem() is too large, the value NULL is returned instead. There are 2 cases where the return value from ctl_getitem() was not directly checked to make sure it's not NULL, but there are subsequent INSIST() checks that make sure the return value is not NULL. There are no data values ordinarily stored in ntpd that would exceed this buffer length. But if one has permission to store values and one stores a value that is "too large", then ntpd will abort if an attempt is made to read that oversized value. [CVE-2016-2519, Reported by Yihan Lian of the Cloud Security Team, Qihoo 360] For ntp-4 versions up to but not including ntp-4.2.8p7, an off-path attacker can cause a preemptable client association to be demobilized by sending a crypto NAK packet to a victim client with a spoofed source address of an existing associated peer. This is true even if authentication is enabled. Furthermore, if the attacker keeps sending crypto NAK packets, for example one every second, the victim never has a chance to reestablish the association and synchronize time with that legitimate server. For ntp-4.2.8 up to ntp-4.2.8p6 there is less risk because more stringent checks are performed on incoming packets, but there are still ways to exploit this vulnerability in versions before ntp-4.2.8p7. [CVE-2016-1547, Reported by Stephen Gray and Matthew Van Gundy of Cisco ASIG] It is possible to change the time of an ntpd client or deny service to an ntpd client by forcing it to change from basic client/server mode to interleaved symmetric mode. An attacker can spoof a packet from a legitimate ntpd server with an origin timestamp that matches the peer->dst timestamp recorded for that server. After making this switch, the client will reject all future legitimate server responses. It is possible to force the victim client to move time after the mode has been changed. ntpq gives no indication that the mode has been switched. [CVE-2016-1548, Reported by Miroslav Lichvar of RedHat and separately by Jonathan Gardner of Cisco ASIG] Packet authentication tests have been performed using memcmp() or possibly bcmp(), and it is potentially possible for a local or perhaps LAN-based attacker to send a packet with an authentication payload and indirectly observe how much of the digest has matched. [CVE-2016-1550, Reported independently by Loganaden Velvindron, and Matthew Van Gundy and Stephen Gray of Cisco ASIG] III. Impact Malicious remote attackers may be able to break time synchornization, or cause the ntpd(8) daemon to crash. IV. Workaround No workaround is available, but systems not running ntpd(8) are not affected. Network administrators are advised to implement BCP-38, which helps to reduce risk associated with the attacks. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. The ntpd service has to be restarted after the update. A reboot is recommended but not required. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install The ntpd service has to be restarted after the update. A reboot is recommended but not required. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-16:16/ntp.patch # fetch https://security.FreeBSD.org/patches/SA-16:16/ntp.patch.asc # gpg --verify ntp.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart the applicable daemons, or reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/9/ r298700 releng/9.3/ r298770 stable/10/ r298699 releng/10.1/ r298770 releng/10.2/ r298770 releng/10.3/ r298770 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.11 (FreeBSD) iQIcBAEBCgAGBQJXIxXiAAoJEO1n7NZdz2rnAXgP/0OzpMmgCt4H9ldywUWaFmtr ppIrbIXEuruh08TqrBm+PgUKFT0rZptCtX5pvZ/CwPdqfaisbvWkphcMART47q/Y NcysqVGddmQUvrYihirYloj8qiODPu6XNqSG6QS4fw26NP1/dPnUmAREsTukWJjk rAE+YZloikmKHXPXmG0Dr2STlzLrPDpeEp0aEb+MybZLerzyS6OyzTrnDLHttkwb PFdA54KH4kUzCKJu3O4xtXimMjRm8s7tyOSHQhCI3U6bgTB0Q3hU+9FDFsx3K/7+ LsIa3JVefdgcIRnKWqli31Nk3fyndYgjFXpcqdUnK7bA0RpliGPqW90gom6W+Jb7 uRE5BDWHH3z9KAAGtOpziN20aWXeHHuisDpyfLVNyE350qyKuoVR/FPEa6mc2Fc4 CN53AfTQYPnGrwH4BnIVg2AsOmwwrEWx/TvzQ2DZLrKsUCklWXiUOxHz+6jXlz5v RGIYJtJX/B+QN5a3RgAcluMb/A08FzjyAx57mEkYesv4nQn+9i2lLCP/LFHxId49 3rTmk817Mx1SMIS8Xc1bnd94gOBK8kNuduiV0xVKoJIn4IK5puwy/CBtx2jfMfI7 FPN6Krm7cQDy7z1rAZc80gTuIcMqXFNDHVtGVq+AqDQyv6rXL2iM8N+3xgQEe8Ei fKgeiTiC4OSqKYLy/Ut/ =nQp/ -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Fri Apr 29 11:18:55 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FB48B20D0F for ; Fri, 29 Apr 2016 11:18:55 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: from smtp-3-out.integrity.hu (smtp-3-out.integrity.hu [212.52.165.213]) by mx1.freebsd.org (Postfix) with ESMTP id B72041ADE for ; Fri, 29 Apr 2016 11:18:54 +0000 (UTC) (envelope-from gabor@zahemszky.hu) Received: from webmail.integrity.hu (mail-fe-1.integrity.hu [10.1.64.120]) by mail-smtp.integrity.hu (Postfix) with ESMTPA id 8211E40329 for ; Fri, 29 Apr 2016 13:13:21 +0200 (CEST) Received: from +Oqy66MTEcckkNdeGS/+JeMunA4hvTPA by webmail.integrity.hu with HTTP (HTTP/1.1 POST); Fri, 29 Apr 2016 13:13:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 29 Apr 2016 13:13:21 +0200 From: gabor@zahemszky.hu To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp In-Reply-To: <20160429082953.DB31D1769@freefall.freebsd.org> References: <20160429082953.DB31D1769@freefall.freebsd.org> Message-ID: <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> X-Sender: gabor@zahemszky.hu User-Agent: Roundcube Webmail/1.1.4 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 11:18:55 -0000 > 2) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install Both on an i386 and on an amd64 machine, I got: ==== .... Fetching metadasa signature for 10.3-RELEASE from update5.freebsd.org... done Fetching metadata index.... done The update metadata is correctly signed, but failed an integrity check. Cowardly refusing to proceed any further. ==== Both machines are VM-s, upgraded from 10.2. (Got the same with -s update[23456].freebsd.org, and without -s option. Zahy < Gabor at Zahemszky dot HU > From owner-freebsd-security@freebsd.org Fri Apr 29 11:24:03 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75955B20062 for ; Fri, 29 Apr 2016 11:24:03 +0000 (UTC) (envelope-from starikarp@yandex.com) Received: from forward15h.cmail.yandex.net (forward15h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::a0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 307F511E9 for ; Fri, 29 Apr 2016 11:24:02 +0000 (UTC) (envelope-from starikarp@yandex.com) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward15h.cmail.yandex.net (Yandex) with ESMTP id 72D7922175 for ; Fri, 29 Apr 2016 14:23:26 +0300 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 2D9492C1332 for ; Fri, 29 Apr 2016 14:23:26 +0300 (MSK) Received: by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Vk6gGLamRQ-NP94L570; Fri, 29 Apr 2016 14:23:25 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1461929005; bh=5CbrQbwsHU821wWBIfEmd24nfU+ixjNFqZSkTeu+byE=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References: Content-Type:X-Mailer:Mime-Version:Content-Transfer-Encoding; b=F+kii2y3P17lSPGcqFGrv5SHU2bJftOD6TJYx9gLMU5Ari7ypWI80krYwquUuBT9x kUzblltgG4MyF0p01fkdU61aaEnxxCg0sxWhgB67mpyxpBV091C33n36bC0Bo8VTFh rM8WWRThJfSJGnrQhWoO9nvRt2SUikDPEk/9iGd4= Authentication-Results: smtp4h.mail.yandex.net; dkim=pass header.i=@yandex.com X-Yandex-ForeignMX: US X-Yandex-Suid-Status: 1 0 Message-ID: <1461929003.67736.2.camel@yandex.com> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp From: Stari Karp To: freebsd-security@freebsd.org Date: Fri, 29 Apr 2016 07:23:23 -0400 In-Reply-To: <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 11:24:03 -0000 On Fri, 2016-04-29 at 13:13 +0200, gabor@zahemszky.hu wrote: > > > > 2) To update your vulnerable system via a binary patch: > > > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > > platforms can be updated via the freebsd-update(8) utility: > > > > # freebsd-update fetch > > # freebsd-update install > Both on an i386 and on an amd64 machine, I got: > > ==== > .... > Fetching metadasa signature for 10.3-RELEASE from > update5.freebsd.org...  > done > Fetching metadata index.... done > > The update metadata is correctly signed, but > failed an integrity check. > Cowardly refusing to proceed any further. > ==== > > Both machines are VM-s, upgraded from 10.2. > > (Got the same with -s update[23456].freebsd.org, and without -s > option. > > Zahy < Gabor at Zahemszky dot HU > > _______________________________________________ I have the same. I did upgrade FreeBSD 10.2 with freebsd-update to version 10.3: freebsd-version -ku 10.3-RELEASE 10.3-RELEASE FreeBSD 10.3-RELEASE #1: Sun Apr 10 13:48:11 EDT 2016     blabla@morebl a.bla.net:/usr/obj/usr/src/sys/GENERIC  amd64 freebsd-version -ku From owner-freebsd-security@freebsd.org Fri Apr 29 13:58:28 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77A59B1F0CD for ; Fri, 29 Apr 2016 13:58:28 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E5851693 for ; Fri, 29 Apr 2016 13:58:28 +0000 (UTC) (envelope-from marquis@roble.com) Date: Fri, 29 Apr 2016 06:58:22 -0700 (PDT) From: Roger Marquis To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp In-Reply-To: <1461929003.67736.2.camel@yandex.com> References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 13:58:28 -0000 Despite the risk of beating a dead horse (apologies to non-native english speakers for the acronym), as I cannot recall discussion of migrating base, and since replacing ntpd with openntpd has been standard practice in security-oriented environments for a few years now, perhaps someone on the sec team could help me with this question: What are the reasons FreeBSD has not deprecated ntpd in favor of openntpd? Roger >> > 2) To update your vulnerable system via a binary patch: >> > >> > Systems running a RELEASE version of FreeBSD on the i386 or amd64 >> > platforms can be updated via the freebsd-update(8) utility: >> > >> > # freebsd-update fetch >> > # freebsd-update install From owner-freebsd-security@freebsd.org Fri Apr 29 15:55:51 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D34E7B21586 for ; Fri, 29 Apr 2016 15:55:51 +0000 (UTC) (envelope-from xenophon@irtnog.org) Received: from mx1.irtnog.org (rrcs-24-123-13-61.central.biz.rr.com [24.123.13.61]) by mx1.freebsd.org (Postfix) with ESMTP id ACEA11D12 for ; Fri, 29 Apr 2016 15:55:50 +0000 (UTC) (envelope-from xenophon@irtnog.org) Received: from uxeprdbsdmx01.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id 3970D1C8B1A for ; Fri, 29 Apr 2016 11:47:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by uxeprdbsdmx01.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax-CVhyiQQ8Y for ; Fri, 29 Apr 2016 11:47:53 -0400 (EDT) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP for ; Fri, 29 Apr 2016 11:47:53 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 29 Apr 2016 11:47:51 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp thread-index: AdGiHzvAyY7oiv7wS/CqgChlVB+DIwACqi9g References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> From: "Matthew X. Economou" To: X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 15:55:51 -0000 Roger Marquis writes: >=20 > What are the reasons FreeBSD has not deprecated ntpd in favor of > openntpd? While I cannot speak for anyone other than myself, the two simply aren't equivalent. As a conscious design choice, OpenNTPD trades off accuracy for code simplicity. It lacks support for NTP authentication, access controls, reference clocks, multicast/broadcast operation, or any kind of monitoring/reporting. OpenNTPD is probably closer to rdate than ntpd in terms of their relative capabilities. I'd rather we keep ntpd in base as a consequence. The only change I'd suggest would be to alter the default configuration such that all unauthorized access were blocked (i.e., set "restrict default ignore" and "restrict -6 default ignore"). Best wishes, Matthew --=20 "The lyf so short, the craft so longe to lerne." From owner-freebsd-security@freebsd.org Fri Apr 29 16:36:26 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B84A5B2138B for ; Fri, 29 Apr 2016 16:36:26 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id AA82D17DE; Fri, 29 Apr 2016 16:36:26 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id F1237116C; Fri, 29 Apr 2016 16:36:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Fri, 29 Apr 2016 06:46:36 +0000 From: Glen Barber To: gabor@zahemszky.hu Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp Message-ID: <20160429064636.GN1804@FreeBSD.org> References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EmwFttYoLalE/5Ab" Content-Disposition: inline In-Reply-To: <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 16:36:26 -0000 --EmwFttYoLalE/5Ab Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2016 at 01:13:21PM +0200, gabor@zahemszky.hu wrote: > >2) To update your vulnerable system via a binary patch: > > > >Systems running a RELEASE version of FreeBSD on the i386 or amd64 > >platforms can be updated via the freebsd-update(8) utility: > > > ># freebsd-update fetch > ># freebsd-update install >=20 > Both on an i386 and on an amd64 machine, I got: >=20 > =3D=3D=3D=3D > .... > Fetching metadasa signature for 10.3-RELEASE from update5.freebsd.org... > done > Fetching metadata index.... done >=20 > The update metadata is correctly signed, but > failed an integrity check. > Cowardly refusing to proceed any further. This is being investigated within secteam@. Glen --EmwFttYoLalE/5Ab Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXIwNMAAoJEAMUWKVHj+KT1boQAKFGYzLrD0g7krTy3kPo4lP+ ywAo8gW8rC4f0mcD5n3dkhreJHcAQjguRqFz3AeIHS770aJSTF+uojm0QqdxLjlO 04DLjKFcXDMarS6EZR+2afdPoGWyPKmPsDHxX+5mNOOpMnTbQEUy8Nb6gY7knLZZ ZYekcpvy/A0nhI/SGANGg5Oq96hdEjcr9z19P+3GC6yyE/eLaAYKIFMzQFXaSd0m 72m74MW88fBOzY2SKtxNB2mBQa6fMdn2/sQNmZkZpnH5xuNcJbYCMhTQ+2dVFey4 dQOwJ4LMfyObVIl20oOlefoWHaWccZ9qjhTCm0uojviilw4wSvqwoN/mLi0vUGCZ Dqs6wci04oD7lJLLYnc52B0OxbGc2Sb0UYFX+zUWHaer10O3CLVVf6ffUKEZDxIE /yul3h/N0sS7uQySZo89LofoJB9Y2dDCAPNVGlGFeSIi42u6R5KioK8s56wcVx9h ieNRoWHQPn05/jKJhmiR8UxA0J2PY7QyLPnYwiXMtRZ4Nbz5GDwUq4Q8CYYB+X2v PxioCB++qXLRrIC2sv7h/07SCgCjINzM6dJx3cG86STCtF4766a+HKqu4+u4Is0C ePV56XOs2ddCEWUxeVI4RIU7sgjjJHxuV81xcw2P+dT2ScfctH/zJzMXrKnUIryz 060A1qFAtVisx+TmykaA =BhCA -----END PGP SIGNATURE----- --EmwFttYoLalE/5Ab-- From owner-freebsd-security@freebsd.org Fri Apr 29 23:43:17 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1411B21A39 for ; Fri, 29 Apr 2016 23:43:17 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CEC631846 for ; Fri, 29 Apr 2016 23:43:17 +0000 (UTC) (envelope-from marquis@roble.com) Date: Fri, 29 Apr 2016 16:43:16 -0700 (PDT) From: Roger Marquis To: "Matthew X. Economou" cc: freebsd-security@freebsd.org Subject: RE: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp In-Reply-To: References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 23:43:18 -0000 >> What are the reasons FreeBSD has not deprecated ntpd in favor of >> openntpd? > > While I cannot speak for anyone other than myself, the two simply aren't > equivalent. As a conscious design choice, OpenNTPD trades off accuracy > for code simplicity. IIRC openntpd is accurate down to ~100ms. Ntpd does have a lot of code dedicated to additional accuracy but this is exactly the security trade-off I want to avoid. Who needs millisecond accuracy anyway? > It lacks support for NTP authentication, This is still the case but considering the tiny fraction of ntpd sites that use encryption and the fact that encryption is not enabled by default it is not really relevant to FreeBSD. > access controls, reference clocks, multicast/broadcast operation, Several reflection vulnerabilities over the past few years have been due to holes in ntpd's access control so its hard to appreciate their value or the value of these other little used features. > or any kind of monitoring/reporting. This is no longer correct. Openntpd's 'ntpctl' reports are sufficient for the vast majority of sites. > OpenNTPD is probably closer to rdate than ntpd in terms of their relative > capabilities. Rdate? Really? This is a little over the top don't you think? > I'd rather we keep ntpd in base as a consequence. I'm sure the NSA would like it if we all did, considering the order of magnitude difference in security vulnerabilities and the fact that the daemon has to run as root. > The only change I'd suggest would be to alter the default configuration > such that all unauthorized access were blocked (i.e., set "restrict default > ignore" and "restrict -6 default ignore"). This is a good idea, perhaps, for those sites that need to run ntpd for one of the reasons listed above but again, that's a tiny fraction of the installed base. Most FreeBSD systems only need to query a timehost, not to be a time server. One of ntpd's biggest disadvantages is that its udp socket cannot be disabled i.e., it cannot be configured as just a client (though you can use ipfw or pf to that effect). Considering the demand for this feature you have to ask why ntpd hasn't been able to implement it? Roger From owner-freebsd-security@freebsd.org Sat Apr 30 00:09:21 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64921B20306 for ; Sat, 30 Apr 2016 00:09:21 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 455D2170C for ; Sat, 30 Apr 2016 00:09:20 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 96.5F.27179.9A7F3275; Fri, 29 Apr 2016 17:09:13 -0700 (PDT) X-AuditID: 11973e15-f79686d000006a2b-05-5723f7a9eeab Received: from [17.149.235.79] (Unknown_Domain [17.149.235.79]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id B5.DD.11233.9A7F3275; Fri, 29 Apr 2016 17:09:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp From: Charles Swiger In-Reply-To: <0O6F002Z65WLUS40@mr28p00im-smtpin028.me.com> Date: Fri, 29 Apr 2016 17:09:13 -0700 Cc: freebsd-security Content-Transfer-Encoding: quoted-printable Message-Id: <28698FCA-CEAB-4A0F-9F12-57FCCD871E1E@mac.com> References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> <0O6F002Z65WLUS40@mr28p00im-smtpin028.me.com> To: Roger Marquis X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FDorLvyu3K4wYp91hY9m56wWXQsdHdg 8pjxaT6Lx7H7q9kCmKK4bFJSczLLUov07RK4MhaeXM5YcEu2ovdfD0sD417xLkZODgkBE4nW A4eYIGwxiQv31rN1MXJxCAnsZZQ4s/wXO0xRw7ZXLBCJqUwSb9ufMYMkmAW0JG78ewnWzSug J7Fp/VswW1jAWmLZ0qdADRwcbAJqEhMm8oCEOQWsJP4eamYFsVkEVCUuf3nBCjHGWGJ5114W CFtbYtnC18wQI60kPjYtZoTYu4NJ4ub+f2AHiQA1955eC3W1rMSTk4vAjpMQ+MgqcXTbc6YJ jEKzkNw3C8l9s5AsWcDIvIpRKDcxM0c3M89ML7GgICdVLzk/dxMjKISn24nuYDyzyuoQowAH oxIP74x7SuFCrIllxZW5hxilOViUxHknfVMOFxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDY +XDmd6cZt/gmMTwUjJ9XaxHkK3DJ1fddv89m0cL1bHqTM69OOxcxY/KyHe/stbmPH1i8o+HL 0Tq9I2fOv52S6222s/N+XuijtIAOLTFJ0zx79v/P9G4afvM+XsbM0CfWM1HUWv7vld6PM7Yu m+roohj05bYv7/2pYVs7D9ZeMTBzXNJn8tpeiaU4I9FQi7moOBEAZGzA00ICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUiOPW1v+7K78rhBu+um1n0bHrCZtGx0N2B yWPGp/ksHsfur2YLYIrisklJzcksSy3St0vgylh4cjljwS3Zit5/PSwNjHvFuxg5OSQETCQa tr1igbDFJC7cW8/WxcjFISQwlUnibfszZpAEs4CWxI1/L5lAbF4BPYlN69+C2cIC1hLLlj4F aubgYBNQk5gwkQckzClgJfH3UDMriM0ioCpx+csLVogxxhLLu/ayQNjaEssWvmaGGGkl8bFp MSPE3h1MEjf3/2MHSYgANfeeXssEcZysxJOTi1gmMPLPQnLSLCQnzUIydwEj8ypGgaLUnMRK I73EgoKcVL3k/NxNjKCQayh03sF4bJnVIUYBDkYlHt4Z95TChVgTy4orcw8xSnAwK4nwGn9V DhfiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/4FKCWQnliSmp2aWpBaBJNl4uCUamCc9D1I5D6H pIz9+nsfZN6GTTrw7uvuX9F8039eU+Nctaspur0wht/y0bPZ8QtuyCb3HltfXnm7R0jSUzCn 98/+o0WP+jmKr77znZShr6V+50zh9oML1zDY6/zIvPPLUEv0H6uYbWzMv4SzQTMfRbbde+3J kPxba2qy3eL5ISYF1+PK04rc/TSVWIozEg21mIuKEwFVrgKuNQIAAA== X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 00:09:21 -0000 On Apr 29, 2016, at 4:43 PM, Roger Marquis wrote: >>> What are the reasons FreeBSD has not deprecated ntpd in favor of >>> openntpd? >>=20 >> While I cannot speak for anyone other than myself, the two simply = aren't >> equivalent. As a conscious design choice, OpenNTPD trades off = accuracy >> for code simplicity. >=20 > IIRC openntpd is accurate down to ~100ms. Hopefully better, since that is terrible clock accuracy. > Ntpd does have a lot of code dedicated to additional accuracy but this = is > exactly the security trade-off I want to avoid. Most of the ntpd security bugs relate to authentication, in part because = almost nobody ever used it. The timing code is more robust. > Who needs millisecond accuracy anyway? Cell phones, cell phone towers, computers handling financial = transactions, etc. >> It lacks support for NTP authentication, >=20 > This is still the case but considering the tiny fraction of ntpd sites > that use encryption and the fact that encryption is not enabled by > default it is not really relevant to FreeBSD. I'll give you this-- ntp auth is unlikely to be missed by most people. >> access controls, reference clocks, multicast/broadcast operation, >=20 > Several reflection vulnerabilities over the past few years have been = due > to holes in ntpd's access control so its hard to appreciate their = value > or the value of these other little used features. Any listening network service can be used for reflection attacks. >> or any kind of monitoring/reporting. >=20 > This is no longer correct. Openntpd's 'ntpctl' reports are sufficient > for the vast majority of sites. Surely individual sites can make up their own minds about that, right? >> OpenNTPD is probably closer to rdate than ntpd in terms of their = relative >> capabilities. >=20 > Rdate? Really? This is a little over the top don't you think? Not really. Lack of reference clocks is a big deal, and so is SNTP vs = NTP. >> I'd rather we keep ntpd in base as a consequence. >=20 > I'm sure the NSA would like it if we all did, considering the order of > magnitude difference in security vulnerabilities and the fact that the > daemon has to run as root. Most time daemons need root in order to execute adjtime() / adjtimex() / = ntp_adjtime(). Systems with a capability model might use something like CAP_SYS_TIME = instead; if present, ntpd can be run without root-- see NetBSD, Solaris, and some = Linux flavors. >> The only change I'd suggest would be to alter the default = configuration >> such that all unauthorized access were blocked (i.e., set "restrict = default >> ignore" and "restrict -6 default ignore"). >=20 > This is a good idea, perhaps, for those sites that need to run ntpd = for > one of the reasons listed above but again, that's a tiny fraction of = the > installed base. Most FreeBSD systems only need to query a timehost, = not > to be a time server. Your data for that? > One of ntpd's biggest disadvantages is that its udp socket cannot be > disabled i.e., it cannot be configured as just a client (though you = can > use ipfw or pf to that effect). Considering the demand for this = feature > you have to ask why ntpd hasn't been able to implement it? It's not possible to perform NTP timestamp exchange properly without = both sides listening because you want to determine both the round-trip delay and = the clock offset. openntpd implements SNTPv4 and not the NTPv4 protocol. The extra sanity = checking in the latter helps detect and mitigate against falsetickers, which is = why folks continue to use NTP and ntpd rather than rdate or SNTP implementations = like openntpd. Regards, --=20 -Chuck From owner-freebsd-security@freebsd.org Sat Apr 30 00:26:00 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C02E9B2092B for ; Sat, 30 Apr 2016 00:26:00 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B09112AE for ; Sat, 30 Apr 2016 00:26:00 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: by mail-ig0-x22a.google.com with SMTP id m9so33722117ige.1 for ; Fri, 29 Apr 2016 17:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xo7Z95QrLLkCNx9P/WRn2snVgXLSjegks4XZhYRzk9E=; b=OQj2SUDSSNgaXRlC7dGwQGOYSqfo3+Hc7vIVeJad+pA+Q5PcTBvOlbEy7yxdgAU+sW 1oNWHjqDroM+KRX/+zHwZiKpUal/6PmLlqc0ILMqKAIzIy18vrgGvJIMT5euP3SpyolM owpn5UkyASxIVD5nrb73TgbPKqqL5rp4OEhjeJDNDhiGmrhlk1bB4WZyMK1AubrgdZVp xZ7Xr3kuG5AHsqTKnmf4MUoimXkl/lkftGiWBmUic+TvEQ4cOrkBZPrnB3LGAoir7Vck tqc25ASTb0R83x+M8w82U4y+8vvbS49kkhCX70QtM5CiF3JFkN9kWHlMH1w5XMVVbgDq vL6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xo7Z95QrLLkCNx9P/WRn2snVgXLSjegks4XZhYRzk9E=; b=UH2e3vMzxR15aOnaSa4Z9Q6GE9j3qBfMs/OvnQ/nRoIOrqpvpGskGvjLGAw/pRtgM7 eJ5cDPDZ2cg9mUr0J7ASUho3wxb7afZoTjxgz8Ioi1GfU1stI8LLBZIjaUSWtFMOqXVs fkTndJ+vXMMxe3iAStGQgcD9fW5si7SUqF8NhLxumHNX4NBixQd6nXRXkeqWuAS8D14n KSrku9XNvsZ+7/gzQPeDU/WY7Dmbh7QvfMntYwWJ9Jhgb+qlX17OW65ch68HTq6XxWHN ThFC/5EXbvTdLfMuEBpTzOtSe0weNQ4oWuHrea/EG2f0hfHOa8KLmgyoP2+yB4D7qBUK Vn0g== X-Gm-Message-State: AOPr4FUm/o0i8oYji5I4S7vQwc033Z0SK92Hs8fTx+aY2HlWRRu3KOzgtGBJuWYVo98/JFG4ruep5i8JE7sTBQ== MIME-Version: 1.0 X-Received: by 10.50.220.137 with SMTP id pw9mr8017362igc.65.1461975960028; Fri, 29 Apr 2016 17:26:00 -0700 (PDT) Received: by 10.107.142.21 with HTTP; Fri, 29 Apr 2016 17:25:59 -0700 (PDT) Received: by 10.107.142.21 with HTTP; Fri, 29 Apr 2016 17:25:59 -0700 (PDT) In-Reply-To: <28698FCA-CEAB-4A0F-9F12-57FCCD871E1E@mac.com> References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> <0O6F002Z65WLUS40@mr28p00im-smtpin028.me.com> <28698FCA-CEAB-4A0F-9F12-57FCCD871E1E@mac.com> Date: Fri, 29 Apr 2016 17:25:59 -0700 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp From: jungle Boogie To: Charles Swiger Cc: Roger Marquis , freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 00:26:00 -0000 Sent from my iPhone 7.1 On Apr 29, 2016 5:09 PM, "Charles Swiger" wrote: > > On Apr 29, 2016, at 4:43 PM, Roger Marquis wrote: > > > Who needs millisecond accuracy anyway? > > Cell phones, cell phone towers, computers handling financial transactions, etc. > And these use cases actually use FreeBSD's generic kernel? From owner-freebsd-security@freebsd.org Sat Apr 30 00:44:29 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6188FB21134 for ; Sat, 30 Apr 2016 00:44:29 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 552FD1678 for ; Sat, 30 Apr 2016 00:44:28 +0000 (UTC) (envelope-from marquis@roble.com) Date: Fri, 29 Apr 2016 17:44:28 -0700 (PDT) From: Roger Marquis To: Charles Swiger cc: freebsd-security Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp In-Reply-To: <28698FCA-CEAB-4A0F-9F12-57FCCD871E1E@mac.com> References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> <0O6F002Z65WLUS40@mr28p00im-smtpin028.me.com> <28698FCA-CEAB-4A0F-9F12-57FCCD871E1E@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 00:44:29 -0000 >> Who needs millisecond accuracy anyway? > >Cell phones, cell phone towers, computers handling financial transactions, etc. I manage security for several dozen FreeBSD computers handling financial transactions and they all run openntpd in client-only mode. It was the only way we could avoid an absolute deluge of security incident tickets from corp scanning (mainly Nessus). These hosts, as well as cell phone towers, etc may be reasons for keeping isc ntpd as a port but do not support a case for keeping it in base. >> perhaps, for those sites that need to run ntpd for one of the reasons >> listed above but again, that's a tiny fraction of the installed base. Most >> FreeBSD systems only need to query a timehost, not to be a time server. > > Your data for that? Are you seriously proposing that most FreeBSD installations need to serve as timeservers? > openntpd implements SNTPv4 and not the NTPv4 protocol. The extra sanity checking > in the latter helps detect and mitigate against falsetickers, which is why folks > continue to use NTP and ntpd rather than rdate or SNTP implementations like openntpd. And your data for that? I'd personally be surprised if most devops were familiar with the differences between SNTPv4 and NTPv4. OTOH openntpd's ntpd.conf does provide a "constraints from" directive which will query one or more http/https sites and use the resulting timestamps to reject ntp responses outside of a range near the constraint. This is a nice OOB feature not found in base ntpd. Roger From owner-freebsd-security@freebsd.org Sat Apr 30 06:03:36 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35ACCAD9024 for ; Sat, 30 Apr 2016 06:03:36 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C29E9119F for ; Sat, 30 Apr 2016 06:03:35 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id u3U5v39O038702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 30 Apr 2016 07:57:04 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: marquis@roble.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id u3U5uxav023810 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Apr 2016 12:56:59 +0700 (KRAT) (envelope-from eugen@grosbein.net) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp To: Roger Marquis , Charles Swiger References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> <0O6F002Z65WLUS40@mr28p00im-smtpin028.me.com> <28698FCA-CEAB-4A0F-9F12-57FCCD871E1E@mac.com> <201604300045.u3U0icQk037159@hz.grosbein.net> Cc: freebsd-security From: Eugene Grosbein Message-ID: <57244926.9000907@grosbein.net> Date: Sat, 30 Apr 2016 12:56:54 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201604300045.u3U0icQk037159@hz.grosbein.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 06:03:36 -0000 30.04.2016 7:44, Roger Marquis пишет: > Are you seriously proposing that most FreeBSD installations need to > serve as timeservers? Absolutely. Every LAN router should be capable in supplying NTP service for its LAN clients, it just needs a way to differentiate its LAN/WAN interfaces (security zones) to prevent abuse from outer interfaces. From owner-freebsd-security@freebsd.org Sat Apr 30 11:30:17 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B50DFAEE4DD for ; Sat, 30 Apr 2016 11:30:17 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (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 4CA4610AB for ; Sat, 30 Apr 2016 11:30:16 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5B227762.dip0.t-ipconnect.de [91.34.119.98]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id u3UBSfAL012753; Sat, 30 Apr 2016 13:28:41 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id u3UBU89c010446; Sat, 30 Apr 2016 13:30:08 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id u3UBTjWL055247; Sat, 30 Apr 2016 13:29:57 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201604301129.u3UBTjWL055247@fire.js.berklix.net> To: Roger Marquis cc: "Matthew X. Economou" , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-URL: http://www.berklix.eu In-reply-to: Your message "Fri, 29 Apr 2016 16:43:16 -0700." <201604292342.u3TNg4uU007758@slim.berklix.org> Date: Sat, 30 Apr 2016 13:29:45 +0200 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 11:30:17 -0000 Roger Marquis wrote: > >> What are the reasons FreeBSD has not deprecated ntpd in favor of > >> openntpd? > > > > While I cannot speak for anyone other than myself, the two simply aren't > > equivalent. As a conscious design choice, OpenNTPD trades off accuracy > > for code simplicity. > > IIRC openntpd is accurate down to ~100ms. Ntpd does have a lot of > code dedicated to additional accuracy but this is exactly the security > trade-off I want to avoid. Who needs millisecond accuracy anyway? AMD + NFS makes on a LAN. 1/10 second seems insufficient. ( Though one could run a faster less secure NTP on a local LAN behind a firewall, & a slower more secure NTP on a WAN, (so a FreeBSD gate would need both NTPs ) ). Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich http://berklix.eu/jhs/ Mail plain text, No quoted-printable, HTML, base64, MS.doc. Prefix old lines '> ' Reply below old, like play script. Break lines by 80. Let Brits in EU vote on Brexit https://petition.parliament.uk/petitions/112142 Lie to companies extorting personal data: Prevent abuse, loss & ID theft. From owner-freebsd-security@freebsd.org Sat Apr 30 13:45:09 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91241B1F8C5 for ; Sat, 30 Apr 2016 13:45:09 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mail.inka.de (quechua.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C3641942 for ; Sat, 30 Apr 2016 13:45:09 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mips.inka.de (news@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1awVCk-0002w9-0F; Sat, 30 Apr 2016 15:45:06 +0200 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.15.2/8.15.2) with ESMTP id u3UDhYbm074089 for ; Sat, 30 Apr 2016 15:43:34 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.15.2/8.15.2/Submit) id u3UDhYPj074088 for freebsd-security@freebsd.org; Sat, 30 Apr 2016 15:43:34 +0200 (CEST) (envelope-from news) To: freebsd-security@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.security Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp Date: Sat, 30 Apr 2016 13:43:34 +0000 (UTC) Message-ID: References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> User-Agent: slrn/1.0.2 (FreeBSD) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 13:45:09 -0000 On 2016-04-29, "Matthew X. Economou" wrote: >> What are the reasons FreeBSD has not deprecated ntpd in favor of >> openntpd? > > While I cannot speak for anyone other than myself, the two simply aren't > equivalent. OpenNTPD is intended to cover the most common usage scenarios. The single most common use of NTP is a client that simply gets the time from a server or set of servers. The second most common use is a server that fetches the time from other servers and redistributes it to a bunch of clients. These two scenarios cover what, 99% of all ntpd users? (OpenNTPD also has support for reference clocks, but that code uses OpenBSD's sensor framework and is not portable.) > As a conscious design choice, OpenNTPD trades off accuracy > for code simplicity. There has been no such design choice. OpenNTPD is simply accurate enough in practice that the matter hasn't really come up. Accuracy is a complete red herring if you are getting your time from the Internet, where packet jitter is a few milliseconds anyway. > It lacks support for NTP authentication, access controls, > reference clocks, multicast/broadcast operation, or any kind of > monitoring/reporting. Only a tiny fraction of NTP users will use any of that. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-security@freebsd.org Sat Apr 30 13:55:06 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A5A2B1FD4C for ; Sat, 30 Apr 2016 13:55:06 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mail.inka.de (quechua.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45BB21F7B for ; Sat, 30 Apr 2016 13:55:06 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mips.inka.de (news@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1awVMO-00037n-Ro; Sat, 30 Apr 2016 15:55:04 +0200 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.15.2/8.15.2) with ESMTP id u3UDqLc2074281 for ; Sat, 30 Apr 2016 15:52:21 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.15.2/8.15.2/Submit) id u3UDqLTd074280 for freebsd-security@freebsd.org; Sat, 30 Apr 2016 15:52:21 +0200 (CEST) (envelope-from news) To: freebsd-security@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.security Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp Date: Sat, 30 Apr 2016 13:52:21 +0000 (UTC) Message-ID: References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> <201604300015.u3U0FB3k058050@lorvorc.mips.inka.de> User-Agent: slrn/1.0.2 (FreeBSD) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 13:55:06 -0000 On 2016-04-29, Roger Marquis wrote: >> While I cannot speak for anyone other than myself, the two simply aren't >> equivalent. As a conscious design choice, OpenNTPD trades off accuracy >> for code simplicity. > > IIRC openntpd is accurate down to ~100ms. I have no idea where you get that absurd number from. OpenNTPD is accurate at least down to 1 ms. I don't have better time sources. $ ntpctl -sa 1/1 peers valid, clock synced, stratum 2 peer wt tl st next poll offset delay jitter 2001:6f8:124a::8 ntp * 1 10 1 250s 1506s -0.193ms 0.493ms 0.067ms -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-security@freebsd.org Sat Apr 30 14:27:28 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19968B222FA for ; Sat, 30 Apr 2016 14:27:28 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D6DE91D3B for ; Sat, 30 Apr 2016 14:27:26 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id A87194F57A; Sat, 30 Apr 2016 14:27:19 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u3UERHcB046859; Sat, 30 Apr 2016 14:27:17 GMT (envelope-from phk@phk.freebsd.dk) To: Christian Weisgerber cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp In-reply-to: From: "Poul-Henning Kamp" References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> <201604300015.u3U0FB3k058050@lorvorc.mips.inka.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46857.1462026437.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Apr 2016 14:27:17 +0000 Message-ID: <46858.1462026437@critter.freebsd.dk> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 14:27:28 -0000 -------- In message , Christian Weisger= ber w rites: >On 2016-04-29, Roger Marquis wrote: > >>> While I cannot speak for anyone other than myself, the two simply aren= 't >>> equivalent. As a conscious design choice, OpenNTPD trades off accurac= y >>> for code simplicity. >> >> IIRC openntpd is accurate down to ~100ms. > >I have no idea where you get that absurd number from. OpenNTPD is >accurate at least down to 1 ms. I don't have better time sources. Uhm.... So I hate to be pedantic, but "accurate to 1msec" means: Clock is UTC+/- 1msec = The "accuracy" you claim, and the numbers you report to back it up means: Clock is within 1 msec of half the filtered RTT the chosen peer. By pure chance your clock might be accurate to 1msec, but you have no way of knowing from the numbers you report, and it is virtually impossible to prove without a GPS or similar non-network time source. If the numbers you report always look like that, it would be correct to claim that it "can track to within 1msec". But don't worry: Accuracy is not the important part of timekeeping anyway. Stability is far more valuable than accuracy, because you can compensate inaccuracy with any desired precision, but there is only the genuine article when it comes to stability. If your peer-offset is always less than a millisecond, chances are good that you are yanking your clock around to track changes in network delay which ruins both stability and accuracy. The best explanation of all this is John R. Vig's Quartz Tutorial which is freely available on the web - highly recommended: http://www.am1.us/Local_Papers/U11625%20VIG-TUTORIAL.pdf Poul-Henning -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-security@freebsd.org Sat Apr 30 16:34:58 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F40FDB1F376 for ; Sat, 30 Apr 2016 16:34:57 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E9F2F1A1D for ; Sat, 30 Apr 2016 16:34:57 +0000 (UTC) (envelope-from marquis@roble.com) Date: Sat, 30 Apr 2016 09:34:50 -0700 (PDT) From: Roger Marquis To: "Julian H. Stacey" cc: freebsd-security@freebsd.org, "Matthew X. Economou" Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp In-Reply-To: <201604301129.u3UBTjWL055247@fire.js.berklix.net> References: <201604301129.u3UBTjWL055247@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 16:34:58 -0000 Large builds over NFS filesystems, particularly secure NFS (i.e., Kerberos) are one the best tests of time synchronization. Clients with bad clocks can further exercise this not uncommon infrastructure. The reason you don't typically see build errors even here, IME, is because the timehosts tend to be shared by and local to both client and server. Roger Julian Stacey wrote: > AMD + NFS makes on a LAN. 1/10 second seems insufficient. > ( Though one could run a faster less secure NTP on a local LAN > behind a firewall, & a slower more secure NTP on a WAN, > (so a FreeBSD gate would need both NTPs ) ).