public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <jesse@cats-chateau.net>
To: "Robert White" <rwhite@casabyte.com>,
	"'Ingo Molnar'" <mingo@elte.hu>,
	"'Christoph Hellwig'" <hch@infradead.org>,
	"'Mike McCormack'" <mike@codeweavers.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: WINE + NX (No eXecute) support for x86, 2.6.7-rc2-bk2
Date: Thu, 10 Jun 2004 08:35:17 -0500	[thread overview]
Message-ID: <04061008351700.11472@tabby> (raw)
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA2ZSI4XW+fk25FhAf9BqjtMKAAAAQAAAAdFYhVEbxb0Kgbx4hvCgIkQEAAAAA@casabyte.com>

On Wednesday 09 June 2004 15:53, Robert White wrote:
> Which is why I, later in the same message, wrote:
>
> Architecturally the easy-application-accessible switch should be something
> more than a syscall to prevent a return-address-twiddle invoking the call
> directly.  I'd make it a /proc/self something, or put it in a separate
> include-only-if-used shared library or something.  If the minimal distance
> is opening and writing a normally-untouched file then you get a nice
> support matrix.  (e.g. no file means no feature, file plus action means
> executable stack, no action means system default (old can, new cannot),
> hacks would require a variable (fd) and executing arbitrary code to open
> and write that file, programs/programmers that want/need the old behavior
> can achieve it without having to know how to manipulate their ELF headers
> or tool-chains, etc.)
>
> Which is not susceptible to the 1-2 attack you mention below because the
> open and write cannot be done on a protected stack or heap, since it would
> then have to be (er... ) executed to perform the hack.
>
> Ahhhh, yes...

no. This only means the 1-2 attack must be done in two steps (maybe three).

1. create the file (first buffer overflow)
2. write? (second buffer overflow - depends on whether file must have value)
3. disable NX (third)

  reply	other threads:[~2004-06-10 13:35 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-06  6:09 WINE + NX (No eXecute) support for x86, 2.6.7-rc2-bk2 Mike McCormack
2004-06-06  5:26 ` Ingo Molnar
2004-06-06  8:29   ` Mike McCormack
2004-06-06  7:32     ` Arjan van de Ven
2004-06-08  9:20       ` Jakub Jelinek
2004-06-08 11:15         ` Mike McCormack
2004-06-08 10:32           ` Ingo Molnar
2004-06-08 12:01             ` Mike McCormack
2004-06-09  1:40             ` John Reiser
2004-06-09  2:27               ` Paul Jackson
2004-06-06  7:32 ` Christoph Hellwig
2004-06-06  9:13   ` Mike McCormack
2004-06-06  8:10     ` Christoph Hellwig
2004-06-06  9:37       ` Mike McCormack
2004-06-06  8:39         ` Christoph Hellwig
2004-06-06  8:43           ` Christoph Hellwig
2004-06-06 10:20             ` Mike McCormack
2004-06-06 11:17             ` Felipe Alfaro Solana
2004-06-07  4:20         ` Horst von Brand
2004-06-07 14:19       ` Ingo Molnar
2004-06-08 21:50         ` Robert White
2004-06-08 21:57           ` Robert White
2004-06-09 16:53           ` Jesse Pollard
2004-06-09 20:53             ` Robert White
2004-06-10 13:35               ` Jesse Pollard [this message]
2004-06-10 21:13                 ` Robert White
2004-06-11  9:50                   ` Marc Bevand
2004-06-09 17:14           ` Jesper Juhl
2004-06-09 18:02             ` Evaldo Gardenali
2004-06-09 19:58             ` Felipe Alfaro Solana
2004-06-10 18:07             ` Stefanos Harhalakis
2004-06-06 11:38     ` David Woodhouse
2004-06-06 15:58       ` Mike McCormack
2004-06-07  8:49       ` David Howells
     [not found] <23Y4Y-6F5-1@gated-at.bofh.it>
     [not found] ` <240qb-8ir-7@gated-at.bofh.it>
     [not found]   ` <240Tc-gV-5@gated-at.bofh.it>
     [not found]     ` <2412S-pU-3@gated-at.bofh.it>
     [not found]       ` <24vX0-81P-7@gated-at.bofh.it>
2004-06-07 17:40         ` Andi Kleen
2004-06-08  9:42           ` Eric W. Biederman
     [not found]         ` <24WNz-4pO-3@gated-at.bofh.it>
2004-06-10 18:57           ` Bill Davidsen
2004-06-10 21:33             ` Robert White

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04061008351700.11472@tabby \
    --to=jesse@cats-chateau.net \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike@codeweavers.com \
    --cc=mingo@elte.hu \
    --cc=rwhite@casabyte.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox