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 propoli
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 comb
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 comb
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 comb
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 sy
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 funct
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 cop-out,
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 applic
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 t
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! The
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 code
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:
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 a
> 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 th
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
18 matches
Mail list logo
