Re: Is this the ultimate stack-smash fix?
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 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 around that one.
> > > >
> > > > Huh? Pointers and arrays are clearly different at the ABI level.
> > > >
> > > > A pointer is a word that contains an address of something.
> > > > An array is an array.
> > >
> > > 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 = %s\n", array); }
> >
> > ... and watch it biting the dust !
>
> Deliberately linking to the wrong symbol is not a point. Might as well
> replace file a.c with "int array = 0;". That'll also bite the dust. So?
>
> > in short: an array is NOT a pointer.
>
> In this context we were talking *function calls*, not confusing the
> linker. And whether you say "char array[];" or "char *const array;",
> array is a pointer. Even more so at the ABI = function call interface.
OK, I missed this. There are no arrays in the function call interface,
they are promoted to pointers.
Xav
-
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: Is this the ultimate stack-smash fix?
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 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 around that one.
Huh? Pointers and arrays are clearly different at the ABI level.
A pointer is a word that contains an address of something.
An array is an array.
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 = %s\n", array); }
... and watch it biting the dust !
Deliberately linking to the wrong symbol is not a point. Might as well
replace file a.c with "int array = 0;". That'll also bite the dust. So?
in short: an array is NOT a pointer.
In this context we were talking *function calls*, not confusing the
linker. And whether you say "char array[];" or "char *const array;",
array is a pointer. Even more so at the ABI = function call interface.
OK, I missed this. There are no arrays in the function call interface,
they are promoted to pointers.
Xav
-
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: Is this the ultimate stack-smash fix?
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 useful C postulate that, at the ABI level at
> > > > least, arrays and pointers are equivalent. I can't see *how* you plan
> > > > to work around that one.
> > >
> > > Huh? Pointers and arrays are clearly different at the ABI level.
> > >
> > > A pointer is a word that contains an address of something.
> > > An array is an array.
> >
> > 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 = %s\n", array); }
>
> ... and watch it biting the dust !
Deliberately linking to the wrong symbol is not a point. Might as well
replace file a.c with "int array = 0;". That'll also bite the dust. So?
> in short: an array is NOT a pointer.
In this context we were talking *function calls*, not confusing the
linker. And whether you say "char array[];" or "char *const array;",
array is a pointer. Even more so at the ABI = function call interface.
Another try: Assume that
#include "secret.h"
int main() { printf("array = %s\n", array); return 0; }
is correct code.
Is the variable array a pointer to a char or an array of chars?
Oh well, who cares.
--
Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
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: Is this the ultimate stack-smash fix?
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 array";
> >
> > file b.c:
> > extern char* array;
> > main() { printf("array = %s\n", array); }
> >
>
> try file b.c
> extern char array;
> main() { printf("array= %s\n", ); }
So ?
-
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: Is this the ultimate stack-smash fix?
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 = %s\n", array); }
>
try file b.c
extern char array;
main() { printf("array= %s\n", ); }
?
>
> ... and watch it biting the dust !
> in short: an array is NOT a pointer.
-
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: Is this the ultimate stack-smash fix?
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 pointers are equivalent. I can't see *how* you plan
> > > to work around that one.
> >
> > Huh? Pointers and arrays are clearly different at the ABI level.
> >
> > A pointer is a word that contains an address of something.
> > An array is an array.
>
> 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 = %s\n", array); }
... and watch it biting the dust !
in short: an array is NOT a pointer.
Xav
-
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: Is this the ultimate stack-smash fix?
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 pointers are equivalent. I can't see *how* you plan
to work around that one.
Huh? Pointers and arrays are clearly different at the ABI level.
A pointer is a word that contains an address of something.
An array is an array.
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 = %s\n", array); }
... and watch it biting the dust !
in short: an array is NOT a pointer.
Xav
-
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: Is this the ultimate stack-smash fix?
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 = %s\n", array); }
try file b.c
extern char array;
main() { printf("array= %s\n", array); }
?
... and watch it biting the dust !
in short: an array is NOT a pointer.
-
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: Is this the ultimate stack-smash fix?
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 array";
file b.c:
extern char* array;
main() { printf("array = %s\n", array); }
try file b.c
extern char array;
main() { printf("array= %s\n", array); }
So ?
-
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: Is this the ultimate stack-smash fix?
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 useful C postulate that, at the ABI level at
least, arrays and pointers are equivalent. I can't see *how* you plan
to work around that one.
Huh? Pointers and arrays are clearly different at the ABI level.
A pointer is a word that contains an address of something.
An array is an array.
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 = %s\n", array); }
... and watch it biting the dust !
Deliberately linking to the wrong symbol is not a point. Might as well
replace file a.c with "int array = 0;". That'll also bite the dust. So?
in short: an array is NOT a pointer.
In this context we were talking *function calls*, not confusing the
linker. And whether you say "char array[];" or "char *const array;",
array is a pointer. Even more so at the ABI = function call interface.
Another try: Assume that
#include "secret.h"
int main() { printf("array = %s\n", array); return 0; }
is correct code.
Is the variable array a pointer to a char or an array of chars?
Oh well, who cares.
--
Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
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: Is this the ultimate stack-smash fix?
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 around that one. > > Huh? Pointers and arrays are clearly different at the ABI level. > > A pointer is a word that contains an address of something. > An array is an array. An array is a word that contains the address of the first element. Exercise 1: What is the difference between the following two declarations at the source level and at the ABI level? a) int main(int argc, char *argv[]) b) int main(int argc, char **argv) Exercise 2: What would the following in hypothetical C startup code do? char *args[10]; int count = 10; ... exit(main(count - 1, args + 1)); -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - 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: Is this the ultimate stack-smash fix?
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 around that one. Huh? Pointers and arrays are clearly different at the ABI level. A pointer is a word that contains an address of something. An array is an array. An array is a word that contains the address of the first element. Exercise 1: What is the difference between the following two declarations at the source level and at the ABI level? a) int main(int argc, char *argv[]) b) int main(int argc, char **argv) Exercise 2: What would the following in hypothetical C startup code do? char *args[10]; int count = 10; ... exit(main(count - 1, args + 1)); -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - 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: Is this the ultimate stack-smash fix?
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 libraries your trusted > > applications depended on. > > So by what ABI do you propose to pass array bounds to a called > function? It sounds pretty ugly. Not especially. In cases you can't optimize pointers become tuples of . > 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 around that one. Huh? Pointers and arrays are clearly different at the ABI level. A pointer is a word that contains an address of something. An array is an array. There is an implicit promotion from one to the other at the source level, but that has little to do with the application binary interface. > > Yep bounds checking is not an easy fix. > > Understatement of the year, if you really want to catch all cases. No, it's more of a large mechanical job than truly hard problem. The real challenge lies in optimizing out the checks so you don't penalize the inner loops of code. Eric - 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: Is this the ultimate stack-smash fix?
> 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 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: Is this the ultimate stack-smash fix?
[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 what ABI do you propose to pass array bounds to a called function? It sounds pretty ugly. 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 around that one. > Yep bounds checking is not an easy fix. Understatement of the year, if you really want to catch all cases. Peter - 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: Is this the ultimate stack-smash fix?
[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
address the individual bytes in each object, even the object which
follows the array. To implement things in an efficient manner, you
need fat pointers, which would make sizeof (long) /= sizeof (void *),
which would break quite some software, I think.
IMHO, C is a hopeless case in this area. Fortunately, there is a
number of other programming languages out there which do permit proper
bounds checking on arrays (and have strong, static typing and other
gizmos which make shooting yourself into the foot unintentionally a
bit more difficult).
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
-
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: Is this the ultimate stack-smash fix?
[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
address the individual bytes in each object, even the object which
follows the array. To implement things in an efficient manner, you
need fat pointers, which would make sizeof (long) /= sizeof (void *),
which would break quite some software, I think.
IMHO, C is a hopeless case in this area. Fortunately, there is a
number of other programming languages out there which do permit proper
bounds checking on arrays (and have strong, static typing and other
gizmos which make shooting yourself into the foot unintentionally a
bit more difficult).
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
-
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: Is this the ultimate stack-smash fix?
[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 what ABI do you propose to pass array bounds to a called function? It sounds pretty ugly. 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 around that one. Yep bounds checking is not an easy fix. Understatement of the year, if you really want to catch all cases. Peter - 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: Is this the ultimate stack-smash fix?
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 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: Is this the ultimate stack-smash fix?
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 libraries your trusted applications depended on. So by what ABI do you propose to pass array bounds to a called function? It sounds pretty ugly. Not especially. In cases you can't optimize pointers become tuples of pointer to the array, pointer one past the end of the array, real pointer. 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 around that one. Huh? Pointers and arrays are clearly different at the ABI level. A pointer is a word that contains an address of something. An array is an array. There is an implicit promotion from one to the other at the source level, but that has little to do with the application binary interface. Yep bounds checking is not an easy fix. Understatement of the year, if you really want to catch all cases. No, it's more of a large mechanical job than truly hard problem. The real challenge lies in optimizing out the checks so you don't penalize the inner loops of code. Eric - 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: Is this the ultimate stack-smash fix?
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 **argv[])
> {
> char local[128];
> if(argc > 2)
> strcpy(local,argv[1]);
> }
>
> Unless you modify the ABI and pass the array bounds around you won't
> catch such problems,
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.
> and I won't even mention unions and
>
> struct dyn_data {
> int len;
> char data[];
> }
Yep bounds checking is not an easy fix. But it is a good fix.
Eric
-
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: Is this the ultimate stack-smash fix?
"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 stack, and the problems with it. That's what I meant to comment on. But I'm glad to find out about bounds checking as an option. > 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. That's why I was wondering of limiting privileged addresses security at a more fundamental level... as you say above, this fixes *ONE* source of bugs(security threats)... but itn't it inevitable that there will be others? But if services are each put in a separate box, that doesn't have a door leading to the inner sanctum, things would be more secure in spite of "bugs". Well I thank everyone for their responses in this thread, I think It's been beaten into the ground (my original idea), and I'm left with some food for thought. - 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: Is this the ultimate stack-smash fix?
"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)
strcpy(local,argv[1]);
}
Unless you modify the ABI and pass the array bounds around you won't
catch such problems, and I won't even mention unions and
struct dyn_data {
int len;
char data[];
}
--
Manfred
-
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: Is this the ultimate stack-smash fix?
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 compiler itself to check this in a combination of run-time and > > compile-time checks. I haven't followed up but not too long ago > > there was an effort to add this as an option to gcc. If you really > > want this fixed that is the direction to go. Then buffer overflow > > exploits become virtually impossible. > > > > I've thought some more, and yes someone else has already done this. Problems > are with compilers that > put code on stack (g++ trampolines for local functions i think). There is > the gcc-mod (Stack-guard?) that checks for > corrupt stack frame using magic number containing zeros before returning... > this will take away some > performance though... No. I'm not talking about stack-guard patches. I'm talking about bounds checking. The difference here is that if correct code is generated you won't overflow any buffer at all period. The compiler will either prove at compile time that it can't happen (The efficient case). Or it will generate pointers as tuples into chunks of memory. And it will do runtime checks that will that will kill your program if it overflows the stack. I think the gcc options is -fcheck or something like that. I haven't had a chance to follow up, since I saw that someone was actually working on it. Since compilers bugs happen buffer overflow exploits are still possible but it means two separate programmers must mess up in complimentary ways. As for fine grain privileges they can help, but the real fix is to keep the programs that need raised privileges down to one function. Letting you look at the program and see if it is obviously correct with no security bugs. 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. Eric - 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: Is this the ultimate stack-smash fix?
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 compiler itself to check this in a combination of run-time and compile-time checks. I haven't followed up but not too long ago there was an effort to add this as an option to gcc. If you really want this fixed that is the direction to go. Then buffer overflow exploits become virtually impossible. I've thought some more, and yes someone else has already done this. Problems are with compilers that put code on stack (g++ trampolines for local functions i think). There is the gcc-mod (Stack-guard?) that checks for corrupt stack frame using magic number containing zeros before returning... this will take away some performance though... No. I'm not talking about stack-guard patches. I'm talking about bounds checking. The difference here is that if correct code is generated you won't overflow any buffer at all period. The compiler will either prove at compile time that it can't happen (The efficient case). Or it will generate pointers as start,length,offset tuples into chunks of memory. And it will do runtime checks that will that will kill your program if it overflows the stack. I think the gcc options is -fcheck or something like that. I haven't had a chance to follow up, since I saw that someone was actually working on it. Since compilers bugs happen buffer overflow exploits are still possible but it means two separate programmers must mess up in complimentary ways. As for fine grain privileges they can help, but the real fix is to keep the programs that need raised privileges down to one function. Letting you look at the program and see if it is obviously correct with no security bugs. 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. Eric - 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: Is this the ultimate stack-smash fix?
"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)
strcpy(local,argv[1]);
}
Unless you modify the ABI and pass the array bounds around you won't
catch such problems, and I won't even mention unions and
struct dyn_data {
int len;
char data[];
}
--
Manfred
-
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: Is this the ultimate stack-smash fix?
"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 stack, and the problems with it. That's what I meant to comment on. But I'm glad to find out about bounds checking as an option. 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. That's why I was wondering of limiting privileged addresses security at a more fundamental level... as you say above, this fixes *ONE* source of bugs(security threats)... but itn't it inevitable that there will be others? But if services are each put in a separate box, that doesn't have a door leading to the inner sanctum, things would be more secure in spite of "bugs". Well I thank everyone for their responses in this thread, I think It's been beaten into the ground (my original idea), and I'm left with some food for thought. - 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: Is this the ultimate stack-smash fix?
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 **argv[])
{
char local[128];
if(argc 2)
strcpy(local,argv[1]);
}
Unless you modify the ABI and pass the array bounds around you won't
catch such problems,
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.
and I won't even mention unions and
struct dyn_data {
int len;
char data[];
}
Yep bounds checking is not an easy fix. But it is a good fix.
Eric
-
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: Is this the ultimate stack-smash fix?
> 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 make the ident service report user 'CrAp' > for every port!". Named and proftpd are already updated to use this.. check the source for the best documentation ... Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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: Is this the ultimate stack-smash fix?
"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 run-time and > compile-time checks. I haven't followed up but not too long ago > there was an effort to add this as an option to gcc. If you really > want this fixed that is the direction to go. Then buffer overflow > exploits become virtually impossible. > I've thought some more, and yes someone else has already done this. Problems are with compilers that put code on stack (g++ trampolines for local functions i think). There is the gcc-mod (Stack-guard?) that checks for corrupt stack frame using magic number containing zeros before returning... this will take away some performance though... I wonder if the root of the issue is the underlying security architechure ... anything that needs ANY privilege gets ALL privileges (ie root). chown named and such fixes this, but can't rebind to privileged port, must be restarted by root to do so. VMS / NT have more fine grained privileges. 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 make the ident service report user 'CrAp' for every port!". - 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: Is this the ultimate stack-smash fix?
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 about > buffer overrun exploits. I have gained a new appreciation after being > rooted twice this month. > > I believe there is a solution that can be implemented in the kernel > (Linux and probably most Unix) > that can prevent this type of exploit, has no effect on userspace code, > and is minimally obtrusive > for the kernel. 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 run-time and compile-time checks. I haven't followed up but not too long ago there was an effort to add this as an option to gcc. If you really want this fixed that is the direction to go. Then buffer overflow exploits become virtually impossible. Eric - 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: Is this the ultimate stack-smash fix?
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 about buffer overrun exploits. I have gained a new appreciation after being rooted twice this month. I believe there is a solution that can be implemented in the kernel (Linux and probably most Unix) that can prevent this type of exploit, has no effect on userspace code, and is minimally obtrusive for the kernel. 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 run-time and compile-time checks. I haven't followed up but not too long ago there was an effort to add this as an option to gcc. If you really want this fixed that is the direction to go. Then buffer overflow exploits become virtually impossible. Eric - 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: Is this the ultimate stack-smash fix?
"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 run-time and compile-time checks. I haven't followed up but not too long ago there was an effort to add this as an option to gcc. If you really want this fixed that is the direction to go. Then buffer overflow exploits become virtually impossible. I've thought some more, and yes someone else has already done this. Problems are with compilers that put code on stack (g++ trampolines for local functions i think). There is the gcc-mod (Stack-guard?) that checks for corrupt stack frame using magic number containing zeros before returning... this will take away some performance though... I wonder if the root of the issue is the underlying security architechure ... anything that needs ANY privilege gets ALL privileges (ie root). chown named and such fixes this, but can't rebind to privileged port, must be restarted by root to do so. VMS / NT have more fine grained privileges. 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 make the ident service report user 'CrAp' for every port!". - 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: Is this the ultimate stack-smash fix?
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 make the ident service report user 'CrAp' for every port!". Named and proftpd are already updated to use this.. check the source for the best documentation ... Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - 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: Is this the ultimate stack-smash fix?
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 "unofficial" patches (Solar Designer) to lock out executing the stack for a long time, and it does work in most cases, this isn't really doable as a general solution. - 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: Is this the ultimate stack-smash fix?
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/ for Solar Designer's patch, and: http://www.insecure.org/sploits/non-executable.stack.problems.html for the exploit. It was done to death on the linux-security ML a while ago, so you could search the archives if you want to know more. -- Bruce Harada [EMAIL PROTECTED] - 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: Is this the ultimate stack-smash fix?
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 overflow exploit to work around this. It does sound look like a good idea, but it doesn't really gain you anything in the long run: the exploits just change a bit. ISTR there is a patch which does this for Linux, though?? James. - 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: Is this the ultimate stack-smash fix?
> 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. Search for Solar Designer and non executable stack. - 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: Is this the ultimate stack-smash fix?
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. Search for Solar Designer and non executable stack. - 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: Is this the ultimate stack-smash fix?
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 overflow exploit to work around this. It does sound look like a good idea, but it doesn't really gain you anything in the long run: the exploits just change a bit. ISTR there is a patch which does this for Linux, though?? James. - 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: Is this the ultimate stack-smash fix?
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/ for Solar Designer's patch, and: http://www.insecure.org/sploits/non-executable.stack.problems.html for the exploit. It was done to death on the linux-security ML a while ago, so you could search the archives if you want to know more. -- Bruce Harada [EMAIL PROTECTED] - 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/
