John Summerfield scribbled:
> 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 prevente
making it addressable
through an access register (ie data space) only.
From: "John R . Campbell" <[EMAIL PROTECTED]>
Reply-To: Linux on 390 Port <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: CPU Arch Security
Date: Sat, 9 Nov 2002 22:38:58 -0500
The issue i
Jan Jaeger wrote:
>I think that the real issue here is that Linux (or unix in general) does has
>litte to offer with regard to program capabilities (ref keykos/eros micro
>kernel designs). Under Linux, (acl based) one basically has all the
>authorisations of the user under which one is running.
From: Ulrich Weigand <[EMAIL PROTECTED]>
Reply-To: Linux on 390 Port <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: CPU Arch Security
Date: Sun, 10 Nov 2002 17:55:53 +0100
Well, Linux has capabilities nowadays, but they aren't much used
in your typical distribution
On Sun, 10 Nov 2002 22:27, you wrote:
> 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 w
Jan Jaeger wrote:
>I am not sure that one would run away from the concept of unix. One can
>easily (in concept anyway) add more spaces to one process, separate spaces
>for code, stack and data for example.
>Similarly, shared libs could reside in their own space, one would need a
>different linkag
Hi,
I think that I can understand both views, but I can only say that I
think the concepts needed to exploit the different execution domains
within one process is asking for a new operating system and that I guess
this new operating system might be S/390-specific or the applications
using it wou
On Tuesday 12 November 2002 11:58 am, Gregg C Levine wrote:
> Actually that was my reaction. The demonstration packet that they sent
> me, was the thing that did it. The terms, "kludge", and "clumsy", and a
> few others that were not polite, crossed my mined, at the time. And you
> are right about
> From: Greg Smith [mailto:rys@;epaibm.rtpnc.epa.gov]
> Ross Patterson wrote:
> > s390 port had been successful, we wouldn't have this problem. Linas'
> port
> > of GCC for "Bigfoot" had the stack growing *upward*, not *downward* as
> on
> > almost every other platform.
>
> I've always been curio
On Tue, Nov 05, 2002 at 08:03:35PM +, Alan Cox wrote:
> Flavour of the year appears to be maths sign/overflow mishandling.
> Buffer overflows are no longer a growth area as programmers learn that
> one.
Gee, only took 'em, what, 40 years?
> > For this to catch on in the mainstream, other CPU
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 it get released to the world?
Adam
On Tue, 2002-11-05 at 19:04, Linas Vepstas wrote:
> Its time the stack-growth-direction bug got fixed; the architectural
> limitations that caused it to grow down are now gone, and the
> stack-overrun attacks that it engenders are a great threat to
> computer security.
Except that parisc has a sta
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. Pe
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:
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
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 corr
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 ha
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 doe
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. Mo
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 l
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 onl
al Message-
From: 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:
> O
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 car
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 i
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 mem
otive 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
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
manager, and AIX/370 only ran under VM, both of these AIXes used the
hypervisor to take care of the hw specifics in one way or another.
Jan Jaeger
From: Linas Vepstas <[EMAIL PROTECTED]>
Reply-To: Linux on 390 Port <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: CPU Arch S
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 wo
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
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 (a
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 use
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 seve
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?
Th
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 othe
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 yo
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
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 poin
On Sat, Nov 09, 2002 at 08:01:55PM +0100, Ulrich Weigand was heard to remark:
> 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 puttin
Linas Vepstas wrote:
On Sat, Nov 09, 2002 at 08:01:55PM +0100, Ulrich Weigand was heard to
remark:
>> Just use mmap, and use file access rights to protect the data.
>
>How can a library get read-write access to a file, while preventing
>the app from writing to the same file?
Of course you need tw
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
General Obi-Wan Kenobi )
(This company 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: [LIN
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 sta
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'
>
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 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 fe
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 u
inal Message-
> From: Linux on 390 Port [mailto:LINUX-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
Linux on 390 Port [mailto:LINUX-390@;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
Folks,
This is known territory, both in implementation and literature. Both
Multics and MTS implemented a similar architecture to what Linus V. is
describing, and Apollo did an implementation with distributed memory in
NCS. I'd suggest doing some reading before you go off to design a CPU
-- we've
2002 12:57 PM
To: [EMAIL PROTECTED]
Subject: Re: CPU Arch Security [was: Re: Probably the first published
shell code]
-snip-
It has been years since I last looked at the 390 instruction set. Can't one
set a read-only mode for selected PSW keys?
> -Original Message-
> From: Post, Mark K [mailto:mark.post@;eds.com]
> Sent: Monday, November 11, 2002 1:28 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CPU Arch Security [was: Re: Probably the first
> published shel l code]
>
>
> Linas,
>
> No. Eithe
ECTED]
"Post, Mark K" cc: (bcc: Michael Short/Towers
Perrin)
<[EMAIL PROTECTED] Subject: Re: CPU Arch Security [was:
al Message-
> From: Linas Vepstas [mailto:linas@;linas.org]
> Sent: Monday, November 11, 2002 12:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CPU Arch Security [was: Re: Probably the first published
> shell code]
>
>
> -snip-
> It has been years since I last looked at the 390
er 11, 2002 12:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CPU Arch Security [was: Re: Probably the first published
> shell code]
>
>
> -snip-
> It has been years since I last looked at the 390 instruction set. Can't one
> set a read-only mode for selected PSW keys?
>
65 matches
Mail list logo
