Open source firewalls

Open source firewalls

[Vinay Venkataraghavan]

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 to implement buffer overflow attacks. But
how would an intrusion detection system detect a
buffer overflow attack. My question is at the layer
that the intrusion detection system operates, how will
it know that a particular string for exmaple is liable
to overflow a vulnerable buffer. 

Are there other open source firewall implementations
other than snort?

I would apprecitate it if you could let me know.
Thanks,
Vinay



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250

RE: Open source firewalls

[Alejandro Bonilla]

> 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
that is what you want?

.Alejandro

Re: Open source firewalls

[Maciej Soltysiak]

>> Are there other open source firewall implementations
>> other than snort?
> 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
> that is what you want?
Well iptables (which allows you to simply build firewall rulesets)
is the user-space part of the packet filter called netfilter in linux.
What it does (blocks or allows) is always up to the user, as with all firewalls,
except the majority of dummy windows firewalls and dummy linux scripts)

Others are of course in freebsd, netbsd, openbsd, opensolaris :-)

It really usually is a mixture of both kernel- and user-space code.

Regards,
Maciej

Re: Open source firewalls

[Nigel Rantor]

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 full blown IDS
> which is capable of detecting buffer overflow attacks,
> sql injection etc. 
> 
> I know how to implement buffer overflow attacks. But
> how would an intrusion detection system detect a
> buffer overflow attack. My question is at the layer
> that the intrusion detection system operates, how will
> it know that a particular string for exmaple is liable
> to overflow a vulnerable buffer. 

Erm, if you know how some buffer overflow attacks work then surely the 
answer is "it depends on the application". To tell if an application is 
vulnerable you would have to audit it in some manner. Either by checking 
the source or doing some black-box testing on it.

Even if you did have a great big database of apps and had identifed 
which of them had possible vulnerabilities it would be easier to simply 
fix them rather than get an external system to disallow such inputs.

And not forgetting that you would have to have some way for your IDS to 
tell what app was running behind a specific port. Thought about that yet?

> Are there other open source firewall implementations
> other than snort?

Snort isn't a firewall. Don't mix apples and oranges. Snort is an IDS. 
The current de-facto "firewall" for linux is the iptables suite.

Cheers,

   n

Re: Open source firewalls

[Helge Hafting]

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 
question.  It may also contain illegal characters, but be careful - 
non-english users use plenty of valid non-ascii characters in filenames,
passwords and so on.

The way to do this is to implement a transparent proxy module for every 
protocol you want to do overflow prevention for.  Collect the strings
transmitted, pass them on after validating them.  Or reset the 
connection when one gets "too long".  For example, you may want to
limit POP usernames to whatever the maximum username length is
on your system.  But make such things configurable, others may
want longer usernames than you.

>My question is at the layer
>that the intrusion detection system operates, how will
>it know that a particular string for exmaple is liable
>to overflow a vulnerable buffer. 
>
>  
>
It can't know of course, but it can suspect that 1000-character
usernames, passwords or filenames is foul play and reset the
connection.  Or 10k URL's . . .

Helge Hafting

Re: Open source firewalls

[RVK]

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 chroot the services, if running it on a firewall. There are 
various mechanisms which can be used like bounding the memory region it 
self. Stack Randomisation and Canary based approaches can also avoid any 
buffer overflow attacks.
IDS runs on L7, best example is snort. Its not possible for IDS 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
> overflow string is much longer than what's usual for the app/protocol in
> question.  It may also contain illegal characters, but be careful -
> non-english users use plenty of valid non-ascii characters in filenames,
> passwords and so on.
>
> The way to do this is to implement a transparent proxy module for every
> protocol you want to do overflow prevention for.  Collect the strings
> transmitted, pass them on after validating them.  Or reset the
> connection when one gets "too long".  For example, you may want to
> limit POP usernames to whatever the maximum username length is
> on your system.  But make such things configurable, others may
> want longer usernames than you.
>
>> My question is at the layer
>> that the intrusion detection system operates, how will
>> it know that a particular string for exmaple is liable
>> to overflow a vulnerable buffer.
>>
>>
>>
> It can't know of course, but it can suspect that 1000-character
> usernames, passwords or filenames is foul play and reset the
> connection.  Or 10k URL's . . .
>
> Helge Hafting
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> .
>

