relays and CUPS vulnerabilities
There are some very significant recent CVEs out for CUPS, the unix printing system. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cups It's an ideal moment to remind relay operators that a Tor node, relay or bridge, should be a single-purpose internet server. Running alternate internet services is a bad idea. The node should have the minimum packages installed for the purpose of running a node. More packages means more possible vulnerabilities. Needless to say, a CUPS server listening on 631/tcp or 631/udp while providing Tor access is a bad idea. g -- 43C2 85B0 41B6 4AC1 0E02 2767 7092 AEB3 40B0 C804
Hello, I don't see how this is an issue, because Tor guards / middles only ever relay traffic, and exits already have sufficient REJECT rules:
reject 0.0.0.0/8:* reject 169.254.0.0/16:* reject 127.0.0.0/8:* reject 192.168.0.0/16:* reject 10.0.0.0/8:* reject 172.16.0.0/12:*
I am just going to assume that CUPS opens these ports on your public interface?! But your point of containerization is a always a good one, my Tor exit runs in a QEMU/KVM VM on our colocated server, which has nothing else running on it except for openvpn and systemd-resolved (using DNS-over-TLS and DNSSEC). You should also have IPTables configured accordingly, and it's rules loaded on every boot automatically. I attached an example bash script on how to configure IPtables, but please go through the entire script and see what it actually does, don't just apply it and lock yourself out of the system. Note that this is for my system, so you will have to change ports and so on for your system, and remove useless lines. Thank you, George
There are some very significant recent CVEs out for CUPS, the unix printing system.
It's an ideal moment to remind relay operators that a Tor node, relay or bridge, should be a single-purpose internet server.
Running alternate internet services is a bad idea. The node should have the minimum packages installed for the purpose of running a node. More packages means more possible vulnerabilities.
Needless to say, a CUPS server listening on 631/tcp or 631/udp while providing Tor access is a bad idea.
g
-- 43C2 85B0 41B6 4AC1 0E02 2767 7092 AEB3 40B0 C804
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Fri, Sep 27, 2024 at 09:41:29AM -0400, George via tor-relays wrote:
There are some very significant recent CVEs out for CUPS, the unix printing system.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cups [...] Needless to say, a CUPS server listening on 631/tcp or 631/udp while providing Tor access is a bad idea.
George and I took the opportunity to scan relays and bridges to see if they have this vulnerable cups-browsed service running. We found 14 relay IP addresses that did, and 4 bridge IP addresses. This is a pretty good rate overall! (I had been expecting to find more bridges, because they're more likely to be at home and people might be running them from their stock Ubuntu desktop install or the like. But we found very few, and maybe that is because at many homes everything is NATed/firewalled by default.) 12 of the 18 had proper contactinfo and I emailed them. One bounced, one replied and fixed it, and the others haven't replied yet. There is a fine policy question here, which is "ok so what now? Do we leave them in place or bump them out of the network?" I figure I'll wait a week or so and scan these 18 again. But I fear that the package "fix" will just correct a buffer overflow or something and it will leave the "they listen to the whole internet and add any printers that the internet sends them" behavior intact (because one is a bug, the other is a feature), so my scan won't actually be able to tell if they updated. Fortunately, which next step we choose doesn't matter much here, because the numbers we're talking about are so small. There is a larger conversation we could have, around whether we should make vulnerability scanning of relays a more common or automated or scaled thing. I like the idea in theory but in practice I don't think it should be a high priority compared to our other network health priorities. I'm tracking details and next steps about the cups issue on the gitlab ticket, https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/83 --Roger
Hi Roger,
There is a fine policy question here, which is "ok so what now? Do we leave them in place or bump them out of the network?"
This is just my experience, but reaching single node operators has become notoriously difficult - I frequently use metrics to find out-of-date / potentially vulnerable nodes and e-mail the associated e-mail address. On average 10% actually respond, but most don't care or simply forgot about their exclusively for Tor-purposes made e-mail address. I usually wait 48 hours, and if they didn't respond by then, I try again and wait another 24 hours. Most people actively monitoring their inbox would have either replied within 2 days, or after the second e-mail. If nothing happened after 2 e-mails and 3 work days, I usually give up. The fact that cups even binds to public interfaces and doesn't come by default with a whitelist for LAN networks is mind-boggling. I don't have any advice regarding flagging these nodes to be rejected by clients, since I don't know the volume of traffic they transport on a daily basis. Regarding scanning (exit) nodes for malicious behavior or vulnerabilities, I am all for it (as frequent as resources allow, but as fine-grained and accurate as possible at the same time) - I don't know the predicted percentage of LEO-ran nodes right now, but any percentage is too high. however, I know that it can be extremely hard to distinguish. I think nusenu had some great articles on the problem, and also some effective tools & algorithms to detect malicious nodes. Just my 2 cents.. All the best, George Hartley On Sunday, September 29th, 2024 at 6:15 AM, Roger Dingledine arma@torproject.org wrote:
On Fri, Sep 27, 2024 at 09:41:29AM -0400, George via tor-relays wrote:
There are some very significant recent CVEs out for CUPS, the unix printing system.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cups [...] Needless to say, a CUPS server listening on 631/tcp or 631/udp while providing Tor access is a bad idea.
George and I took the opportunity to scan relays and bridges to see if they have this vulnerable cups-browsed service running. We found 14 relay IP addresses that did, and 4 bridge IP addresses. This is a pretty good rate overall!
(I had been expecting to find more bridges, because they're more likely to be at home and people might be running them from their stock Ubuntu desktop install or the like. But we found very few, and maybe that is because at many homes everything is NATed/firewalled by default.)
12 of the 18 had proper contactinfo and I emailed them. One bounced, one replied and fixed it, and the others haven't replied yet.
There is a fine policy question here, which is "ok so what now? Do we leave them in place or bump them out of the network?"
I figure I'll wait a week or so and scan these 18 again. But I fear that the package "fix" will just correct a buffer overflow or something and it will leave the "they listen to the whole internet and add any printers that the internet sends them" behavior intact (because one is a bug, the other is a feature), so my scan won't actually be able to tell if they updated. Fortunately, which next step we choose doesn't matter much here, because the numbers we're talking about are so small.
There is a larger conversation we could have, around whether we should make vulnerability scanning of relays a more common or automated or scaled thing. I like the idea in theory but in practice I don't think it should be a high priority compared to our other network health priorities.
I'm tracking details and next steps about the cups issue on the gitlab ticket, https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/83
--Roger
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (3)
-
George -
George Hartley -
Roger Dingledine