25.05.2004 | 09:44
Svima nama drag sistem u zadnje vrijeme cini se dosta supljikavim... taman sto je apple izbacio sekjuriti apdejt... cini se da ga nisu zakrpali kako spada... naime opet ranjivost (telnet -f, HelpViewer and Self URI Registering, Sherlock bugs, ...).. evo na negleskom clanka
In the same trend of the current URI exploits being researched (telnet -f, HelpViewer and Self URI Registering, Sherlock bugs, ...) I found Yet Another Remote Code Execution exploit.
Again, taking advantage of MacOS X's remote disk mouting to get the executable path, things are quite easy. It does not mean that it is required!
Adv: safari_0x06
Release Date: Private
Affected Products: MacOSX >= 10.3.3, Various Browsers, possibly others platforms/browsers
Fixed in: Not fixed.
Impact: Remote code execution.
Severity: High.
Vendors: Notified (23/02/04)
Author:
Ova e-mail adresa je zaštićena od spam robota, nije vidljiva ako ste isključili JavaScript
So in a nutshell, ssh allows local command execution with the ProxyCommand option. Instead of executing a proxy application, we'll execute our own commands. Yes, it's that simple, and yes it's that powerfull. Note that you can also potentially forward remote ports using the -R flag and setting up a null-password account (ssh://ssh haxor.com -R port:localhostort).
URI's are all very dangerous, and the only solution that I see right now is asking for each non-standard URI (non-mail, http, and ftp for example) if the user wants to execute it, with the command name. This is very unfortunate because really cumbersome.
Tests on konqueror showed that this browser wasn't vulnerable as it skips commands arguments.
On Firefox/Epiphany/Mozilla I wasn't able to exploit it because of a bug in my gnome 2.6 handlers, otherwise it seems it would be possible.
So, as usual, a non-dangerous proof of concept demo is available
www.insecure.ws/article.php?story=200405222251133
Solution:
I suggest you trying Paranoid Android from Unsanity which does the job I described as a possible solution.