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/
the "Turing Attack" (was: Sabotaged PaXtest)
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > btw., do you consider PaX as a 100% sure solution against 'code > > injection' attacks (meaning that the attacker wants to execute an > > arbitrary piece of code, and assuming the attacked application has a > > stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed > > way? > > your question is answered in http://pax.grsecurity.net/docs/pax.txt the problem is - your answer in that document is i believe wrong, in subtle and less subtle ways as well. In particular, lets take a look at the more detailed PaX description in: 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. ( there is no formal threat model ( == structured document defining types of attacks and conditions under which they occur) described on those webpages, but the above quote comes closest as a summary, wrt. the topic of code injection via overflows. ) firstly, let me outline what i believe the correct threat model is that covers all overflow-based code injection threats, in a very simplified sentence: - " the attacker wants to inject arbitrary code into a sufficiently capable (finite) Turing Machine on the attacked system, via overflows. " - as you can see from the formulation, this is a pretty generic model, that covers all conceivable forms of 'code injection' attacks - which makes it a natural choice to use. (A finite Turing Machine here is a "state machine with memory attached and code pre-defined". I.e. a simple CPU, memory and code.) a number of different types of Turing Machines may exist on any given target system: (1) Native Turing Machines (2) Intentional Turing Machines (3) Accidental Turing Machines (4) Malicious Turing Machines each type of machine can be attacked, and the end result is always the same: the attacker uses the capabilities of the attacked application for his own purposes. (==injects code) i'll first go through them one by one, in more detail. After that i'll talk about what i see as the consequences of this threat model and how it applies to the subject at hand, to PaX and to exec-shield. 1) Native Turing Machines - this is the most commonly used and attacked (but by no means exclusive) type: machine code interpreted by a CPU. Note: 'CPU' does not necessarily mean the _host CPU_, it could easily mean code interpretation done by a graphics CPU or a firmware CPU. ( Note: 'machine code' does not necessarily mean that the typical operation mode of the host CPU is attacked: there are many CPUs that support multiple instruction set architectures. E.g. x86 CPUs support 16-bit and 32-bit code as well, and x64 supports 3 modes in fact: 64-bit, 32-bit and 16-bit code too. Depending on the type of application vulnerability, an attack may want to utilize a different type of ISA than the most common one, to minimize the complexity needed to utilize the Turing Machine. ) 2) Intentional Turing Machines -- these are pretty commonly used too: "software CPUs" in essence, e.g. script interpreters, virtual machines and CPU emulators. There are also forms of code which one might not recognize as a Turing Machine: parsers of some of the more capable configuration files. in no case must these Turing Machines be handled in any way different from 'native binary code' - all that matters is the capabilities and attackability of the Turing Machine, not it's implementation! (E.g. an attack might go against a system that itself is running on an emulated CPU - in that case the attacker is up against an 'interpreter', not a real native CPU.) Note that such interpreters/machines, since implemented within a binary or library, can very often be used from within the process image via ret2libc methods, so they are not controllable via 'access control' means. ( Note that e.g. the
the Turing Attack (was: Sabotaged PaXtest)
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: btw., do you consider PaX as a 100% sure solution against 'code injection' attacks (meaning that the attacker wants to execute an arbitrary piece of code, and assuming the attacked application has a stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed way? your question is answered in http://pax.grsecurity.net/docs/pax.txt the problem is - your answer in that document is i believe wrong, in subtle and less subtle ways as well. In particular, lets take a look at the more detailed PaX description in: 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. ( there is no formal threat model ( == structured document defining types of attacks and conditions under which they occur) described on those webpages, but the above quote comes closest as a summary, wrt. the topic of code injection via overflows. ) firstly, let me outline what i believe the correct threat model is that covers all overflow-based code injection threats, in a very simplified sentence: - the attacker wants to inject arbitrary code into a sufficiently capable (finite) Turing Machine on the attacked system, via overflows. - as you can see from the formulation, this is a pretty generic model, that covers all conceivable forms of 'code injection' attacks - which makes it a natural choice to use. (A finite Turing Machine here is a state machine with memory attached and code pre-defined. I.e. a simple CPU, memory and code.) a number of different types of Turing Machines may exist on any given target system: (1) Native Turing Machines (2) Intentional Turing Machines (3) Accidental Turing Machines (4) Malicious Turing Machines each type of machine can be attacked, and the end result is always the same: the attacker uses the capabilities of the attacked application for his own purposes. (==injects code) i'll first go through them one by one, in more detail. After that i'll talk about what i see as the consequences of this threat model and how it applies to the subject at hand, to PaX and to exec-shield. 1) Native Turing Machines - this is the most commonly used and attacked (but by no means exclusive) type: machine code interpreted by a CPU. Note: 'CPU' does not necessarily mean the _host CPU_, it could easily mean code interpretation done by a graphics CPU or a firmware CPU. ( Note: 'machine code' does not necessarily mean that the typical operation mode of the host CPU is attacked: there are many CPUs that support multiple instruction set architectures. E.g. x86 CPUs support 16-bit and 32-bit code as well, and x64 supports 3 modes in fact: 64-bit, 32-bit and 16-bit code too. Depending on the type of application vulnerability, an attack may want to utilize a different type of ISA than the most common one, to minimize the complexity needed to utilize the Turing Machine. ) 2) Intentional Turing Machines -- these are pretty commonly used too: software CPUs in essence, e.g. script interpreters, virtual machines and CPU emulators. There are also forms of code which one might not recognize as a Turing Machine: parsers of some of the more capable configuration files. in no case must these Turing Machines be handled in any way different from 'native binary code' - all that matters is the capabilities and attackability of the Turing Machine, not it's implementation! (E.g. an attack might go against a system that itself is running on an emulated CPU - in that case the attacker is up against an 'interpreter', not a real native CPU.) Note that such interpreters/machines, since implemented within a binary or library, can very often be used from within the process image via ret2libc methods, so they are not controllable via 'access control' means. ( Note that e.g. the sendmail.cf configuration
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/
