On 9/28/06, Voytek Eymont <[EMAIL PROTECTED]> wrote:
I would think that depended entirely on the exploitable hole; even if you get rid of those utilities, there will be ways within perl/php/<language-of-choice> to download things; if the exploitable hole makes those available, you're no better off for having removed those utilities.
I think it would cause more inconvenience than you realise. I'm not sure what Apt or up2date use, but I know that utilities such as CPAN will try to use wget/curl/links/lynx in order to download updates; you'll probably find that a lot of other systems that have the ability to look for updates do as well.
Essentially, I think you're making the same mistake here that Bruce Schneier writes about airline security people making all the time: you're reacting specifically to one attack vector that you've seen in the past, which means that that vector won't be successful again. You're not doing anything to prevent different vectors from being detected or prevented though.
I'd suggest that a more effective strategy might be to talk to your users; tell them what you've found, why it's unacceptable, and what action you'll be taking if you discover anything similar in future. Also make it clear to them how they can check things with you before they install, and be proactive in helping them find solutions that don't compromise your security - for instance, sticking phpmyadmin behind a .htaccess file.
On Wed, September 27, 2006 9:15 pm, Erik de Castro Lopo wrote:
>> apart from wget and curl, what else can be used to download illicit
>> files to a web server ?
>
> Python, Perl, Ruby, C, Haskell, Ocaml. In fact any programming language.
> Also programs like lynx.
Eric,
I guess I meant 'single-purpose utilities that can be easily expoited like
so' :
'some_app file_url'
through a web server vulnerability to easily deposit exploits
I'm guessing that if I do NOT have wget/curl/lynx/links available, next
time a cms has such an expoitable hole, I'll reduce my exposure, no ??
I would think that depended entirely on the exploitable hole; even if you get rid of those utilities, there will be ways within perl/php/<language-of-choice> to download things; if the exploitable hole makes those available, you're no better off for having removed those utilities.
if I remove or rename wget/curl/lynx/links from my server, apart from
ocassional inconvience to me, that won't cause me issues ?
I think it would cause more inconvenience than you realise. I'm not sure what Apt or up2date use, but I know that utilities such as CPAN will try to use wget/curl/links/lynx in order to download updates; you'll probably find that a lot of other systems that have the ability to look for updates do as well.
Essentially, I think you're making the same mistake here that Bruce Schneier writes about airline security people making all the time: you're reacting specifically to one attack vector that you've seen in the past, which means that that vector won't be successful again. You're not doing anything to prevent different vectors from being detected or prevented though.
I'd suggest that a more effective strategy might be to talk to your users; tell them what you've found, why it's unacceptable, and what action you'll be taking if you discover anything similar in future. Also make it clear to them how they can check things with you before they install, and be proactive in helping them find solutions that don't compromise your security - for instance, sticking phpmyadmin behind a .htaccess file.
--
Voytek
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
--
There is nothing more worthy of contempt than a man who quotes himself - Zhasper, 2004
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
