Arjan van de Ven wrote:
On Fri, 2005-07-15 at 13:56 +0530, RVK wrote:
except this is no longer true really ;)
randomisation for example makes this a lot harder to do.
gcc level tricks to prevent buffer overflows are widely in use nowadays
too (FORTIFY_SOURCE and -fstack-protector). The
Arjan van de Ven wrote:
On Fri, 2005-07-15 at 13:56 +0530, RVK wrote:
except this is no longer true really ;)
randomisation for example makes this a lot harder to do.
gcc level tricks to prevent buffer overflows are widely in use nowadays
too (FORTIFY_SOURCE and -fstack-protector). The
Arjan van de Ven wrote:
On Fri, 2005-07-15 at 13:56 +0530, RVK wrote:
except this is no longer true really ;)
randomisation for example makes this a lot harder to do.
gcc level tricks to prevent buffer overflows are widely in use nowadays
too (FORTIFY_SOURCE and -fstack-protector). The
Arjan van de Ven wrote:
On Fri, 2005-07-15 at 12:11 +0530, RVK wrote:
Even in the presence of non-executable stack, Linux Torvalds explains
that "It's really easy. You do something like this: 1) overflow the
buffer on the stack, so that the return value is overwritten by a
poin
he above exploit. It
probably takes all of five lines of changes to some existing exploit,
and some random program to find out where in the address space the
shared libraries tend to be loaded."
rvk
but your system is not compromised.
One final point, in practice, you get lots of unw
J.A. Magallon wrote:
On 07.14, RVK wrote:
Ian Campbell wrote:
On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
Ian Campbell wrote:
What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way, it is just a "thing&q
Helge Hafting wrote:
RVK wrote:
Proxies can be a good way of filtering but it can't avoid buffer
overflows.
Yes they can - did you read and udnerstand my previous post at all?
A proxy _can_ avoid a buffer overflow by noticing the
anomalously large data item and simply refuse to pass
ot of applications using that.
rvk
Jakub
-
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/
right ?
So the best way is either make your code free of buffer overflows or use
some library which controls the attack during any buffer overflow or use
Stack Randomisation and Canary based approaches.
rvk
Helge Hafting wrote:
RVK wrote:
I don't think buffer overflow has anything
Ian Campbell wrote:
On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
Ian Campbell wrote:
What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way, it is just a "thing" which you can
pass back to the API, that pthread_t hap
Arjan van de Ven wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
it doesn't return a number it returns a pointer ;) or a floating point
number. You don't know :)
what it returns is a *cookie*. A cookie that you can only use to pass
back to various pthread functions.
Ian Campbell wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this means tha
DS to
detect these attacks accurately.
rvk
Helge Hafting wrote:
Vinay Venkataraghavan wrote:
I know how to implement buffer overflow attacks. But
how would an intrusion detection system detect a
buffer overflow attack.
Buffer overflow attacks vary, but have one thing in common. The
ove
Arjan van de Ven wrote:
On Thu, 2005-07-14 at 11:03 +0530, RVK wrote:
Robert Hancock wrote:
RVK wrote:
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
What do you mean, negative integer
Robert Hancock wrote:
RVK wrote:
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
What do you mean, negative integer? It's not an integer, it's a
pthread_t, you're not even supposed to look at
You are right Bengettid() will do for me. Previously for 2.4.x
(2.4.18)thread libraries I normally was using pthread_self().
Raghu
Benedikt Spranger wrote:
Hi,
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
thanks
rvk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
17 matches
Mail list logo
