Re: the "Turing Attack" (was: Sabotaged PaXtest)
[Posted only on LKML, this has become humour.] On Thu, Feb 10, 2005 at 09:03:00PM +0100, David Weinehall wrote: > On Thu, Feb 10, 2005 at 04:21:49PM +0100, Ingo Molnar wrote: > > > > * Jakob Oestergaard <[EMAIL PROTECTED]> wrote: > > > > PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield > > > > is in the 6th month, but that does not change the fundamental > > > > end-result: a child will be born ;-) > > > > > > Yes and no. I would think that the chances of a child being born are > > > greater if the pregnancy has lasted successfully up until the 6th month, > > > compared to a first week pregnancy. > > > > > > I assume you get my point :) > > > > the important point is: neither PaX nor exec-shield can claim _for sure_ > > that no child will be born, and neither can claim virginity ;-) > > > > [ but i guess there's a point where a bad analogy must stop ;) ] > > Yeah, sex is *usually* a much more pleasant experience than having your > machine broken into, even if it results in a pregnancy. =) I'll bite, before anyone else says it... It can not be a mere coincidence that the most rigorous security audits include penetration testing. -- Mika Boström +358-40-525-7347 \-/ "World peace will be achieved [EMAIL PROTECTED]www.iki.fi/bostik Xwhen the last man has killed Security freak, and proud of it./-\ the second-to-last." -anon? signature.asc Description: Digital signature
Re: the Turing Attack (was: Sabotaged PaXtest)
[Posted only on LKML, this has become humour.] On Thu, Feb 10, 2005 at 09:03:00PM +0100, David Weinehall wrote: On Thu, Feb 10, 2005 at 04:21:49PM +0100, Ingo Molnar wrote: * Jakob Oestergaard [EMAIL PROTECTED] wrote: PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield is in the 6th month, but that does not change the fundamental end-result: a child will be born ;-) Yes and no. I would think that the chances of a child being born are greater if the pregnancy has lasted successfully up until the 6th month, compared to a first week pregnancy. I assume you get my point :) the important point is: neither PaX nor exec-shield can claim _for sure_ that no child will be born, and neither can claim virginity ;-) [ but i guess there's a point where a bad analogy must stop ;) ] Yeah, sex is *usually* a much more pleasant experience than having your machine broken into, even if it results in a pregnancy. =) I'll bite, before anyone else says it... It can not be a mere coincidence that the most rigorous security audits include penetration testing. -- Mika Boström +358-40-525-7347 \-/ World peace will be achieved [EMAIL PROTECTED]www.iki.fi/bostik Xwhen the last man has killed Security freak, and proud of it./-\ the second-to-last. -anon? signature.asc Description: Digital signature
Re: the "Turing Attack" (was: Sabotaged PaXtest)
On Thu, Feb 10, 2005 at 04:21:49PM +0100, Ingo Molnar wrote: > > * Jakob Oestergaard <[EMAIL PROTECTED]> wrote: > > > On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote: > > > > > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > the bigger problem is however that you're once again fixing the > > > > symptoms, instead of the underlying problem - not the correct > > > > approach/mindset. > > > > > > i'll change my approach/mindset when it is proven that "the underlying > > > problem" can be solved. (in a deterministic fashion) > > > > I know neither exec-shield nor PaX and therefore have no bias or > > preference - I thought I should chirp in on your comment here Ingo... > > > > ... > > > PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield > > > is in the 6th month, but that does not change the fundamental > > > end-result: a child will be born ;-) > > > > Yes and no. I would think that the chances of a child being born are > > greater if the pregnancy has lasted successfully up until the 6th month, > > compared to a first week pregnancy. > > > > I assume you get my point :) > > the important point is: neither PaX nor exec-shield can claim _for sure_ > that no child will be born, and neither can claim virginity ;-) > > [ but i guess there's a point where a bad analogy must stop ;) ] Yeah, sex is *usually* a much more pleasant experience than having your machine broken into, even if it results in a pregnancy. =) Regards: David -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the "Turing Attack" (was: Sabotaged PaXtest)
* Jakob Oestergaard <[EMAIL PROTECTED]> wrote: > On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote: > > > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > the bigger problem is however that you're once again fixing the > > > symptoms, instead of the underlying problem - not the correct > > > approach/mindset. > > > > i'll change my approach/mindset when it is proven that "the underlying > > problem" can be solved. (in a deterministic fashion) > > I know neither exec-shield nor PaX and therefore have no bias or > preference - I thought I should chirp in on your comment here Ingo... > > ... > > PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield > > is in the 6th month, but that does not change the fundamental > > end-result: a child will be born ;-) > > Yes and no. I would think that the chances of a child being born are > greater if the pregnancy has lasted successfully up until the 6th month, > compared to a first week pregnancy. > > I assume you get my point :) the important point is: neither PaX nor exec-shield can claim _for sure_ that no child will be born, and neither can claim virginity ;-) [ but i guess there's a point where a bad analogy must stop ;) ] Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the "Turing Attack" (was: Sabotaged PaXtest)
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> the bigger problem is however that you're once again fixing the
> symptoms, instead of the underlying problem - not the correct
> approach/mindset.
i'll change my approach/mindset when it is proven that "the underlying
problem" can be solved. (in a deterministic fashion)
in case you dont accept the threat model i outlined (the
[almost-Universal] Turing Machine approach), here are the same
fundamental arguments, applied to the PaX threat model.
first about the basic threat itself: it comes from some sort of memory
overwrite condition that an attacker can control - we assume the
worst-case, that the attacker has arbitrary read/write access to the
writable portions of the attacked task's address space. [this threat
arises out of some sort of memory overwrite flaw most of the time.]
you are splitting the possible effects of a given specific threat into 3
categories:
(1) introduce/execute arbitrary [native] code
(2) execute existing code out of original program order
(3) execute existing code in original program order with arbitrary data
then you are building defenses against each category. You say that PaX
covers (1) deterministically, while exec-shield only adds probabilistic
defenses (which i agree with). You furthermore say (in your docs) that
PaX (currently) offers probabilistic defenses against (2) and (3). You
furthermore document it that (2) and (3) can likely only be
probabilistically defended against.
i hope we are in agreement so far, and here comes the point where i
believe our opinion diverges: i say that if _any_ aspect of a given
specific threat is handled in a probabilistic way, the whole defense
mechanism is still only probabilistic!
in other words: unless you have a clear plan to turn PaX into a
deterministic defense, for a specific threat outlined above, it is just
as probabilistic (clearly with a better entropy) as exec-shield.
PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield
is in the 6th month, but that does not change the fundamental
end-result: a child will be born ;-)
you cannot just isolate a given attack type ('exploit class') and call
PaX deterministic and trumpet a security guarantee - since what makes
sense from a security guarantee point of view is the actions of the
*attacker*: _can_ the attacker mount a successful attack or not, given a
specific threat? If he can never mount a successful attack (using a
specific flaw) then the defense is deterministic. If there is an exploit
class that can be successful then the defense is probabilistic. (or
nonexistent)
Defending only against a class of exploits (applied to the specific
threat) will force attackers towards the remaining areas - but if those
remaining areas cannot be defended against for sure, then you cannot say
that PaX offers a security guarantee against that specific threat.
Talking about security guarantees against 'sub-threats' does not make
sense because attackers dont do us the favor of using only one class of
attacks.
and once we are in the land of probabilistic defenses, it's the weakest
link that matters. It might make sense to handle the 'native code
injection' portion of the threat in a deterministic way, but only as a
tool to drive attackers towards vectors that are less probable, and it
is not in any way giving any security guarantee.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: the Turing Attack (was: Sabotaged PaXtest)
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
the bigger problem is however that you're once again fixing the
symptoms, instead of the underlying problem - not the correct
approach/mindset.
i'll change my approach/mindset when it is proven that the underlying
problem can be solved. (in a deterministic fashion)
in case you dont accept the threat model i outlined (the
[almost-Universal] Turing Machine approach), here are the same
fundamental arguments, applied to the PaX threat model.
first about the basic threat itself: it comes from some sort of memory
overwrite condition that an attacker can control - we assume the
worst-case, that the attacker has arbitrary read/write access to the
writable portions of the attacked task's address space. [this threat
arises out of some sort of memory overwrite flaw most of the time.]
you are splitting the possible effects of a given specific threat into 3
categories:
(1) introduce/execute arbitrary [native] code
(2) execute existing code out of original program order
(3) execute existing code in original program order with arbitrary data
then you are building defenses against each category. You say that PaX
covers (1) deterministically, while exec-shield only adds probabilistic
defenses (which i agree with). You furthermore say (in your docs) that
PaX (currently) offers probabilistic defenses against (2) and (3). You
furthermore document it that (2) and (3) can likely only be
probabilistically defended against.
i hope we are in agreement so far, and here comes the point where i
believe our opinion diverges: i say that if _any_ aspect of a given
specific threat is handled in a probabilistic way, the whole defense
mechanism is still only probabilistic!
in other words: unless you have a clear plan to turn PaX into a
deterministic defense, for a specific threat outlined above, it is just
as probabilistic (clearly with a better entropy) as exec-shield.
PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield
is in the 6th month, but that does not change the fundamental
end-result: a child will be born ;-)
you cannot just isolate a given attack type ('exploit class') and call
PaX deterministic and trumpet a security guarantee - since what makes
sense from a security guarantee point of view is the actions of the
*attacker*: _can_ the attacker mount a successful attack or not, given a
specific threat? If he can never mount a successful attack (using a
specific flaw) then the defense is deterministic. If there is an exploit
class that can be successful then the defense is probabilistic. (or
nonexistent)
Defending only against a class of exploits (applied to the specific
threat) will force attackers towards the remaining areas - but if those
remaining areas cannot be defended against for sure, then you cannot say
that PaX offers a security guarantee against that specific threat.
Talking about security guarantees against 'sub-threats' does not make
sense because attackers dont do us the favor of using only one class of
attacks.
and once we are in the land of probabilistic defenses, it's the weakest
link that matters. It might make sense to handle the 'native code
injection' portion of the threat in a deterministic way, but only as a
tool to drive attackers towards vectors that are less probable, and it
is not in any way giving any security guarantee.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: the Turing Attack (was: Sabotaged PaXtest)
* Jakob Oestergaard [EMAIL PROTECTED] wrote: On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: the bigger problem is however that you're once again fixing the symptoms, instead of the underlying problem - not the correct approach/mindset. i'll change my approach/mindset when it is proven that the underlying problem can be solved. (in a deterministic fashion) I know neither exec-shield nor PaX and therefore have no bias or preference - I thought I should chirp in on your comment here Ingo... ... PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield is in the 6th month, but that does not change the fundamental end-result: a child will be born ;-) Yes and no. I would think that the chances of a child being born are greater if the pregnancy has lasted successfully up until the 6th month, compared to a first week pregnancy. I assume you get my point :) the important point is: neither PaX nor exec-shield can claim _for sure_ that no child will be born, and neither can claim virginity ;-) [ but i guess there's a point where a bad analogy must stop ;) ] Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the Turing Attack (was: Sabotaged PaXtest)
On Thu, Feb 10, 2005 at 04:21:49PM +0100, Ingo Molnar wrote: * Jakob Oestergaard [EMAIL PROTECTED] wrote: On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: the bigger problem is however that you're once again fixing the symptoms, instead of the underlying problem - not the correct approach/mindset. i'll change my approach/mindset when it is proven that the underlying problem can be solved. (in a deterministic fashion) I know neither exec-shield nor PaX and therefore have no bias or preference - I thought I should chirp in on your comment here Ingo... ... PaX cannot be a 'little bit pregnant'. (you might argue that exec-shield is in the 6th month, but that does not change the fundamental end-result: a child will be born ;-) Yes and no. I would think that the chances of a child being born are greater if the pregnancy has lasted successfully up until the 6th month, compared to a first week pregnancy. I assume you get my point :) the important point is: neither PaX nor exec-shield can claim _for sure_ that no child will be born, and neither can claim virginity ;-) [ but i guess there's a point where a bad analogy must stop ;) ] Yeah, sex is *usually* a much more pleasant experience than having your machine broken into, even if it results in a pregnancy. =) Regards: David -- /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the "Turing Attack" (was: Sabotaged PaXtest)
Followup to: <[EMAIL PROTECTED]> By author:Ingo Molnar <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > This, on the face of it, seems like a ridiculous possibility as the > chances of that are reverse proportional to the number of bits necessary > to implement the simplest Turing Machine. (which for anything even > closely usable are on the order of 2^1, less likely than the > likelyhood of us all living to the end of the Universe.) > 2^1? Not even close. You can build a fully Turing-complete interpreter in a few tens of bytes (a few hundred bits) on most architectures, and you have to consider ALL bit combinations that can form an accidental Turing machine. What is far less clear is whether or not you can use that accidental Turing machine to do real damage. After all, it's not computation (in the strict sense) that causes security violations, it's I/O. Thus, the severity of the problem depends on which I/O primitives the accidental Turing machine happens to embody. Note that writing to the memory of the host process is considered I/O for this purpose. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the "Turing Attack" (was: Sabotaged PaXtest)
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > http://pax.grsecurity.net/docs/pax-future.txt > >To understand the future direction of PaX, let's summarize what we >achieve currently. The goal is to prevent/detect exploiting of >software bugs that allow arbitrary read/write access to the attacked >process. Exploiting such bugs gives the attacker three different >levels of access into the life of the attacked process: > >(1) introduce/execute arbitrary code >(2) execute existing code out of original program order >(3) execute existing code in original program order with arbitrary >data > >Non-executable pages (NOEXEC) and mmap/mprotect restrictions >(MPROTECT) prevent (1) with one exception: if the attacker is able to >create/write to a file on the target system then mmap() it into the >attacked process then he will have effectively introduced and >executed arbitrary code. >[...] > > the blanket statement in this last paragraph is simply wrong, as it > omits to mention a number of other ways in which "code" can be > injected. i'd like to correct this sentence of mine because it's unfair: your categories are consistent if you define 'code' as 'machine code', and it's clear from your documents that you mean 'machine code' under code. (My other criticism remains.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the Turing Attack (was: Sabotaged PaXtest)
* Ingo Molnar [EMAIL PROTECTED] wrote: http://pax.grsecurity.net/docs/pax-future.txt To understand the future direction of PaX, let's summarize what we achieve currently. The goal is to prevent/detect exploiting of software bugs that allow arbitrary read/write access to the attacked process. Exploiting such bugs gives the attacker three different levels of access into the life of the attacked process: (1) introduce/execute arbitrary code (2) execute existing code out of original program order (3) execute existing code in original program order with arbitrary data Non-executable pages (NOEXEC) and mmap/mprotect restrictions (MPROTECT) prevent (1) with one exception: if the attacker is able to create/write to a file on the target system then mmap() it into the attacked process then he will have effectively introduced and executed arbitrary code. [...] the blanket statement in this last paragraph is simply wrong, as it omits to mention a number of other ways in which code can be injected. i'd like to correct this sentence of mine because it's unfair: your categories are consistent if you define 'code' as 'machine code', and it's clear from your documents that you mean 'machine code' under code. (My other criticism remains.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the Turing Attack (was: Sabotaged PaXtest)
Followup to: [EMAIL PROTECTED] By author:Ingo Molnar [EMAIL PROTECTED] In newsgroup: linux.dev.kernel This, on the face of it, seems like a ridiculous possibility as the chances of that are reverse proportional to the number of bits necessary to implement the simplest Turing Machine. (which for anything even closely usable are on the order of 2^1, less likely than the likelyhood of us all living to the end of the Universe.) 2^1? Not even close. You can build a fully Turing-complete interpreter in a few tens of bytes (a few hundred bits) on most architectures, and you have to consider ALL bit combinations that can form an accidental Turing machine. What is far less clear is whether or not you can use that accidental Turing machine to do real damage. After all, it's not computation (in the strict sense) that causes security violations, it's I/O. Thus, the severity of the problem depends on which I/O primitives the accidental Turing machine happens to embody. Note that writing to the memory of the host process is considered I/O for this purpose. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
