On Tuesday 30 August 2005 02:51, Kir wrote:
What do you mean? Curl prints to STDOUT. If someone manages to exec a
shell, couldn't he just redirect the curl output to /tmp as he desires?
Anyway, it seems to me it'd be more effective to make sure he cannot
execute whatever it is he downloaded; the noexec flag and GRSec's TPE
would probably both be useful for that.
Or did I misunderstand you?
You misunderstood. Method above was meant to be used with
wget, that dumps received file into file. But it`s not
impossible to modify curl`s source to behave in the same
way: force it to redirect received data into file and then
apply the same hack.
Am I wrong?
Excuse for being blunt, but I believe this approach is useless. There are many
ways an intruder could grab a remote file, from wget/curl, perl/python
one-liners, and even from bash scripting (yes, I've seen it done through
careful filehandle and socket mangling). So, unless you disable all downloads
from your machine, them you are just restricting the options an intruder
would have, but not eliminating the possibility of downloading externals
files.
Many people have mentioned grsec/PaX, mounting /tmp with noexec and many other
variations. These are, IMHO, much better approaches because they are system
configuration parameters, not based on application patching. If you choose to
patch your applications then you'll have to keep track of all updates to
these applications (i.e., through apt-get, yum, emerge or whatever is the
package manager of your choice -- after all one must update server software
at some time, especially when it comes to security updates) which could
override your modifications, and backport your modifications into every new
version that comes out. And even then you would not have the same level of
security provided by a containment solution such as grsrc/PaX.
Then again, these are just my $0.02...
Kind regards
Ulisses Montenegro
