[PATCH] qubes-tor security + bug fixes
94 views
Skip to first unread message
Abel Luck
Apr 9, 2014, 2:08:53 PM4/9/14
to qubes...@googlegroups.com
Hi Devs,
I've pushed a few patches to qubes-tor to my repo.
https://github.com/abeluck/qubes-tor/commits/master
One of the comits is pretty critical. Mike Perry of Tor Project
discovered a bug in the Linux kernel that leaks FIN packets under
certain circumstances bypassing transparent proxying rules.
read more about it here:
https://lists.torproject.org/pipermail/tor-talk/2014-March/032503.html
Cheers,
~abel
I've pushed a few patches to qubes-tor to my repo.
https://github.com/abeluck/qubes-tor/commits/master
One of the comits is pretty critical. Mike Perry of Tor Project
discovered a bug in the Linux kernel that leaks FIN packets under
certain circumstances bypassing transparent proxying rules.
read more about it here:
https://lists.torproject.org/pipermail/tor-talk/2014-March/032503.html
Cheers,
~abel
Marek Marczykowski-Górecki
Apr 9, 2014, 2:43:11 PM4/9/14
to Abel Luck, qubes...@googlegroups.com
+ /sbin/iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP
+ /sbin/iptables -A OUTPUT -m state --state INVALID -j DROP
I see in that discussion:
On Fri, Mar 28, 2014 at 5:34 PM, Mike Perry <mikeperry at torproject.org>wrote:
> iptables -A OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp
--tcp-flags ACK,FIN ACK,FIN -j LOG --log-prefix "Transproxy leak blocked: "
--log-uid
> iptables -A OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp
--tcp-flags ACK,RST ACK,RST -j LOG --log-prefix "Transproxy leak blocked: "
--log-uid
> iptables -A OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp
--tcp-flags ACK,FIN ACK,FIN -j DROP
> iptables -A OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp
--tcp-flags ACK,RST ACK,RST -j DROP
> It's likely only the first pair is needed, and you may want to comment
> out the --ctstate LOG line as I did to limit noise for successfully
> handled --ctstate INVALID DROP blocks.
> I did test this with the above repro method, and --ctstate INVALID did
> appear sufficient by itself, but reports of any --ctstate DROP rule
> bypass happening will be tremendously useful (which will result in the
> later LOG lines being hit, and sending output to 'dmesg').
Also iptables manual says that the "state" module is an obsolete version of
"conntrack".
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Marek Marczykowski-Górecki
Apr 18, 2015, 10:46:28 AM4/18/15
to Abel Luck, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I didn't get any reply... Anyway applied, a year later.
- --
Version: GnuPG v1
iQEcBAEBAgAGBQJVMm46AAoJENuP0xzK19csIQUH/j2ODR9i4VmfXxcd/fy+Svnc
aLUU9YFuW9caDHTD7LRhUa6SyOoakfj0LzczudschnWF4ipxknwJIYfYZQvJt+7F
j0XYHCZyIiPxSIEhVapbU9ru//Ff6arcgH+Qo+GnsIr0dFUfG44dIHV1BPXnfRAx
zf4cC9jVU1jcym0btxgbUsCwibPMtI9iddgUkVNSf/zm64+NCnfVh5tjLrLz2vhv
3AyEC4+wa+eA12zSfw3UoP2hCoP60UdnLyiYiGIj4SZ6p8EPaNgDq0CBwQEmQq47
mY/j967doZ9M9NtTNJ1EKJ00bJqZi8d+fXKlc8bPZvmtNw2u58wxL93z4zZ+OBw=
=VQYq
-----END PGP SIGNATURE-----
Hash: SHA1
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Version: GnuPG v1
iQEcBAEBAgAGBQJVMm46AAoJENuP0xzK19csIQUH/j2ODR9i4VmfXxcd/fy+Svnc
aLUU9YFuW9caDHTD7LRhUa6SyOoakfj0LzczudschnWF4ipxknwJIYfYZQvJt+7F
j0XYHCZyIiPxSIEhVapbU9ru//Ff6arcgH+Qo+GnsIr0dFUfG44dIHV1BPXnfRAx
zf4cC9jVU1jcym0btxgbUsCwibPMtI9iddgUkVNSf/zm64+NCnfVh5tjLrLz2vhv
3AyEC4+wa+eA12zSfw3UoP2hCoP60UdnLyiYiGIj4SZ6p8EPaNgDq0CBwQEmQq47
mY/j967doZ9M9NtTNJ1EKJ00bJqZi8d+fXKlc8bPZvmtNw2u58wxL93z4zZ+OBw=
=VQYq
-----END PGP SIGNATURE-----
Axon
Apr 18, 2015, 11:45:56 AM4/18/15
to Marek Marczykowski-Górecki, Abel Luck, qubes...@googlegroups.com, WhonixQubes, Patrick Schleizer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Marek Marczykowski-Górecki wrote:
> On Sat, Apr 12, 2014 at 09:55:42AM +0200, Abel Luck wrote:
>> Saw this, and will reply next week!
>
>> ~abel
>
>> Marek Marczykowski-Górecki:
>>> On 09.04.2014 20:08, Abel Luck wrote:
>>>> Hi Devs,
>>>>
>>>> I've pushed a few patches to qubes-tor to my repo.
>>>>
>>>> https://github.com/abeluck/qubes-tor/commits/master
>>>>
>>>> One of the comits is pretty critical. Mike Perry of Tor
>>>> Project discovered a bug in the Linux kernel that leaks FIN
>>>> packets under certain circumstances bypassing transparent
>>>> proxying rules.
>>>>
>>>> read more about it here:
>>>> https://lists.torproject.org/pipermail/tor-talk/2014-March/032503.html
>>>
[...]
for well over a year now? Sounds pretty bad. Is it recommended not to
use TorVM if [ano|pseudo]nymity is desired (which is probably the only
reason to use it in the first place), at least until this patch
becomes available?
BTW, how do/have Whonix and Qubes+Whonix fare(d) wrt this bug?
Sounds like there was some controversy over how to test for it,
esp. on different isolation methods (physical, Xen, KVM, VirtualBox,
etc.):
https://www.whonix.org/forum/index.php?topic=331.0
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVMnwWAAoJEJh4Btx1RPV8UWUQAM5ELKaIS7Esf9YeoSuU3/Ys
lVWzFR8bBkoRNxHHIXuFSaBtcpl36OpdNvWqR/vVVq6OeeVwADmCkPBoxEzLVNY3
hUYIl4x53t87wbJKXN9xxaBj2nmbQhPCo35Dl1Y42Qd/AfQU2ctCMdJdfjJR/bu0
X3lfYF7izF3e9kM89dBtydYYXXX4Y27nQn70LcAe3vIARmLM/5Zpjz7Jthc9ALd9
VRCTEgYC6RKYOIieHiUSukmFOyOE6zv03uCChfVlkxJ8FPjneG3Hs59TVNR81AyZ
Xv/gLpQb06LOZALQRlboWusOxlUOGzXJc7U+XXEVTJMY0vpF5eseCvBGOv0ebBgL
H6ma7C4dpLsrxI8H6+nDXKIXSYojGPvjPrufr9GFmeEZYPFF9/97A0YtQDNLVOqj
Or89S5/hsu6/994xl8IWg6/jVf5lCh1aGr2jWOGWm+Xv/XfBbxYkt07cEn/wtp7W
Ckm6X1aoiEK5OJOVittiN+gZ5y09dZJ4lYRsh7BdjpfX+yNatuG5rMR+EB6qdoZI
GDAbnkViNhKWsldD+A9Xr4all58HUYZrMWLixH1kl3susB/NIELdBAJyG3GOBQR8
ka51Vy8EHCllLmdgj4byXwsXx189WteHaH4B2femayskzYQQleknvYNVn2b6v0t2
OWANvUPn/rPQf264MBdh
=dhGU
-----END PGP SIGNATURE-----
Hash: SHA512
Marek Marczykowski-Górecki wrote:
> On Sat, Apr 12, 2014 at 09:55:42AM +0200, Abel Luck wrote:
>> Saw this, and will reply next week!
>
>> ~abel
>
>> Marek Marczykowski-Górecki:
>>> On 09.04.2014 20:08, Abel Luck wrote:
>>>> Hi Devs,
>>>>
>>>> I've pushed a few patches to qubes-tor to my repo.
>>>>
>>>> https://github.com/abeluck/qubes-tor/commits/master
>>>>
>>>> One of the comits is pretty critical. Mike Perry of Tor
>>>> Project discovered a bug in the Linux kernel that leaks FIN
>>>> packets under certain circumstances bypassing transparent
>>>> proxying rules.
>>>>
>>>> read more about it here:
>>>> https://lists.torproject.org/pipermail/tor-talk/2014-March/032503.html
>>>
>>>
>>>> It's likely only the first pair is needed, and you may want
>>>> to comment out the --ctstate LOG line as I did to limit
>>>> noise for successfully handled --ctstate INVALID DROP
>>>> blocks.
>>>
>>>> I did test this with the above repro method, and --ctstate
>>>> INVALID did appear sufficient by itself, but reports of any
>>>> --ctstate DROP rule bypass happening will be tremendously
>>>> useful (which will result in the later LOG lines being hit,
>>>> and sending output to 'dmesg').
>>>
>>> Also iptables manual says that the "state" module is an
>>> obsolete version of "conntrack".
>
> I didn't get any reply... Anyway applied, a year later.
>
So, does this mean that Qubes TorVM users have been leaking packets
>>>> It's likely only the first pair is needed, and you may want
>>>> to comment out the --ctstate LOG line as I did to limit
>>>> noise for successfully handled --ctstate INVALID DROP
>>>> blocks.
>>>
>>>> I did test this with the above repro method, and --ctstate
>>>> INVALID did appear sufficient by itself, but reports of any
>>>> --ctstate DROP rule bypass happening will be tremendously
>>>> useful (which will result in the later LOG lines being hit,
>>>> and sending output to 'dmesg').
>>>
>>> Also iptables manual says that the "state" module is an
>>> obsolete version of "conntrack".
>
> I didn't get any reply... Anyway applied, a year later.
>
for well over a year now? Sounds pretty bad. Is it recommended not to
use TorVM if [ano|pseudo]nymity is desired (which is probably the only
reason to use it in the first place), at least until this patch
becomes available?
BTW, how do/have Whonix and Qubes+Whonix fare(d) wrt this bug?
Sounds like there was some controversy over how to test for it,
esp. on different isolation methods (physical, Xen, KVM, VirtualBox,
etc.):
https://www.whonix.org/forum/index.php?topic=331.0
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVMnwWAAoJEJh4Btx1RPV8UWUQAM5ELKaIS7Esf9YeoSuU3/Ys
lVWzFR8bBkoRNxHHIXuFSaBtcpl36OpdNvWqR/vVVq6OeeVwADmCkPBoxEzLVNY3
hUYIl4x53t87wbJKXN9xxaBj2nmbQhPCo35Dl1Y42Qd/AfQU2ctCMdJdfjJR/bu0
X3lfYF7izF3e9kM89dBtydYYXXX4Y27nQn70LcAe3vIARmLM/5Zpjz7Jthc9ALd9
VRCTEgYC6RKYOIieHiUSukmFOyOE6zv03uCChfVlkxJ8FPjneG3Hs59TVNR81AyZ
Xv/gLpQb06LOZALQRlboWusOxlUOGzXJc7U+XXEVTJMY0vpF5eseCvBGOv0ebBgL
H6ma7C4dpLsrxI8H6+nDXKIXSYojGPvjPrufr9GFmeEZYPFF9/97A0YtQDNLVOqj
Or89S5/hsu6/994xl8IWg6/jVf5lCh1aGr2jWOGWm+Xv/XfBbxYkt07cEn/wtp7W
Ckm6X1aoiEK5OJOVittiN+gZ5y09dZJ4lYRsh7BdjpfX+yNatuG5rMR+EB6qdoZI
GDAbnkViNhKWsldD+A9Xr4all58HUYZrMWLixH1kl3susB/NIELdBAJyG3GOBQR8
ka51Vy8EHCllLmdgj4byXwsXx189WteHaH4B2femayskzYQQleknvYNVn2b6v0t2
OWANvUPn/rPQf264MBdh
=dhGU
-----END PGP SIGNATURE-----
HW42
Apr 18, 2015, 1:36:32 PM4/18/15
to Marek Marczykowski-Górecki, Abel Luck, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Marek Marczykowski-Górecki:
Is someone able to reproduce the described problem with a TorVM?
I quickly tried it with my TorVM but was not able to reproduce it.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVMpYGAAoJEOSsySeKZGgWWDMQAMAojfRkUu40rhPmNMh+NXkB
W6Sv3QAW4nyeoPI/pXQTYawqBeWHjpKfZ4jRrjK4DCgReri5eIpUI0lXZHi0h7gu
Ljr0SfAO4G2fJvPsM40bdrozsQPaySuK4jtArgCbETLyzDXaPH8JPsG6qfPGYAoi
qq4cyXXuXCVQWX+cd6/j6roChfK1c1OQGU+AbcuHNapuMyNulFuW7kqDSVdXJEyF
h1CB4KHndsOTn6uw6bffIaD7GXG2ko0PaM2zIBhasyNMZ/LDaFADi8fP8uHrWOvN
5HtnV7NcOVZjBL4V/86jwY7veuv3XAyhTmVkokGYr34xX3bChF/R8JUzzc+LtoC0
sh+l1FkRkxsStB3YFrNRGB423h7fwgMf/20NggnSI9sy0u9znFI+bNgebR6r6Icu
rDhf5z4vm0a1N0INkh1f2FbS/AQP46WpqAwr5c/2B3rROYrVPJkcopVitMsc0XNp
gkbMW2dSYXnrsHp3M7a03s8oFCUdzTLZ2EcFMTg2Kka9l1FgMPcsX+E3tOZdMvJl
FJb/qo/M0/iJUS66AMcbff4riRz6qjTB5Ymjl5qTCPFKtH3Wwic+VsVeEC0W/rmY
cO9KCKCTf4pjL0cm4XPjcHIIKH7C73CHgS8J+Ak3mUti7ZV9Mf2HpnlaLWQgyqGr
lrC2beFjVPxSrOtqBTAO
=4yAU
-----END PGP SIGNATURE-----
Hash: SHA512
Marek Marczykowski-Górecki:
I quickly tried it with my TorVM but was not able to reproduce it.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVMpYGAAoJEOSsySeKZGgWWDMQAMAojfRkUu40rhPmNMh+NXkB
W6Sv3QAW4nyeoPI/pXQTYawqBeWHjpKfZ4jRrjK4DCgReri5eIpUI0lXZHi0h7gu
Ljr0SfAO4G2fJvPsM40bdrozsQPaySuK4jtArgCbETLyzDXaPH8JPsG6qfPGYAoi
qq4cyXXuXCVQWX+cd6/j6roChfK1c1OQGU+AbcuHNapuMyNulFuW7kqDSVdXJEyF
h1CB4KHndsOTn6uw6bffIaD7GXG2ko0PaM2zIBhasyNMZ/LDaFADi8fP8uHrWOvN
5HtnV7NcOVZjBL4V/86jwY7veuv3XAyhTmVkokGYr34xX3bChF/R8JUzzc+LtoC0
sh+l1FkRkxsStB3YFrNRGB423h7fwgMf/20NggnSI9sy0u9znFI+bNgebR6r6Icu
rDhf5z4vm0a1N0INkh1f2FbS/AQP46WpqAwr5c/2B3rROYrVPJkcopVitMsc0XNp
gkbMW2dSYXnrsHp3M7a03s8oFCUdzTLZ2EcFMTg2Kka9l1FgMPcsX+E3tOZdMvJl
FJb/qo/M0/iJUS66AMcbff4riRz6qjTB5Ymjl5qTCPFKtH3Wwic+VsVeEC0W/rmY
cO9KCKCTf4pjL0cm4XPjcHIIKH7C73CHgS8J+Ak3mUti7ZV9Mf2HpnlaLWQgyqGr
lrC2beFjVPxSrOtqBTAO
=4yAU
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Apr 19, 2015, 10:13:57 AM4/19/15
to Axon, Abel Luck, qubes...@googlegroups.com, WhonixQubes, Patrick Schleizer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fortunately no, because package qubes-tor-0.1.6 (released May 23 2014)
introduced more generic solution (simply blocking all packets in
FORWARD, so only local process - tor - can generate traffic):
https://github.com/QubesOS/qubes-app-linux-tor/commit/ebb74f8bb3165f9f989ecbf39e695815d374e82f
> Sounds pretty bad. Is it recommended not to
> use TorVM if [ano|pseudo]nymity is desired (which is probably the only
> reason to use it in the first place), at least until this patch
> becomes available?
>
> BTW, how do/have Whonix and Qubes+Whonix fare(d) wrt this bug?
It looks like there is no such problem, as by default it also drops all
packets in FORWARD chain.
> Sounds like there was some controversy over how to test for it,
> esp. on different isolation methods (physical, Xen, KVM, VirtualBox,
> etc.):
>
> https://www.whonix.org/forum/index.php?topic=331.0
g+7/nNuV1QhbKWy01jiI7Y6h7YEu5F+ql6p54Whq+MobMKEcrEVXsfvKOZR2wC/n
Olv72Gcqpe9QMdF5OHfTWouQUHLVJAObLEMTdVDW7KXB6AVd2NzMmkkDdgk6QDeG
X/4Wpuu10DtwVBJ1TPqaNabW83DjcP3He6GOZo3DpAGv4Mv6Ua2sNiEO7H+if/Ed
Kpt23I4bcLvixBHDAJ2ajUiZU7w0VDn5Ee7/SSNrwQzprU5BDRHW2JD8aIy+SHnz
gdAF/GaXbqzF5x7FgyO+in2EMQ+MvjfZBu8/XHQqBWqu7+PRP8QbRJT7RMKzkE4=
=3xxN
-----END PGP SIGNATURE-----
Hash: SHA1
introduced more generic solution (simply blocking all packets in
FORWARD, so only local process - tor - can generate traffic):
https://github.com/QubesOS/qubes-app-linux-tor/commit/ebb74f8bb3165f9f989ecbf39e695815d374e82f
> Sounds pretty bad. Is it recommended not to
> use TorVM if [ano|pseudo]nymity is desired (which is probably the only
> reason to use it in the first place), at least until this patch
> becomes available?
>
> BTW, how do/have Whonix and Qubes+Whonix fare(d) wrt this bug?
packets in FORWARD chain.
> Sounds like there was some controversy over how to test for it,
> esp. on different isolation methods (physical, Xen, KVM, VirtualBox,
> etc.):
>
> https://www.whonix.org/forum/index.php?topic=331.0
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVM7gaAAoJENuP0xzK19csorEH/jYj2RWPSz7EAjEJHv6Roa9v
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
g+7/nNuV1QhbKWy01jiI7Y6h7YEu5F+ql6p54Whq+MobMKEcrEVXsfvKOZR2wC/n
Olv72Gcqpe9QMdF5OHfTWouQUHLVJAObLEMTdVDW7KXB6AVd2NzMmkkDdgk6QDeG
X/4Wpuu10DtwVBJ1TPqaNabW83DjcP3He6GOZo3DpAGv4Mv6Ua2sNiEO7H+if/Ed
Kpt23I4bcLvixBHDAJ2ajUiZU7w0VDn5Ee7/SSNrwQzprU5BDRHW2JD8aIy+SHnz
gdAF/GaXbqzF5x7FgyO+in2EMQ+MvjfZBu8/XHQqBWqu7+PRP8QbRJT7RMKzkE4=
=3xxN
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Apr 19, 2015, 10:15:23 AM4/19/15
to HW42, Abel Luck, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Because it was fixed another way (check my mail from minute ago). The
relevant part from Abel's patches is stream isolation default setting.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVM7hyAAoJENuP0xzK19csUFcH/jS5HtD3RDiA0O3aF0TXjiJx
N4jrrkFwUmEBptsxR4xDxvp5gDcbAPv5tvsytu2XuTKYT1+pKNCkk5OUkM3lZEH9
DKyr1RC1nH971fwnFNUQhWBJ25gPeRy6Bd0sBFG35FjyJKX4NELoZYFxGTUeadw/
Jqe1rTOPf9yHZIQnTg/HG3nEAyXoCFZPC7UjUVDq/NDgV17cdcjWp00zPx0zIXig
PZ+MAgsqvkTnpEd6BbTEFVozJOup/GK4mkI8fMvIIKdfK8LGI4UENu3kEU6TQz+k
mkOLhwzFtTIO7hokcFdovyV1uqX17qZ+I/ZUQan7KM+KdIduDPp50WOhr0jNuCI=
=/hHM
-----END PGP SIGNATURE-----
Hash: SHA1
relevant part from Abel's patches is stream isolation default setting.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
N4jrrkFwUmEBptsxR4xDxvp5gDcbAPv5tvsytu2XuTKYT1+pKNCkk5OUkM3lZEH9
DKyr1RC1nH971fwnFNUQhWBJ25gPeRy6Bd0sBFG35FjyJKX4NELoZYFxGTUeadw/
Jqe1rTOPf9yHZIQnTg/HG3nEAyXoCFZPC7UjUVDq/NDgV17cdcjWp00zPx0zIXig
PZ+MAgsqvkTnpEd6BbTEFVozJOup/GK4mkI8fMvIIKdfK8LGI4UENu3kEU6TQz+k
mkOLhwzFtTIO7hokcFdovyV1uqX17qZ+I/ZUQan7KM+KdIduDPp50WOhr0jNuCI=
=/hHM
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages