On Fri, 2005-07-15 at 16:47 +0530, RVK wrote:
> Arjan van de Ven wrote:
> >so it's new? so what? doesn't make it less true that it nowadays is a
> >lot harder to exploit such bugs on recent distros.
> >
> >
> >
> How about using ProPolice etc ?
that's also a good one; gcc 4.1 will have a
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
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 combination of this
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
pointer to the
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
> pointer to the system() library
Brian O'Mahoney wrote:
First there are endless ways of stopping DAMAGE from buffer
over-runs, from code that accepts user data, eg extend buffer, dont
use dangerous strxxx functions so while you can move
stuff to proxies, and that has been done extensively e.g.
for sendmail it is a
Brian O'Mahoney wrote:
First there are endless ways of stopping DAMAGE from buffer
over-runs, from code that accepts user data, eg extend buffer, dont
use dangerous strxxx functions so while you can move
stuff to proxies, and that has been done extensively e.g.
for sendmail it is a
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
pointer to the system() library function.
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
pointer to the
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 combination of this all
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
On Fri, 2005-07-15 at 16:47 +0530, RVK wrote:
Arjan van de Ven wrote:
so it's new? so what? doesn't make it less true that it nowadays is a
lot harder to exploit such bugs on recent distros.
How about using ProPolice etc ?
that's also a good one; gcc 4.1 will have a propolice port
First there are endless ways of stopping DAMAGE from buffer
over-runs, from code that accepts user data, eg extend buffer, dont
use dangerous strxxx functions so while you can move
stuff to proxies, and that has been done extensively e.g.
for sendmail it is a cop-out, far better fix the
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
it on
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
it on to the real server!
Proxies can be a good way of filtering but it can't avoid buffer
overflows. It can only increase it. More code more bugs. If it is
running on a hardware firewall as a service then its more dangerous as
once it is compramised then IDS signatures also can be deleated :-). No
use of IDS the right
RVK wrote:
I don't think buffer overflow has anything to do with transparent
proxy. Transparent proxying is just doing some protocol filtering.
A transparent proxy is a protocol filter, which is why it is an
ideal way of detecting protocol-dependent buffer overflow attacks.
The detection
I don't think buffer overflow has anything to do with transparent proxy.
Transparent proxying is just doing some protocol filtering. Still the
proxy code may have some buffer overflows. The best way is first to try
avoiding any buffer overflows and take programming precautions. Other
way is to
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
overflow string is much longer than what's usual for the app/protocol in
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
overflow string is much longer than what's usual for the app/protocol in
I don't think buffer overflow has anything to do with transparent proxy.
Transparent proxying is just doing some protocol filtering. Still the
proxy code may have some buffer overflows. The best way is first to try
avoiding any buffer overflows and take programming precautions. Other
way is to
RVK wrote:
I don't think buffer overflow has anything to do with transparent
proxy. Transparent proxying is just doing some protocol filtering.
A transparent proxy is a protocol filter, which is why it is an
ideal way of detecting protocol-dependent buffer overflow attacks.
The detection
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
it on to the real server!
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
it on
First there are endless ways of stopping DAMAGE from buffer
over-runs, from code that accepts user data, eg extend buffer, dont
use dangerous strxxx functions so while you can move
stuff to proxies, and that has been done extensively e.g.
for sendmail it is a cop-out, far better fix the
Vinay Venkataraghavan wrote:
Hello,
Hello, *devil's advocate hat on*
I have implemented an bare bones Intrusion detection
system that currently detects scans like open, bouce,
half open etc and a host of other tcp scans.
As an aside, why, we have snort?
I would like to develop this into
> Are there other open source firewall implementations
> other than snort?
>
> I would apprecitate it if you could let me know.
> Thanks,
> Vinay
>
I might be wrong and this might be a stupid answer but... How about
iptables?
iptables blocks everything incomind, allows, deny and forwards, so I
Hello,
I have implemented an bare bones Intrusion detection
system that currently detects scans like open, bouce,
half open etc and a host of other tcp scans.
I would like to develop this into a full blown IDS
which is capable of detecting buffer overflow attacks,
sql injection etc.
I know how
Hello,
I have implemented an bare bones Intrusion detection
system that currently detects scans like open, bouce,
half open etc and a host of other tcp scans.
I would like to develop this into a full blown IDS
which is capable of detecting buffer overflow attacks,
sql injection etc.
I know how
Are there other open source firewall implementations
other than snort?
I would apprecitate it if you could let me know.
Thanks,
Vinay
I might be wrong and this might be a stupid answer but... How about
iptables?
iptables blocks everything incomind, allows, deny and forwards, so I think
Vinay Venkataraghavan wrote:
Hello,
Hello, *devil's advocate hat on*
I have implemented an bare bones Intrusion detection
system that currently detects scans like open, bouce,
half open etc and a host of other tcp scans.
As an aside, why, we have snort?
I would like to develop this into
35 matches
Mail list logo
