Le 21 Feb 2001 01:13:03 +0100, Andreas Bombe a écrit :
> On Tue, Feb 20, 2001 at 10:09:55AM +0100, Xavier Bestel wrote:
> > Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a écrit :
> > > On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
> > > > Peter Samuelson <[EMAIL PROTECTED]>
Le 21 Feb 2001 01:13:03 +0100, Andreas Bombe a crit :
On Tue, Feb 20, 2001 at 10:09:55AM +0100, Xavier Bestel wrote:
Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a crit :
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
It
On Tue, Feb 20, 2001 at 10:09:55AM +0100, Xavier Bestel wrote:
> Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a écrit :
> > On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
> > > Peter Samuelson <[EMAIL PROTECTED]> writes:
> > > > It also sounds like you will be
> > > > breaking
Le 20 Feb 2001 11:40:18 -0500, Jeremy Jackson a écrit :
> Xavier Bestel wrote:
>
> > Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a écrit :
> > >
> > > An array is a word that contains the address of the first element.
> >
> > No. Exercise 3: compile and run this:
> > file a.c:
> > char array[]
Xavier Bestel wrote:
> Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a écrit :
> >
> > An array is a word that contains the address of the first element.
>
> No. Exercise 3: compile and run this:
> file a.c:
> char array[] = "I'm really an array";
>
> file b.c:
> extern char* array;
> main() {
Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a écrit :
> On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
> > Peter Samuelson <[EMAIL PROTECTED]> writes:
> > > It also sounds like you will be
> > > breaking the extremely useful C postulate that, at the ABI level at
> > > least,
Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a crit :
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
It also sounds like you will be
breaking the extremely useful C postulate that, at the ABI level at
least, arrays and
Xavier Bestel wrote:
Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a crit :
An array is a word that contains the address of the first element.
No. Exercise 3: compile and run this:
file a.c:
char array[] = "I'm really an array";
file b.c:
extern char* array;
main() { printf("array =
Le 20 Feb 2001 11:40:18 -0500, Jeremy Jackson a crit :
Xavier Bestel wrote:
Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a crit :
An array is a word that contains the address of the first element.
No. Exercise 3: compile and run this:
file a.c:
char array[] = "I'm really an
On Tue, Feb 20, 2001 at 10:09:55AM +0100, Xavier Bestel wrote:
Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a crit :
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
It also sounds like you will be
breaking the extremely
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
> Peter Samuelson <[EMAIL PROTECTED]> writes:
> > It also sounds like you will be
> > breaking the extremely useful C postulate that, at the ABI level at
> > least, arrays and pointers are equivalent. I can't see *how* you plan
>
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
It also sounds like you will be
breaking the extremely useful C postulate that, at the ABI level at
least, arrays and pointers are equivalent. I can't see *how* you plan
to work
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Manfred Spraul]
> > > Unless you modify the ABI and pass the array bounds around you won't
> > > catch such problems,
>
> [Eric W. Biederman]
> > Of course. But this is linux and you have the source. And I did
> > mention you needed to
> need fat pointers, which would make sizeof (long) /= sizeof (void *),
> which would break quite some software, I think.
There are plenty of architectures where sizeof long != sizeof (void *). If your
code makes bad assumptions and a bounds checking cc breaks it then its progress.
-
To
[Manfred Spraul]
> > Unless you modify the ABI and pass the array bounds around you won't
> > catch such problems,
[Eric W. Biederman]
> Of course. But this is linux and you have the source. And I did
> mention you needed to recompile the libraries your trusted
> applications depended on.
[EMAIL PROTECTED] (Eric W. Biederman) writes:
> There is another much more effective solution in the works. The C
> standard allows bounds checking of arrays.
The C standard does not allow reliable bounds checking on {signed,
unsigned, vanilla} char arrays, because the corresponding pointers
[EMAIL PROTECTED] (Eric W. Biederman) writes:
There is another much more effective solution in the works. The C
standard allows bounds checking of arrays.
The C standard does not allow reliable bounds checking on {signed,
unsigned, vanilla} char arrays, because the corresponding pointers can
[Manfred Spraul]
Unless you modify the ABI and pass the array bounds around you won't
catch such problems,
[Eric W. Biederman]
Of course. But this is linux and you have the source. And I did
mention you needed to recompile the libraries your trusted
applications depended on.
So by
need fat pointers, which would make sizeof (long) /= sizeof (void *),
which would break quite some software, I think.
There are plenty of architectures where sizeof long != sizeof (void *). If your
code makes bad assumptions and a bounds checking cc breaks it then its progress.
-
To
Peter Samuelson [EMAIL PROTECTED] writes:
[Manfred Spraul]
Unless you modify the ABI and pass the array bounds around you won't
catch such problems,
[Eric W. Biederman]
Of course. But this is linux and you have the source. And I did
mention you needed to recompile the
Manfred Spraul <[EMAIL PROTECTED]> writes:
> "Eric W. Biederman" wrote:
> >
> > But the gcc bounds checking work is the ultimate buffer overflow fix.
> > You can recompile all of your trusted applications, and libraries with
> > it and be safe from one source of bugs.
> >
>
> void main(int
"Eric W. Biederman" wrote:
> Jeremy Jackson <[EMAIL PROTECTED]> writes:
>
> > "Eric W. Biederman" wrote
> No. I'm not talking about stack-guard patches. I'm talking about bounds checking.
Sorry, I was quite incoherent. Many others have pointed out that there exist
patches for
"Eric W. Biederman" wrote:
>
> But the gcc bounds checking work is the ultimate buffer overflow fix.
> You can recompile all of your trusted applications, and libraries with
> it and be safe from one source of bugs.
>
void main(int argc, char **argv[])
{
char local[128];
if(argc
Jeremy Jackson <[EMAIL PROTECTED]> writes:
> "Eric W. Biederman" wrote:
>
> > Jeremy Jackson <[EMAIL PROTECTED]> writes:
> > (about non-executable stack)
> >
> > There is another much more effective solution in the works. The C
> > standard allows bounds checking of arrays. So it is quite
Jeremy Jackson [EMAIL PROTECTED] writes:
"Eric W. Biederman" wrote:
Jeremy Jackson [EMAIL PROTECTED] writes:
(about non-executable stack)
There is another much more effective solution in the works. The C
standard allows bounds checking of arrays. So it is quite possible
for the
"Eric W. Biederman" wrote:
But the gcc bounds checking work is the ultimate buffer overflow fix.
You can recompile all of your trusted applications, and libraries with
it and be safe from one source of bugs.
void main(int argc, char **argv[])
{
char local[128];
if(argc 2)
"Eric W. Biederman" wrote:
Jeremy Jackson [EMAIL PROTECTED] writes:
"Eric W. Biederman" wrote
No. I'm not talking about stack-guard patches. I'm talking about bounds checking.
Sorry, I was quite incoherent. Many others have pointed out that there exist
patches for non-executatble
Manfred Spraul [EMAIL PROTECTED] writes:
"Eric W. Biederman" wrote:
But the gcc bounds checking work is the ultimate buffer overflow fix.
You can recompile all of your trusted applications, and libraries with
it and be safe from one source of bugs.
void main(int argc, char
> Is there any documentation of the kernel's 'capabilities' functions? It
> would be exceedingly cool if services (named, nfs, etc)
> could be updated to use this; I think crackers would loose some motivation
> if instead of "hey I can totally rule this box!"
> they have to settle for "hey I
"Eric W. Biederman" wrote:
> Jeremy Jackson <[EMAIL PROTECTED]> writes:
> (about non-executable stack)
>
> There is another much more effective solution in the works. The C
> standard allows bounds checking of arrays. So it is quite possible
> for the compiler itself to check this in a
Jeremy Jackson <[EMAIL PROTECTED]> writes:
> Greetings. This is my first post on linux-kernel, I hope this is
> appropriate.
>
> The recent CERT IN-2001-01 's massive repercussions and CA-2001-02's
> re-releasing
> old material in an attempt to coerce admins to update their OS, has led
> me to
Jeremy Jackson [EMAIL PROTECTED] writes:
Greetings. This is my first post on linux-kernel, I hope this is
appropriate.
The recent CERT IN-2001-01 's massive repercussions and CA-2001-02's
re-releasing
old material in an attempt to coerce admins to update their OS, has led
me to think
"Eric W. Biederman" wrote:
Jeremy Jackson [EMAIL PROTECTED] writes:
(about non-executable stack)
There is another much more effective solution in the works. The C
standard allows bounds checking of arrays. So it is quite possible
for the compiler itself to check this in a combination of
Is there any documentation of the kernel's 'capabilities' functions? It
would be exceedingly cool if services (named, nfs, etc)
could be updated to use this; I think crackers would loose some motivation
if instead of "hey I can totally rule this box!"
they have to settle for "hey I can
On Tue, 13 Feb 2001, Jeremy Jackson wrote:
> Next, gcc doesn't generate any code which would be placed in the
> stack, nor does it generate any calls/jumps to the stack area.
Unfortunately, you can't count on this. Objective C, for one, requires an
executable stack.
While there have been
On Tue, 13 Feb 2001 21:22:26 + (GMT)
James Sutherland <[EMAIL PROTECTED]> wrote:
> On Tue, 13 Feb 2001, Jeremy Jackson wrote:
>
> (Long description of how to create a non-executable stack on x86)
>
> ISTR there is a patch which does this for Linux, though??
See:
On Tue, 13 Feb 2001, Jeremy Jackson wrote:
(Long description of how to create a non-executable stack on x86)
I'm afraid you just reinvented the wheel. The idea has been around for a
long time, and it was OK as a quick hack to stop existing exploits
working, but it's possible to modify a buffer
> which are marked
> supervisor-only (is this right?), and definitely don't contain user
> code.
x86 its a fair description. However someone has taken the same theory,
including handling the exceptions and the x86 segment tricks needed to make
it kind of fly. Its not a perfect cure but it
Greetings. This is my first post on linux-kernel, I hope this is
appropriate.
The recent CERT IN-2001-01 's massive repercussions and CA-2001-02's
re-releasing
old material in an attempt to coerce admins to update their OS, has led
me to think about
buffer overrun exploits. I have gained a
Greetings. This is my first post on linux-kernel, I hope this is
appropriate.
The recent CERT IN-2001-01 's massive repercussions and CA-2001-02's
re-releasing
old material in an attempt to coerce admins to update their OS, has led
me to think about
buffer overrun exploits. I have gained a
which are marked
supervisor-only (is this right?), and definitely don't contain user
code.
x86 its a fair description. However someone has taken the same theory,
including handling the exceptions and the x86 segment tricks needed to make
it kind of fly. Its not a perfect cure but it works.
On Tue, 13 Feb 2001, Jeremy Jackson wrote:
(Long description of how to create a non-executable stack on x86)
I'm afraid you just reinvented the wheel. The idea has been around for a
long time, and it was OK as a quick hack to stop existing exploits
working, but it's possible to modify a buffer
On Tue, 13 Feb 2001 21:22:26 + (GMT)
James Sutherland [EMAIL PROTECTED] wrote:
On Tue, 13 Feb 2001, Jeremy Jackson wrote:
(Long description of how to create a non-executable stack on x86)
ISTR there is a patch which does this for Linux, though??
See:
http://www.openwall.com/linux/
43 matches
Mail list logo
