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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Attachment:
publickey - hartley_george@proton.me - 0xAEE8E00F.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays