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
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
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
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 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 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, 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, 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
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 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
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 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
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 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
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, 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
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 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
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.
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
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
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, 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)?
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
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
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
ecurity [was: Re: 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 f
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
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 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
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 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 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
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 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
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, 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
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 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
> > 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
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
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 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 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.)
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
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:
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
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, 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, 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
> 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
51 matches
Mail list logo
