linux-kernel - Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55E838E6.8060205@gmail.com>
Date:	Thu, 3 Sep 2015 08:11:18 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Stas Sergeev <stsp@...t.ru>, Andy Lutomirski <luto@...capital.net>
Cc:	Josh Boyer <jwboyer@...oraproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Andrew Bird (Sphere Systems)" <ajb@...eresystems.co.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Kees Cook <keescook@...omium.org>,
	Brian Gerst <brgerst@...il.com>
Subject: Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and
 default it to 'n')

On 2015-09-02 17:53, Stas Sergeev wrote:
> 03.09.2015 00:40, Andy Lutomirski пишет:
>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@...t.ru> wrote:
>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>
>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@...t.ru> wrote:
>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@...t.ru> wrote:
>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>> <luto@...capital.net>
>>>>>>>> wrote:
>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>> adding
>>>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>>>> what do you think?
>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>> enable it instead?  While dosemu might still be in use, it isn't
>>>>>>>> going
>>>>>>>> to be the common case at all.  So from a distro perspective, I
>>>>>>>> think
>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>> match the ones of fedora?
>>>>>> I didn't say that.
>>>>> What you said was:
>>>>> ---
>>>>>
>>>>> While dosemu might still be in use, it isn't going
>>>>> to be the common case at all.  So from a distro perspective
>>>>>
>>>>> ---
>>>>> ... which is likely true only in fedora circe.
>>>>>
>>>>>>      The default right now is N.
>>>>> In a not yet released kernel, unless I am mistaken.
>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>
>>>>>>      I asked it be left
>>>>>> that way.  That's all.
>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>> Its easy to get back if its not too late.
>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>>>> could set it to N.
>>> Sorry, I don't understand this sysctl proposal.
>>> Could you please educate me what is it all about?
>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>> right? What does it give us? If you disable something in the
>>> config, this gives you, say, smaller kernel image. If OTOH you
>>> add the run-time switch, it gives you a bigger image, regardless
>>> of its default value.
>>> I might be missing something, but I don't understand what
>>> problem will this solve? Have I missed some earlier message
>>> in this thread?
>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>> target vm86 from attacking their kernel.
> I don't think the attack scenario was satisfactory explained.
> IIRC you only said that
> ---
>
> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
> on arbitrary mappings behind the vm's back.
>
> ---
> Just go ahead and remove mark_screen_rdonly, big deal.
> Is this all of the threat?
> Or do we treat _every_ syscall as the potential attack target?
Anything that messes with the VM subsystem (doubly if it does so without 
actually calling into the VM subsystem) is a potential target, as is 
anything that messes with execution mode or privilege level (as in, 
possibly messes with which ring (or whatevere equivalent metaphor other 
processors use) execution is happening in).  This does potentially all 
three (depending on how it's called).  Just because there are no known 
working exploits doesn't mean it's not possible, and in the case of this 
code, I'd say there is almost certainly some way to exploit it either to 
crash the system or gain root-equivalent privileges.



Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)