Re: Open source firewalls

[Helge Hafting]

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 have to be built into the proxy, of course.

Examples:
A web proxy can check for anomalous long "get" request,
there have been web servers with buffer overflows when the
URL was too long.  The proxy can terminate such connections,
protecting the possibly vulnerable webserver.

An ftp proxy can check for (and remove) anomalous long filenames,
as well as funnies like "ls */*/*/*/*/*"

Similiar for many other services.  The proxy approach is useful
because knowledge of the protocol is necessary.  After all,
it is ok to up/download a huge file via ftp, while a 2M filename
is suspicious.  Size alone is not enough.

> Still the proxy code may have some buffer overflows. 

A proxy (or any other attempt at a firewall) may have its own
holes of course, but avoiding making them isn't that hard.


> The best way is first to try avoiding any buffer overflows and take 
> programming precautions. 

Of course, if you have the source and that source isn't an
unmaintainable mess.  One or both of those conditions may fail,
and then the IDS becomes useful.

> Other way is to chroot the services, if running it on a firewall. 

Provided it is an unixish server . . .

> There are various mechanisms which can be used like bounding the 
> memory region it self. Stack Randomisation and Canary based approaches 
> can also avoid any buffer overflow attacks.

These may or may not be available.  You can always stick a proxy
firewall in front of the server though, no matter what os and
server apps it runs.

Helge Hafting

Re: Open source firewalls

[RVK]

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 ?
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 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 have to be built into the proxy, of course.
>
> Examples:
> A web proxy can check for anomalous long "get" request,
> there have been web servers with buffer overflows when the
> URL was too long.  The proxy can terminate such connections,
> protecting the possibly vulnerable webserver.
>
> An ftp proxy can check for (and remove) anomalous long filenames,
> as well as funnies like "ls */*/*/*/*/*"
>
> Similiar for many other services.  The proxy approach is useful
> because knowledge of the protocol is necessary.  After all,
> it is ok to up/download a huge file via ftp, while a 2M filename
> is suspicious.  Size alone is not enough.
>
>> Still the proxy code may have some buffer overflows.
>
>
> A proxy (or any other attempt at a firewall) may have its own
> holes of course, but avoiding making them isn't that hard.
>
>
>> The best way is first to try avoiding any buffer overflows and take
>> programming precautions.
>
>
> Of course, if you have the source and that source isn't an
> unmaintainable mess.  One or both of those conditions may fail,
> and then the IDS becomes useful.
>
>> Other way is to chroot the services, if running it on a firewall.
>
>
> Provided it is an unixish server . . .
>
>> There are various mechanisms which can be used like bounding the
>> memory region it self. Stack Randomisation and Canary based approaches
>> can also avoid any buffer overflow attacks.
>
>
> These may or may not be available.  You can always stick a proxy
> firewall in front of the server though, no matter what os and
> server apps it runs.
>
> Helge Hafting
> .
>

Re: Open source firewalls

[Helge Hafting]

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 proxy can terminate the tcp
connection and throw away the data.

> It can only increase it. More code more bugs. 

Of course the proxy can be buggy too, but it is easier to
avoid problems there:
1. The server was written to perform a service, perhaps with
    security thrown in later.  (Yes, that's bad design.)
    A firewall proxy is written for security, so buffer overflows
    are usually avoided in the firewall proxy itself.  Because this
    is exactly what the firewall writer is thinking about.
2. The proxy may be much smaller and simpler than the server
    it protects, it is therefore much easier to audit for security
    problems.
3. Fixing the server is indeed best, but not necessarily an option.
    It could be proprietary, or written in a unknown language.

> If it is running on a hardware firewall as a service then its more

"Hardware firewall" ???

> dangerous as once it is compramised then IDS signatures also can be 
> deleated :-). No use of IDS the right ?

A compromised firewall is of no use - sure.  So what? That applies
to any firewall, any IDS, or any server for that matter.

> So the best way is either make your code free of buffer overflows or

