Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1192396 > unrolled thread

Re: [PATCH 4/3] x86/ldt: allow to disable modify_ldt at runtime

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/3] x86/ldt: allow to disable modify_ldt at runtime Andy Lutomirski <luto@amacapital.net> - 2015-07-25 18:10 +0200
    Re: [PATCH 4/3] x86/ldt: allow to disable modify_ldt at runtime Willy Tarreau <w@1wt.eu> - 2015-07-25 18:40 +0200
      Re: [PATCH 4/3] x86/ldt: allow to disable modify_ldt at runtime Andy Lutomirski <luto@amacapital.net> - 2015-07-25 19:50 +0200
        Re: [PATCH 4/3] x86/ldt: allow to disable modify_ldt at runtime Willy Tarreau <w@1wt.eu> - 2015-07-25 20:50 +0200

#1192396 — Re: [PATCH 4/3] x86/ldt: allow to disable modify_ldt at runtime

On Sat, Jul 25, 2015 at 6:03 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Sat, Jul 25, 2015 at 09:50:52AM +0200, Willy Tarreau wrote:
>> On Fri, Jul 24, 2015 at 11:44:52PM -0700, Andy Lutomirski wrote:
>> > I'm all for it, but I think it should be hard-disablable in config,
>> > too, for the -tiny people.
>>
>> I totally agree.
>>
>> > If we add a runtime disable, let's do a
>> > separate patch, and you and Kees can fight over how general it should
>> > be.
>>
>> Initially I was thinking about changing it for a 3-state option but
>> that would prevent X86_16BIT from being hard-disablable, so I'll do
>> something completely separate.
>
> So here comes the proposed patch. It adds a default setting for the
> sysctl when the option is not hard-disabled (eg: distros not wanting
> to take risks with legacy apps). It suggests to leave the option off.
> In case a syscall is blocked, a printk_ratelimited() is called with
> relevant info (program name, pid, uid) so that the admin can decide
> whether it's a legitimate call or not. Eg:
>
>   Denied a call to modify_ldt() from a.out[1736] (uid: 100). Adjust sysctl if this was not an exploit attempt.
>
> I personally think it completes well your series, hence the 4/3 numbering.
> Feel free to adopt it if you cycle another round and if you're OK with it
> of course.
>

There's one thing that I think is incomplete here.  Currently, espfix
triggers if SS points to the LDT.  It's possible for SS to point to
the LDT even with modify_ldt disabled, and there's a decent amount of
attack surface there.

Can we improve this?  Two ideas:

1. In the asm, patch out or otherwise disable espfix if that sysctl
has never been set.  (Ick.)

2. When modify_ldt is runtime-disabled (or compile-time disabled,
perhaps), disallow setting the LDT bit in SS in the handful of places
that would allow it (ptrace and sigreturn off the top of my head).  We
don't need to worry about (regs->ss & 4) being set on kernel entry
because we'll never be in user mode with that bit set if the LDT is
disabled, but that bit could still be set using kernel APIs.  (In
fact, my sigreturn test does exactly that.)

Hmm.  With synchronous LDT, we could plausibly check at runtime in the
espfix code, too.  We used to use LAR to do this, but hpa removed it
when he realized that it was racy.  It shouldn't be racy any more,
because, with my patches applied, the LDT never changes while
interrupts are off.

--Andy
--
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/

[toc] | [next] | [standalone]

#1192404

On Sat, Jul 25, 2015 at 09:08:39AM -0700, Andy Lutomirski wrote:
> There's one thing that I think is incomplete here.  Currently, espfix
> triggers if SS points to the LDT.  It's possible for SS to point to
> the LDT even with modify_ldt disabled, and there's a decent amount of
> attack surface there.
> 
> Can we improve this?  Two ideas:
> 
> 1. In the asm, patch out or otherwise disable espfix if that sysctl
> has never been set.  (Ick.)
> 
> 2. When modify_ldt is runtime-disabled (or compile-time disabled,
> perhaps), disallow setting the LDT bit in SS in the handful of places
> that would allow it (ptrace and sigreturn off the top of my head).  We
> don't need to worry about (regs->ss & 4) being set on kernel entry
> because we'll never be in user mode with that bit set if the LDT is
> disabled, but that bit could still be set using kernel APIs.  (In
> fact, my sigreturn test does exactly that.)
> 
> Hmm.  With synchronous LDT, we could plausibly check at runtime in the
> espfix code, too.  We used to use LAR to do this, but hpa removed it
> when he realized that it was racy.  It shouldn't be racy any more,
> because, with my patches applied, the LDT never changes while
> interrupts are off.

