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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|