Yes, but the server may not be "my code" at all.  Can't you see that
problem?  It may very well be someone elses code.  I may not have the
source, or the source may be useless for a number of reasons,
such as:
1. being written in a language I don't understand
2. Have a licence that forbids change
3. Need compilers/tools I don't have
4. Being such a nasty mess that writing a proxy is much easier
    than fixing the bloated ill-designed server code one
    unfortunately depends on for the time being.

In these cases, I can still protect my server with a proxy firewall,
although I can't fix the server itself.

> use some library which controls the attack during any buffer overflow 
> or use Stack Randomisation and Canary based approaches.

A library that controls any buffer overflow doesn't exist at all.

Stack randomization helps but don't solve all cases, the attacker
simply need code to search for randomly moved parts he need, pad with
a few megabytes of NOPs and things like that.  Of course, a proxy
can easily detect megabytes of NOPs and kill that connection . . .

Helge Hafting

Re: Open source firewalls

[RVK]

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 to the real server!  The proxy can terminate the tcp
> connection and throw away the data.
>
Some of the validations can be done at proxy end. But there are more 
invisible scnarios than the simple visible ones. And its definately much 
preferable to use Apache like stuff then using our own........I hope u 
agree with me...
I don't disagree on proxy doing the filtering and validations what I 
mean to say is it can't garantee avoiding buffer overflows. As it itself 
can be a source for it.

>> It can only increase it. More code more bugs.
>
>
> Of course the proxy can be buggy too, but it is easier to
> avoid problems there:
> 1. The server was written to perform a service, perhaps with
>    security thrown in later.  (Yes, that's bad design.)
>    A firewall proxy is written for security, so buffer overflows
>    are usually avoided in the firewall proxy itself.  Because this
>    is exactly what the firewall writer is thinking about.
> 2. The proxy may be much smaller and simpler than the server
>    it protects, it is therefore much easier to audit for security
>    problems.
> 3. Fixing the server is indeed best, but not necessarily an option.
>    It could be proprietary, or written in a unknown language.
>
No. As ur the only user of ur program, means resources is limited to 
visulize all senarios for all protocols. No one would like to keep on 
adding the proxies for the sake of buffer overflow. Is basically taken 
as a facility for filtering.

>> If it is running on a hardware firewall as a service then its more
>
>
> "Hardware firewall" ???
>
Yes embedded firewall. When ur gateway is protected by firewall device. 
Another one is a software firewall sol'n.

>> dangerous as once it is compramised then IDS signatures also can be
>> deleated :-). No use of IDS the right ?
>
>
> A compromised firewall is of no use - sure.  So what? That applies
> to any firewall, any IDS, or any server for that matter.
>
No its not true as one ur frewall is compramised, it can effect other 
services also. But at the same time if any of the servers is compramises 
only that server is effected.

>> So the best way is either make your code free of buffer overflows or
>
>
> Yes, but the server may not be "my code" at all.  Can't you see that
> problem?  It may very well be someone elses code.  I may not have the
> source, or the source may be useless for a number of reasons,
> such as:
> 1. being written in a language I don't understand
> 2. Have a licence that forbids change
> 3. Need compilers/tools I don't have
> 4. Being such a nasty mess that writing a proxy is much easier
>    than fixing the bloated ill-designed server code one
>    unfortunately depends on for the time being.
>
> In these cases, I can still protect my server with a proxy firewall,
> although I can't fix the server itself.
>
Again it will be ur own code with limitation of taking care of all 
scenarios. Take an example....Id we are trying to add a web proxy and 
using apache as our server. Do u say that code written by us will be 
more safe than apache ? :-)

>> use some library which controls the attack during any buffer overflow
>> or use Stack Randomisation and Canary based approaches.
>
>
> A library that controls any buffer overflow doesn't exist at all.
>
Its there and available. Just need to search.

> Stack randomization helps but don't solve all cases, the attacker
> simply need code to search for randomly moved parts he need, pad with
> a few megabytes of NOPs and things like that.  Of course, a proxy
> can easily detect megabytes of NOPs and kill that connection . . .
>
Its not easy to have an attach with Stack Randomization. Like TCP syn 
randomization.

Regards
rvk

> Helge Hafting
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> .
>

Re: Buffer Over-runs, was Open source firewalls

