On Mon, 11 Nov 2002 21:38:13 -0600, Linas Vepstas wrote:
On Tue, Nov 12, 2002 at 02:00:14AM +0100, Ulrich Weigand was heard to remark:
Linas Vepstas wrote:
Ugh. Well, that could stop the show. But since the instruction causing
this would be a problem state instruction, maybe there are fewer
On Monday 11 November 2002 05:34 pm, Gregg C Levine wrote:
However, I did look at the
product, for Windows. And I wasn't thrilled by it.
iRMX for Windows? UGH!!! My mind quails at the mere thought.
(For those unfamiliar, iRMX was/is a realtime operating system created by Intel
and primarily
-390;VM.MARIST.EDU] On Behalf Of
Scott Courtney
Sent: Tuesday, November 12, 2002 11:05 AM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] CPU Arch Security [was: Re: Probably the
first
published shell code]
On Monday 11 November 2002 05:34 pm, Gregg C Levine wrote:
However, I did look
;VM.MARIST.EDU] On Behalf Of
Gregg C Levine
Sent: Tuesday, November 12, 2002 11:59 AM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] CPU Arch Security [was: Re: Probably the
first
published shell code]
Hello from Gregg C Levine
Actually that was my reaction. The demonstration packet that they sent
me
On Tuesday 05 November 2002 11:13 pm, David Boyes wrote:
b) Same scenario as above, but word-substitute apache-kernel and
mod_trojan-device driver. [...]
And we reinvent the Multics ring structure one more time
dockmaster.af.mil, wherefore art thou?
I'll be lynched for saying
dedicates this E-Mail to Master Yoda )
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390;VM.MARIST.EDU] On Behalf Of
Scott Courtney
Sent: Monday, November 11, 2002 4:51 PM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] CPU Arch Security [was: Re: Probably the
first
On Mon, Nov 11, 2002 at 08:40:45PM +0100, Ulrich Weigand was heard to remark:
Linas Vepstas wrote:
Every page of memory has a storage key, which holds a key and a
fetch-protection bit. If the fetch-protection bit is cleared,
then anyone can read the page; if the fetch-protection bit is
Linas Vepstas wrote:
-- if 'exception 04' can be caught and passed back up to the library,
Unfortunately it can't, as key-protection violation is a 'terminating'
exception condition, which means the CPU state at the time the
interruption is delivered is undefined. This means that the instruction
On Tue, 12 Nov 2002, Ulrich Weigand wrote:
Linas Vepstas wrote:
-- if 'exception 04' can be caught and passed back up to the library,
Unfortunately it can't, as key-protection violation is a 'terminating'
exception condition, which means the CPU state at the time the
interruption is
On Tue, Nov 12, 2002 at 02:00:14AM +0100, Ulrich Weigand was heard to remark:
Linas Vepstas wrote:
-- if 'exception 04' can be caught and passed back up to the library,
Unfortunately it can't, as key-protection violation is a 'terminating'
exception condition, which means the CPU state at
On Tue, 12 Nov 2002 11:38, you wrote:
On Tue, Nov 12, 2002 at 02:00:14AM +0100, Ulrich Weigand was heard to
remark:
Linas Vepstas wrote:
-- if 'exception 04' can be caught and passed back up to the library,
Unfortunately it can't, as key-protection violation is a 'terminating'
exception
On Tue, 12 Nov 2002 13:30, you wrote:
xc relatives
On further reflection, those fail before they start. However, if they're
subject to an execute instruction I think you have difficulties.
Mind you, if you're contemplating a new CPU design, you can also consider a
microcode update to
On Sun, 2002-11-10 at 01:55, John Summerfield wrote:
Is this a reason to not close down those avenues that are easy? Seems to me
that if you fix some, you have fewer left to fix.
As the philospher said, a journey of a thousand leagues starts with a single
step.
From a security view point
Linas Vepstas wrote:
But in my storage-key world, I can imagine spearating the strcture
from the data, and putting the structure in read-only memory, where the
app can see it but not corrupt it, and putting the data in a read-write
key, where the app can do whatever it wants.
And *once you
On Sat, 9 Nov 2002 01:09, you wrote:
On Thu, 2002-11-07 at 19:11, John Summerfield wrote:
On IA32, if it's not in the code segment, you can't execute it.
The code segment _can_ be ro, so presumably a return to arbitrary code
can be prevented.
I dont need to modify any of the code
On Thu, 2002-11-07 at 19:11, John Summerfield wrote:
On IA32, if it's not in the code segment, you can't execute it.
The code segment _can_ be ro, so presumably a return to arbitrary code can be
prevented.
I dont need to modify any of the code segment to exploit your machine.
In fact several
Linas Vepstas wrote:
Sorry I used the word semaphore. Using pipes shmem is hard. Well,
using them is easy, using them and creating something that's extenisble,
maintainble, lacks race conditions and other bugs ... that's a lot
harder. If it's so easy, why didn't ssh do it years ago?
The
At 17:09 11/08/2002 +, Alan Cox wrote:
In fact several exploits work on the basis they overrun a stack section
with a complete return sequence including variables to cause an
execlp(/bin/sh, ...) to occur.
Yup, that was exactly the case in the Phrack article that started this
whole topic.
On Fri, Nov 08, 2002 at 05:50:56PM +0100, Ulrich Weigand was heard to remark:
Linas Vepstas wrote:
Sorry I used the word semaphore. Using pipes shmem is hard. Well,
using them is easy, using them and creating something that's extenisble,
maintainble, lacks race conditions and other bugs
On Wed, Nov 06, 2002 at 10:36:40AM +0800, John Summerfield was heard to remark:
On Wed, 6 Nov 2002 05:45, you wrote:
The core idea is actually so simple, its painful. Today, most CPU's
define two memory spaces: the one that the kernel lives in, and the
one that the user-space lives in.
On Wed, Nov 06, 2002 at 10:14:34AM +0800, John Summerfield was heard to remark:
On Wed, 6 Nov 2002 04:39, you wrote:
x86 alas doesnt support page level no execute. Other platforms do and
can run with nonexec stacks. People still exploit them. The libraries
are mostly mapped read only on
: Linas Vepstas [mailto:linas;linas.org]
Sent: Thursday, November 07, 2002 11:47 AM
To: [EMAIL PROTECTED]
Subject: Re: CPU Arch Security [was: Re: Probably the first published
shell code]
On Wed, Nov 06, 2002 at 10:36:40AM +0800, John Summerfield was heard to remark:
On Wed, 6 Nov 2002 05:45, you
On Tue, Nov 05, 2002 at 10:16:28PM +0100, Ulrich Weigand was heard to remark:
Adam Thornton wrote:
(However, changing the Linux tool
chain and basically *all* applications from a flat address space
I don't see that you need to change *all* apps. This would be only for
apps that really care.
On Tue, Nov 05, 2002 at 04:01:57PM -0500, Adam Thornton was heard to remark:
Good lord, I can't believe that I'm arguing for a segmented
architecture.
After they beat me down, my plan is to later claim tht I was only
playing devil's advocate, and I wasn't actually stupid enough to
beleive in
On Thu, 2002-11-07 at 12:02, Ward, Garry wrote:
Which, in the S/390 CICS world is handled by the domain concept; CICS systems
modules run in one domain and can interface with the OS in ways that
the CICS applications can not becasue of the protection keys that the
s/390 hardware supports.
On Thu, 7 Nov 2002 10:46:30 -0600, Linas Vepstas [EMAIL PROTECTED]
wrote:
On Wed, Nov 06, 2002 at 10:36:40AM +0800, John Summerfield was heard to remark:
On Wed, 6 Nov 2002 05:45, you wrote:
The core idea is actually so simple, its painful. Today, most CPU's
define two memory spaces: the
Research Group
419-725-4123
-Original Message-
From: David Andrews [mailto:dba;duda.com]
Sent: Thursday, November 07, 2002 12:20 PM
To: [EMAIL PROTECTED]
Subject: Re: CPU Arch Security [was: Re: Probably the first published
shell code]
On Thu, 2002-11-07 at 12:02, Ward, Garry wrote
On Thu, 7 Nov 2002, Linas Vepstas wrote:
On Wed, Nov 06, 2002 at 10:14:34AM +0800, John Summerfield was heard to remark:
On Wed, 6 Nov 2002 04:39, you wrote:
x86 alas doesnt support page level no execute. Other platforms do and
can run with nonexec stacks. People still exploit them. The
: Probably the first published shell
code]
Date: Thu, 7 Nov 2002 11:09:04 -0600
On Tue, Nov 05, 2002 at 10:16:28PM +0100, Ulrich Weigand was heard to
remark:
Adam Thornton wrote:
(However, changing the Linux tool
chain and basically *all* applications from a flat address space
I don't
On Thu, 7 Nov 2002, Ward, Garry wrote:
Today, you cannot make
a distinction between trusting apache itself, and trusting any apache
module, since they both run in the same address space, and therefore
have full read and write access to that address space.
Which, in the S/390 CICS world is
It doesn't matter where the instruction resides - the key in the current PSW
determines stomping rights.
-jcf
- Original Message -
From: Ward, Garry [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 07, 2002 11:37 AM
Subject: Re: CPU Arch Security [was: Re: Probably
Linas Vepstas wrote:
I didn't say it wasn't enormous. Its not tiny, but I'm not sure
its that big either.
Well, for a start, you can't really do program calls in home space
mode (which is where Linux user mode runs), so you'd need to
fundamentally redesign the whole kernel/user space model
On Thu, Nov 07, 2002 at 07:22:09PM +, Jan Jaeger was heard to remark:
Linas,
Do I understand you correctly, in that you propose a multi layered system
integrity design, whereby shared libs for example have a different
authorisation from normal apps (almost like a multi ring structure)?
On Fri, Nov 08, 2002 at 12:55:31AM +0100, Ulrich Weigand was heard to remark:
Linas Vepstas wrote:
I didn't say it wasn't enormous. Its not tiny, but I'm not sure
its that big either.
Well, for a start, you can't really do program calls in home space
mode (which is where Linux user mode
On Wed, 2002-11-06 at 02:36, John Summerfield wrote:
BTW IA32 has four protection levels enforced in hardware. I believe the
problem is that Linux doesn't use them all.
x86 has 2 or 4 depending on where you look. Some of the levels really
exist as back compatibility segmentation stuff only.
Linas Vepstas wrote:
I've always been curious. Why is a top down stack used anyways ??
If the heap grows up, and the stack grows down, then one can have,
in theory, arbitrarily large stacks. Handy for CPU's that have a
single flat memory space that is not very big
Ahhh Now if someone
On Tue, 2002-11-05 at 21:01, Adam Thornton wrote:
other data spaces, and I don't think you can execute code from data
spaces, but you see where this is going), so you could share your shared
x86 alas doesnt support page level no execute. Other platforms do and
can run with nonexec stacks.
that hardware funtionality, with os support is the best answer to
viruses, although it will probably never be 100% failsafe.
Jan Jaeger
From: Adam Thornton [EMAIL PROTECTED]
Reply-To: Linux on 390 Port [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: CPU Arch Security [was: Re: Probably the first
Adam Thornton wrote:
Well, one thing I can see exploiting under VM would be an agressive use
of DCSSes (or something like them--I don't know if you can put DCSSes in
other data spaces, and I don't think you can execute code from data
spaces, but you see where this is going), so you could share
On Tue, 2002-11-05 at 21:16, Ulrich Weigand wrote:
convinced this buys you anything w.r.t. security that can't be
achieved much more easily, e.g. by StackGuard-type compilers.
Certainly nobody has even attempted to do this w.r.t. segments
on Intel for example -- at least as far as I know.)
On Tue, Nov 05, 2002 at 08:03:35PM +, Alan Cox was heard to remark:
On Tue, 2002-11-05 at 19:04, Linas Vepstas wrote:
For this to catch on in the mainstream, other CPU architectures
would need to add similar features as well. But given the recent
burbling from microsoft and intel about
On Wed, 6 Nov 2002 04:39, you wrote:
x86 alas doesnt support page level no execute. Other platforms do and
can run with nonexec stacks. People still exploit them. The libraries
are mostly mapped read only on Linux, people don't need to modify them.
You put arguments on the stack, and corrupt
On Wed, 6 Nov 2002 05:45, you wrote:
The core idea is actually so simple, its painful. Today, most CPU's
define two memory spaces: the one that the kernel lives in, and the
one that the user-space lives in. When properly designed, there is
nothing a user-space program can do to corrupt
b) Same scenario as above, but word-substitute apache-kernel and
mod_trojan-device driver. If the linux kernel ran in 'space 2',
but device drivers ran in 'space 3', then nasties can't hurt
the kernel, while still enjoying read-write access to the
bus and other hardware that
At 00:39 11/06/2002 -0500, you wrote:
On Tue, Nov 05, 2002 at 11:13:59PM -0500, David Boyes wrote:
And we reinvent the Multics ring structure one more time
dockmaster.af.mil, wherefore art thou?
More to the point, now that there are no longer any Multics systems in
production...
When does
45 matches
Mail list logo
