From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933499AbbIDTwU (ORCPT ); Fri, 4 Sep 2015 15:52:20 -0400 Received: from mail-ig0-f179.google.com ([209.85.213.179]:37155 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933410AbbIDTwS (ORCPT ); Fri, 4 Sep 2015 15:52:18 -0400 Subject: Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') To: Stas Sergeev References: <55E6C36F.6080309@list.ru> <55E736E9.2000201@list.ru> <55E7607B.4070800@list.ru> <55E7663B.30402@list.ru> <55E76FCB.7090304@list.ru> <55E838E6.8060205@gmail.com> <55E839C7.8010501@list.ru> <55E86AF7.3090200@gmail.com> <55E8767A.7000408@list.ru> <55E896C7.1010500@gmail.com> <55E8BB64.3020906@list.ru> <20150904060933.229b5b06@as> <55E9767B.2020501@list.ru> <55E98FD7.8020809@gmail.com> <55E99752.3090107@list.ru> Cc: Chuck Ebbert , Andy Lutomirski , Josh Boyer , linux-kernel@vger.kernel.org, "Andrew Bird (Sphere Systems)" , Linus Torvalds , Ingo Molnar , Kees Cook , Brian Gerst From: Austin S Hemmelgarn Message-ID: <55E9F65F.7070300@gmail.com> Date: Fri, 4 Sep 2015 15:51:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E99752.3090107@list.ru> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090806060906030203030203" X-Antivirus: avast! (VPS 150904-2, 2015-09-04), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a cryptographically signed message in MIME format. --------------ms090806060906030203030203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-04 09:06, Stas Sergeev wrote: > 04.09.2015 15:34, Austin S Hemmelgarn =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> On 2015-09-04 06:46, Stas Sergeev wrote: >>> 04.09.2015 13:09, Chuck Ebbert =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>>> On Fri, 4 Sep 2015 00:28:04 +0300 >>>> Stas Sergeev wrote: >>>> >>>>> 03.09.2015 21:51, Austin S Hemmelgarn =D0=BF=D0=B8=D1=88=D0=B5=D1=82= : >>>>>> There are servers out there that have this enabled and _never_ use= it >>>>>> at all, >>>>> Unless I am mistaken, servers usually use special flavour of the >>>>> distro (different from desktop install), where of course this will >>>>> be disabled _compile time_. >>>> Many (most?) distros use just one kernel for everything, because it'= s >>>> just too much work to have a separate flavor for servers. >>> But for example menuconfig promotes CONFIG_PREEMPT_NONE for server >>> and CONFIG_PREEMPT for desktop. Also perhaps server would need an >>> lts version rather than latest. >>> I wonder if RHEL Server offers the generic desktop-suited kernel >>> with vm86() enabled? >>> >>> In any case, if there is some generic mechanism to selectively >>> disable syscalls at run-time for server, then vm86() is of course >>> a good candidate. I wonder how many other syscalls are currently >>> run-time controlled? (those that are not marked as an "attack surface= " >>> and defaulted to Y; I suppose the "attack surface" is currently only = vm86()) >>> >> OK, I think I need to clarify something here. >> >> The attack surface of a given system refers to the number of different= ways that someone could potentially attack that system. An individual s= yscall is not in itself an attack surface, but is part of >> the attack surface for the whole system. One of the core concepts of = proactive security is to minimize the attack surface, because the fewer w= ays someone could possibly attack you, the less likely it >> is that they will succeed. >> >> I however, referred to vm86 as a potential attack vector, which refers= one way in which someone could attempt to attack the system (be it throu= gh arbitrary code execution , privilege escalation, or >> some other type of exploit), note that something does not need to have= a known exploit to be classified as a potential attack vector (most blac= k hat's out there will keep quiet about discovered >> exploits until they can actually make use of them themselves). By the= ir very definition, every single site that userspace can call into the ke= rnel is a _potential_ attack vector, including vm86(). > But they are not marked as such, while vm86() is. > And they do not have a run-time disabling knob. > So why is such a big difference? Take for example read(), this is not a very likely attack vector because:= 1. It does exactly _one_ thing. 2. It only copies data to the calling process. 3. It has no odd interactions with mm. 4. The only modification it does to how the processor is executing is=20 for the context switch to kernel mode and back to user mode. 5. It is _very_ well audited. Overall, this means that read() is a relatively low risk. fork() is slightly more attractive as an exploit target, because it=20 doesn't fit points 2 and 4 above. vm86() is much more attractive because it doesn't fit any of the 5=20 points above. Other system calls that I know of that fit less than 3 of = the 5 points above are: modify_ldt(), perf_event_open(), ptrace(), and=20 bpf(). I regard all of these as potentially more attractive than vm86=20 because they are available on a wider range of platforms. modify_ldt,=20 perf_event_open, and ptrace all have ways to disable or significantly=20 secure them, and have also all had exploits at some point in time. bpf=20 is able to be disabled, but has not yet had any publicly documented=20 exploits that I know of, but this does not mean that it is secure=20 (especially considering how new it is). > >> vm86() is one of the more attractive syscalls to attempt to use as an = attack vector on 32-bit x86 systems because it's relatively unaudited, > This can be changed if it is at least stripped from the known > bloat, for example. This could have been done _before_ taking any > other actions on it, because the actions would then be entirely > different. Maybe, if it is properly cleaned up, the action will > change from disabling or introducing a knob to auditing it? If you clean it up, I'd be happy to throw every thing I can think of at=20 it. Even if I don't manage to discover any exploits in that case, I=20 would still advocate against having it availible by default because it's = functionality that is used by an consistently decreasing percentage of=20 users (yes, I know lots of people use dosemu, the number of people who=20 use Linux is however going up faster than the number of people who use=20 dosemu (no, I don't have numbers to back this up, but it is=20 statistically very likely to be the case), and I know a number of people = who used to use it (myself included) who are moving to dosbox because=20 the performance difference is getting less significant as computers get=20 faster). >> significantly modifies the execution state of the >> processor, and is available on a majority of 32-bit x85 systems in the= wild. This does not mean that it is exploitable directly, just that it'= s a possible target for an exploit. > So you say it is more dangerous than other syscalls, and I can > believe you, but this needs a proper justification. Someone have > to write why exactly it is more dangerous, can it be fixed or not, > etc. Like it was done for mark_screen_rdonly - I am not asking you > how it can be exploited because I take your word that this code is > a potential risk. But it can be removed. If there are other risky > parts, they also have to be identified. I simply don't think the > sufficient justification was spelled to consider it as more dangerous > than all other syscalls (modulo mmap_min_addr - that one was identified= ). I've already stated _why_ it's more dangerous: 1. It interacts in odd ways with memory management. 2. It directly modifies the execution state of the processor. It is no more potentially dangerous than any other system call that fits = either description, I'm not trying to single out vm86, that just happens = to be the syscall we are discussing right now. Another syscall that is=20 a perfect example of both 1 and 2 would be modify_ldt, which _does_ have = known exploits that required a rewrite, and now has a knob to disable it = because most people don't use it. On almost any other OS out there,=20 anything that did either 1 or 2 wouldn't have been merged in the first=20 place (this is not intended as a statement against Linux), and to be=20 honest, if someone tried to merge vm86 into Linux today, they would have = a very hard time convincing people it is worth it. Reiterating what I've said before, albeit paraphrased: 1. If you can call code, there is a possibility that you can exploit it. 2. Just because there are no publicly documented exploits for something=20 does not mean that it is secure. 3. Having functionality enabled by default that you don't need is a Very = Bad Thing, this is why Windows has historically had so many security issu= es. 4. Reactive security is utterly useless for any system that has already=20 been exploited. If you have been hacked by someone who actually knows=20 what they are doing, then even your hardware is suspect at that point,=20 and patching the initial entry point will not provide any reasonable=20 degree of safety. Also, this will be the last reply I make on this sub-thread, if this=20 does not convince you of any of the points I've made, then nothing I can = say is likely to. --------------ms090806060906030203030203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Brgwgga0MIIEnKADAgECAgMQblUwDQYJKoZIhvcNAQENBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MTUwMzI1MTkzNDM4WhcNMTUwOTIxMTkzNDM4WjBjMRgwFgYDVQQDEw9DQWNlcnQgV29UIFVz ZXIxIzAhBgkqhkiG9w0BCQEWFGFoZmVycm9pbjdAZ21haWwuY29tMSIwIAYJKoZIhvcNAQkB FhNhaGVtbWVsZ0BvaGlvZ3QuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA nQ/81tq0QBQi5w316VsVNfjg6kVVIMx760TuwA1MUaNQgQ3NyUl+UyFtjhpkNwwChjgAqfGd LIMTHAdObcwGfzO5uI2o1a8MHVQna8FRsU3QGouysIOGQlX8jFYXMKPEdnlt0GoQcd+BtESr pivbGWUEkPs1CwM6WOrs+09bAJP3qzKIr0VxervFrzrC5Dg9Rf18r9WXHElBuWHg4GYHNJ2V Ab8iKc10h44FnqxZK8RDN8ts/xX93i9bIBmHnFfyNRfiOUtNVeynJbf6kVtdHP+CRBkXCNRZ qyQT7gbTGD24P92PS2UTmDfplSBcWcTn65o3xWfesbf02jF6PL3BCrVnDRI4RgYxG3zFBJuG qvMoEODLhHKSXPAyQhwZINigZNdw5G1NqjXqUw+lIqdQvoPijK9J3eijiakh9u2bjWOMaleI SMRR6XsdM2O5qun1dqOrCgRkM0XSNtBQ2JjY7CycIx+qifJWsRaYWZz0aQU4ZrtAI7gVhO9h pyNaAGjvm7PdjEBiXq57e4QcgpwzvNlv8pG1c/hnt0msfDWNJtl3b6elhQ2Pz4w/QnWifZ8E BrFEmjeeJa2dqjE3giPVWrsH+lOvQQONsYJOuVb8b0zao4vrWeGmW2q2e3pdv0Axzm/60cJQ haZUv8+JdX9ZzqxOm5w5eUQSclt84u+D+hsCAwEAAaOCAVkwggFVMAwGA1UdEwEB/wQCMAAw VgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBo ZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNV HSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCG SAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2Vy dC5vcmcwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5j cmwwNAYDVR0RBC0wK4EUYWhmZXJyb2luN0BnbWFpbC5jb22BE2FoZW1tZWxnQG9oaW9ndC5j b20wDQYJKoZIhvcNAQENBQADggIBABr5e8W+NiTER+Q/7wiA2LxWN3UdhT3eZJjqqSlP370P KL5iWqeTfxQ67Ai/mHbJcT2PgAJ+/D2Ji+aRR03UWnU/vtOwzyDLUMstqnfl0Zs+sz/CJe7x nBA5jlpjC2DKuMVfbPze7eySaen7XSGFHKE1QoVIIpQ2kVjC4nbbJQnUbAVX1Iz29WxeVGt9 XYigz3tDPf3tglN+q23E7YjQl4abTIoM7i98yV1H9gfY8lFfKZ6jREB9+n6ie2EwS3Kat2mG tl2wBx4MfRnoSQSKsLKQ5oTwhWf0JqlFwpLfl374p0Njcykej9/jnWG8Ks1V/AXTHqI4eyIP Mf5yMZkPv7n7LS9WWKdG4Nd38iv4T2EiAaWsmgu+r81qL5CJu9AyA0SBS4ttKf6k3e63w2Mv N9R45vpQ3QhAhfWyFxFhZN95APe3YECDG3+XIRJpRYPEtHuIsOyzI70ajF93gg/BidvqKsmV MM2ccktDMfqwZXea6zey7F8Geu9R7BqjXmG2HlNuXu7e/xnHOgXf5D3wPmnRLlBhXL1Ch97a w2KjaupjpAHfFjv5kGnZXN87UvvlwzIZiKXwa3vTDwK+rrKn/sHPkfDZPSiyt/ZBIK6lX83P 34H/CzGg+Kx57rHYOIHGumIvpDa5vfWp8O0sGgawb1C2Aae4sTUVIWmIjVuGI062MYIE0TCC BM0CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxBuVTANBglghkgBZQMEAgMFAKCCAiEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwOTA0MTk1MTU5WjBPBgkq hkiG9w0BCQQxQgRAJKR4vcK4DRLIaTLC+wXB2ypM0g2aURESNLhKh48i+AipuaBLRgOfjrHL eVi9JSqUoPuZOILnXL7A/xl+Frc34jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UE ChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcCAxBuVTCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEe MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxBuVTAN BgkqhkiG9w0BAQEFAASCAgBT4o27C8sa7Y2DEN29UFrLNy9sRNISFFHbNloCGZqXcEaZUjwW vuqyxN3jJ9YXr2EymvxQ1U/7CX5sMzZjNqSoAqsX1z9H9s1QP+ohCHal/0Op6b648/rOB4aj dySTV4Zsw3HkJQuVbxwCxPYaTen1QWgmbTrLZ0/MGJhs98FoeNTujNLOYqI9nOZYQPKSOrjK rFr+3xBMplRUqF5cf9gzIYqgS1ZmxozKpTDZmixEk/gvGdHI6W6AgrcQHARiFSW9XthQQn2k lMr2v9mE8JUGoE0EYU/9BnTVCdT2mcYnmEcuR+ZMMQ9HMFc8tuhuB6Y3QjifxbfXazFGw+oB l67CLKAoDlIEanY63oCJj48GC19zPh6ryx6xradUTZetUPU5QgSk4TFN/S7csCLbzpF13DRt Ax1IIPzJgbYQ5ki3CJEVzUpdHuIarQhq72MIY4VqzjdtxRImSxCzANzMrbLN3wG4OMoDsIh0 KBJM7uJWNfr5pjPCGC2MDpsob1v3j47WiHG2qJiu4/VWFF6U4YPg/qrRY7BRVssgWXqQU7yG kVMXmTQxEiqbXbbgCZJofTIsZQsYQT2bSbS9W+XuPefgGYRi4VG4zGn9qndehe2luuBvUm63 C5IpDOH4rK9TPKWvhCAs7HJJxidlsLg1RjkDo4zIv+ttef8sXab+ElZsgQAAAAAAAA== --------------ms090806060906030203030203--