[Brian O'Mahoney]

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 application;

Next, while all buffer over runs are very bad it is only those
that stamp on the stack, overwriting the return address stored
there and implanting viral code to be executed, that are truely
__EVIL__.

To do that you need to know a lot of things, the architecture
ie executing x86 code on a ppc will get you no-where, you must
know, and be able to debug your mal-ware against a stable
target, and this is why the _VERY_ slowly patched Windoze is
so vulnerable, and finally you really need to know the stack
base, top of stack, normally growing downward, and ... be able
to actually run code out of the stack space;

and if any one of these conditions are not true, eg I compiled
sendmail with a newer GCC, stack is not executable, ...

the exploit just fails or crashes an app and then you go after
why?

but your system is not compromised.

One final point, in practice, you get lots of unwanted packets
off the internet, and in general you do not want them on your
internal net, both for performance and security reasons, if you
drop them on your router or firewall then you dont need to
worry if the remote app is mal-ware.

-- 
mit freundlichen Grüßen, Brian.

Re: Buffer Over-runs, was Open source firewalls

[RVK]

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, far better fix the application;
>
>Next, while all buffer over runs are very bad it is only those
>that stamp on the stack, overwriting the return address stored
>there and implanting viral code to be executed, that are truely
>__EVIL__.
>
>To do that you need to know a lot of things, the architecture
>ie executing x86 code on a ppc will get you no-where, you must
>know, and be able to debug your mal-ware against a stable
>target, and this is why the _VERY_ slowly patched Windoze is
>so vulnerable, and finally you really need to know the stack
>base, top of stack, normally growing downward, and ... be able
>to actually run code out of the stack space;
>
>and if any one of these conditions are not true, eg I compiled
>sendmail with a newer GCC, stack is not executable, ...
>
>the exploit just fails or crashes an app and then you go after
>why?
>
>  
>
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. 2) the next four bytes are 
crap (a "return pointer" for the system call, which you don't care 
about) 3) the next four bytes are a pointer to some random place in the 
shared library again that contains the string "/bin/sh" (and yes, just 
do a strings on the thing and you'll find it). Voila. You didn't have to 
write any code, the only thing you needed to know was where the library 
is loaded by default. And yes, it's library-specific, but hey, you just 
select one specific commonly used version to crash. Suddenly you have a 
root shell on the system. So it's not only doable, it's fairly trivial 
to do. In short, anybody who thinks that the non-executable stack gives 
them any real security is very very much living in a dream world. It may 
catch a few attacks for old binaries that have security problems, but 
the basic problem is that the binaries allow you to overwrite their 
stacks. And if they allow that, then they allow the 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 unwanted packets
>off the internet, and in general you do not want them on your
>internal net, both for performance and security reasons, if you
>drop them on your router or firewall then you dont need to
>worry if the remote app is mal-ware.
>
>--
>mit freundlichen Grüßen, Brian.
>
>.
>
>  
>

Re: Buffer Over-runs, was Open source firewalls

[Arjan van de Ven]

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. 2) the next four bytes are 
> crap (a "return pointer" for the system call, which you don't care 
> about) 3) the next four bytes are a pointer to some random place in the 
> shared library again that contains the string "/bin/sh" (and yes, just 
> do a strings on the thing and you'll find it). Voila. You didn't have to 
> write any code, the only thing you needed to know was where the library 
> is loaded by default. And yes, it's library-specific, but hey, you just 
> select one specific commonly used version to crash. Suddenly you have a 
> root shell on the system. So it's not only doable, it's fairly trivial 
> to do. In short, anybody who thinks that the non-executable stack gives 
> them any real security is very very much living in a dream world. It may 
> catch a few attacks for old binaries that have security problems, but 
> the basic problem is that the binaries allow you to overwrite their 
> stacks. And if they allow that, then they allow the 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."

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
makes it a LOT harder to actually exploit a buffer overflow on, say, a
distribution like Fedora Core 4.


> 
> 
> rvk
> 
> >but your system is not compromised.
> >
> >One final point, in practice, you get lots of unwanted packets
> >off the internet, and in general you do not want them on your
> >internal net, both for performance and security reasons, if you
> >drop them on your router or firewall then you dont need to
> >worry if the remote app is mal-ware.
> >
> >--
> >mit freundlichen Grüßen, Brian.
> >
> >.
> >
> >  
> >
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Buffer Over-runs, was Open source firewalls

[RVK]

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 system() library function. 2) the next four bytes are
>>crap (a "return pointer" for the system call, which you don't care
>>about) 3) the next four bytes are a pointer to some random place in the
>>shared library again that contains the string "/bin/sh" (and yes, just
>>do a strings on the thing and you'll find it). Voila. You didn't have to
>>write any code, the only thing you needed to know was where the library
>>is loaded by default. And yes, it's library-specific, but hey, you just
>>select one specific commonly used version to crash. Suddenly you have a
>>root shell on the system. So it's not only doable, it's fairly trivial
>>to do. In short, anybody who thinks that the non-executable stack gives
>>them any real security is very very much living in a dream world. It may
>>catch a few attacks for old binaries that have security problems, but
>>the basic problem is that the binaries allow you to overwrite their
>>stacks. And if they allow that, then they allow the 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."
>>    
>>
>
>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
>makes it a LOT harder to actually exploit a buffer overflow on, say, a
>distribution like Fedora Core 4.
>
>
>  
>
Still is very new....not every one can immediately start using gcc 4.

rvk

>>rvk
>>
>>    
>>
>>>but your system is not compromised.
>>>
>>>One final point, in practice, you get lots of unwanted packets
>>>off the internet, and in general you do not want them on your
>>>internal net, both for performance and security reasons, if you
>>>drop them on your router or firewall then you dont need to
>>>worry if the remote app is mal-ware.
>>>
>>>--
>>>mit freundlichen Grüßen, Brian.
>>>
>>>.
>>>
>>>
>>>
>>>      
>>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/
>>    
>>
>.
>
>  
>

Re: Buffer Over-runs, was Open source firewalls

[Arjan van de Ven]

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
> >makes it a LOT harder to actually exploit a buffer overflow on, say, a
> >distribution like Fedora Core 4.
> >
> >
> >  
> >
> Still is very new....not every one can immediately start using gcc 4.

it;s also available for gcc 3.4 as patch (and included in FC3 and RHEL4
for example)

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.

Re: Buffer Over-runs, was Open source firewalls

[RVK]

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 combination of this all
>>>makes it a LOT harder to actually exploit a buffer overflow on, say, a
>>>distribution like Fedora Core 4.
>>>
>>>
>>>
>>>
>>>      
>>>
>>Still is very new....not every one can immediately start using gcc 4.
>>    
>>
>
>it;s also available for gcc 3.4 as patch (and included in FC3 and RHEL4
>for example)
>
>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.
>  
>
Can I get more details on this patch for 3.4. Where can I find it ?

rvk

>.
>
>  
>

Re: Buffer Over-runs, was Open source firewalls

[RVK]

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 combination of this all
>>>makes it a LOT harder to actually exploit a buffer overflow on, say, a
>>>distribution like Fedora Core 4.
>>>
>>>
>>>
>>>
>>>      
>>>
>>Still is very new....not every one can immediately start using gcc 4.
>>    
>>
>
>it;s also available for gcc 3.4 as patch (and included in FC3 and RHEL4
>for example)
>
>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.
>  
>
Can I get more details on this patch for 3.4. Where can I find it ?

rvk

>.
>
>  
>

Re: Buffer Over-runs, was Open source firewalls

[RVK]

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 combination of this all
>>>makes it a LOT harder to actually exploit a buffer overflow on, say, a
>>>distribution like Fedora Core 4.
>>>
>>>
>>>
>>>
>>>      
>>>
>>Still is very new....not every one can immediately start using gcc 4.
>>    
>>
>
>it;s also available for gcc 3.4 as patch (and included in FC3 and RHEL4
>for example)
>
>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 ?

rvk

>.
>
>  
>

Re: Buffer Over-runs, was Open source firewalls

[Arjan van de Ven]

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 included
already. So I suspect all future distros will have this (once they make
the jump to 4.1 or when they backport this)
> 
> rvk
> 
> >.
> >
> >  
> >
>