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]> wr
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() { pri
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, a
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
>
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 recompil
> 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 unsubscr
[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 ca
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
"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
"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 poss
> 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
"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 combinat
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
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 "unof
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/li
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 o
> 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.
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
22 matches
Mail list logo