I understand it's not complete but I'm a bit bothered with conflating
this sysctl with other setting methods, because if the purpose of the
sysctl is to disable the syscall, it should do that only. I'd rather
document that it's less complete than the Kconfig method and continue
to recommend using your option whenever possible (eg: all my kernels
will use it just as I've already disabled X86_16BIT everywhere).

Also one benefit of having both options is that it will mechanically
make LDT a much less interesting target for future attacks, since it
will significantly reduce the likeliness of success, hence the motivation
for writing exploits that only work in conferences.

Willy

--
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/

[toc] | [prev] | [next] | [standalone]

#1192413

On Sat, Jul 25, 2015 at 9:33 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Sat, Jul 25, 2015 at 09:08:39AM -0700, Andy Lutomirski wrote:
>> There's one thing that I think is incomplete here.  Currently, espfix
>> triggers if SS points to the LDT.  It's possible for SS to point to
>> the LDT even with modify_ldt disabled, and there's a decent amount of
>> attack surface there.
>>
>> Can we improve this?  Two ideas:
>>
>> 1. In the asm, patch out or otherwise disable espfix if that sysctl
>> has never been set.  (Ick.)
>>
>> 2. When modify_ldt is runtime-disabled (or compile-time disabled,
>> perhaps), disallow setting the LDT bit in SS in the handful of places
>> that would allow it (ptrace and sigreturn off the top of my head).  We
>> don't need to worry about (regs->ss & 4) being set on kernel entry
>> because we'll never be in user mode with that bit set if the LDT is
>> disabled, but that bit could still be set using kernel APIs.  (In
>> fact, my sigreturn test does exactly that.)
>>
>> Hmm.  With synchronous LDT, we could plausibly check at runtime in the
>> espfix code, too.  We used to use LAR to do this, but hpa removed it
>> when he realized that it was racy.  It shouldn't be racy any more,
>> because, with my patches applied, the LDT never changes while
>> interrupts are off.
>
> I understand it's not complete but I'm a bit bothered with conflating
> this sysctl with other setting methods, because if the purpose of the
> sysctl is to disable the syscall, it should do that only. I'd rather
> document that it's less complete than the Kconfig method and continue
> to recommend using your option whenever possible (eg: all my kernels
> will use it just as I've already disabled X86_16BIT everywhere).
>

Agreed.  We can certainly tighten up the espfix code later.

> Also one benefit of having both options is that it will mechanically
> make LDT a much less interesting target for future attacks, since it
> will significantly reduce the likeliness of success, hence the motivation
> for writing exploits that only work in conferences.
>

Patch looks fine to me.

--Andy
--
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/

[toc] | [prev] | [next] | [standalone]

#1192422

On Sat, Jul 25, 2015 at 10:42:14AM -0700, Andy Lutomirski wrote:
> On Sat, Jul 25, 2015 at 9:33 AM, Willy Tarreau <w@1wt.eu> wrote:
> > On Sat, Jul 25, 2015 at 09:08:39AM -0700, Andy Lutomirski wrote:
> >> There's one thing that I think is incomplete here.  Currently, espfix
> >> triggers if SS points to the LDT.  It's possible for SS to point to
> >> the LDT even with modify_ldt disabled, and there's a decent amount of
> >> attack surface there.
> >>
> >> Can we improve this?  Two ideas:
> >>
> >> 1. In the asm, patch out or otherwise disable espfix if that sysctl
> >> has never been set.  (Ick.)
> >>
> >> 2. When modify_ldt is runtime-disabled (or compile-time disabled,
> >> perhaps), disallow setting the LDT bit in SS in the handful of places
> >> that would allow it (ptrace and sigreturn off the top of my head).  We
> >> don't need to worry about (regs->ss & 4) being set on kernel entry
> >> because we'll never be in user mode with that bit set if the LDT is
> >> disabled, but that bit could still be set using kernel APIs.  (In
> >> fact, my sigreturn test does exactly that.)
> >>
> >> Hmm.  With synchronous LDT, we could plausibly check at runtime in the
> >> espfix code, too.  We used to use LAR to do this, but hpa removed it
> >> when he realized that it was racy.  It shouldn't be racy any more,
> >> because, with my patches applied, the LDT never changes while
> >> interrupts are off.
> >
> > I understand it's not complete but I'm a bit bothered with conflating
> > this sysctl with other setting methods, because if the purpose of the
> > sysctl is to disable the syscall, it should do that only. I'd rather
> > document that it's less complete than the Kconfig method and continue
> > to recommend using your option whenever possible (eg: all my kernels
> > will use it just as I've already disabled X86_16BIT everywhere).
> >
> 
> Agreed.  We can certainly tighten up the espfix code later.
> 
> > Also one benefit of having both options is that it will mechanically
> > make LDT a much less interesting target for future attacks, since it
> > will significantly reduce the likeliness of success, hence the motivation
> > for writing exploits that only work in conferences.
> >
> 
> Patch looks fine to me.

OK thanks.

Willy

--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web