Re: [tor-talk] Firefox security bug (proxy-bypass) in current TBBs
On 5/3/12 7:26 PM, unknown wrote: On Wed, 2 May 2012 22:43:52 + Robert Ransom rransom.8...@gmail.com wrote: See https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-current-tbbs for the security advisory. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk Any potential DNS-leakage can be prevented with iptables (Debian GNU/Linux way): Well, this can also be prevented if the starter of TBB would be a binary/executable rather than a shell script, and that binary executable would provide LD_PRELOAD tsocks like approach wrapping the connect(). That way the entire TBB will run over the TBB_STARTER that will provide an application-level firewall that would prevent any kind of socket API to get-out directly. -naif ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Firefox security bug (proxy-bypass) in current TBBs
On Fri, 4 May 2012 07:27:35 +0200 Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: Any potential DNS-leakage can be prevented with iptables (Debian GNU/Linux way): Well, this can also be prevented if the starter of TBB would be a binary/executable rather than a shell script, and that binary executable would provide LD_PRELOAD tsocks like approach wrapping the connect(). That way the entire TBB will run over the TBB_STARTER that will provide an application-level firewall that would prevent any kind of socket API to get-out directly. -naif ___ An application-level firewall is an illusion of security. Procesess can be separated by owners with users and groups but programs itself cannot be authenticated to iptables. That's a reason to exclude an application-level firewall options --owner --cmd-owner program-name from the kernel iptables modules. Stronger way to manage network connections associated to programs is SELinux security contexts or similar security modules. Even a path based ACLs and MACs such as AppArmor can be avoided and failed and only strong security context isolation in SELinux is a right decision. Or just simple use system groups with iptables: not so secure, not so strong. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Firefox security bug (proxy-bypass) in current TBBs
On Wed, 2 May 2012 22:43:52 + Robert Ransom rransom.8...@gmail.com wrote: See https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-current-tbbs for the security advisory. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk Any potential DNS-leakage can be prevented with iptables (Debian GNU/Linux way): Edit /etc/login.defs, Replace ENCRYPT_METHOD DES to ENCRYPT_METHOD SHA-512 Run command for create tbb-group with password: addgroup --system tbb-tor Add this rules to your firewall: #tor anonymous users; DIRECT_OUT_GID=tbb-tor #group id for TBB TOR_UID=debian-tor #system tor (if you use it) #anonymous user runs programs with transparent torification to system tor #(if you use it): $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner anonymoususer ! --gid-owner $DIRECT_OUT_GID -m tcp --syn -j REDIRECT --to-ports 9040 $IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner anonymoususer ! --gid-owner $DIRECT_OUT_GID -m udp --dport 53 -j REDIRECT --to-ports 53 $IPTABLES -t nat -A OUTPUT -m owner --uid-owner anonymoususer ! --gid-owner $DIRECT_OUT_GID -j DNAT --to-destination 127.0.0.1 #Accept output for system-tor itself (if you use it) $IPTABLES -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT #Direct output for TBB without udp and tcp 53 port $IPTABLES -A OUTPUT -m owner --gid-owner $DIRECT_OUT_GID ! -p tcp -j REJECT $IPTABLES -A OUTPUT -m owner --gid-owner $DIRECT_OUT_GID -p tcp --dport 53 -j REJECT $IPTABLES -A OUTPUT -m owner --gid-owner $DIRECT_OUT_GID -j ACCEPT Run your tor-browser with sg from x-terminal emulator: sg tbb-tor -c start-tor-browser.sh Unfortunately, this is not an ideal solution for transparent torification TBB. All (but udp and dns-tcp) tcp trafic goes away. Using unix groups is not a way to separate start-script, vidalia, browser and TBB-tor itself. A more fine-tuned firewall solution is still desirable ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Firefox security bug (proxy-bypass) in current TBBs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 See https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-current-tbbs for the security advisory. I'm quite surprised that you do not inform TBB users via the usual channel: via the default startpage in TBB (check.tpo) - even if there are no new TBBs yet. -BEGIN PGP SIGNATURE- iF4EAREKAAYFAk+i5GYACgkQyM26BSNOM7ZZWQD/asLtZpm0C9d6P++5c7F2hvX6 1+4iRtjn+J9eIKL8fvwBAKtatj70yDERZaCEWzw6POPWgzvcwOIrMtEKwGvfBXVG =yAS8 -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Firefox security bug (proxy-bypass) in current TBBs
See https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-current-tbbs for the security advisory. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
