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


Groups > linux.kernel > #1494337

Re: [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat
Date 2016-10-01 04:10 +0200
Message-ID <snhUt-1Rg-5@gated-at.bofh.it> (permalink)
References <snagn-54E-9@gated-at.bofh.it> <snagn-54E-23@gated-at.bofh.it> <snbcl-5HB-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[cc: PeterZ]

On Fri, Sep 30, 2016 at 11:56 AM, Jann Horn <jann@thejh.net> wrote:
> On Fri, Sep 30, 2016 at 10:58:56AM -0700, Andy Lutomirski wrote:
>> Reporting these fields on a non-current task is dangerous.  If the
>> task is in any state other than normal kernel code, they may contain
>> garbage or even kernel addresses on some architectures.
>
> Stupid question: Doesn't something similar apply to wchan?
> Am I missing something?
>
> It looks to me as if the get_wchan() implementation of X86 has the same
> issue, with the difference that it's not obviously usable as an infoleak
> because only known symbol names are printed, not numeric values.
>
> get_wchan() basically does the following:
>
>  - make sure the remote thread is sleeping (but don't take any locks to
>    ensure it stays that way)

Peter, how nasty would it be to add some lightish-weight lock that
lets us pin a task in a non-running state?  Maybe we could take the rq
lock, do something to the task to make it sleepy (steal it off the
queue?), unlock the lock, do whatever we're going, then take the lock
again and put it back.

Or if we had a seqlock-like thing, we could maybe arrange for
get_wchan to abort if the task get scheduled between when it starts
and when it finishes.

On an unrelated note, can we please lock down all the silly historical
*userspace* info leaks in /proc?  Nasty ones include: net, cmdline (at
the very least, only argv[0] should be visible if the reader lacks
ptrace access).

Less nasty ones include: limits, sched, autogroup, comm, wchan,
schedstat, cpuset, cgroup, oom_*, sessionid, coredump_filter

uid_map, gid_map, etc are just screwed up.  They should be per
*namespace* somewhere, and they should require creds on the namespace.

timerslack is totally fscked up -- it allows ugo to write and it
checks the wrong creds.  Jann, does your series fix that?

--Andy

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads Andy Lutomirski <luto@kernel.org> - 2016-09-30 20:00 +0200
  [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat Andy Lutomirski <luto@kernel.org> - 2016-09-30 20:00 +0200
    Re: [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat Jann Horn <jann@thejh.net> - 2016-09-30 21:00 +0200
      Re: [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat Andy Lutomirski <luto@amacapital.net> - 2016-10-01 04:10 +0200
        Re: [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-01 06:30 +0200
        Re: [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat Jann Horn <jann@thejh.net> - 2016-10-01 12:40 +0200
  Re: [PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads Andy Lutomirski <luto@amacapital.net> - 2016-10-04 01:10 +0200
    Re: [PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-04 01:20 +0200
      Re: [PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads Raymond Jennings <shentino@gmail.com> - 2016-10-04 09:10 +0200

csiph-web