Security enhancement against malware for Tor

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified owner::ioerror priority::high resolution::implemented status::closed tor-client type::enhancement labels

This appears to be the way to disable attaching on Mac OS X: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/ptrace.2.html

I added that to the latest commit. I don't have a Mac OS X machine and so I haven't tested it.

To be clear on what this is trying to achieve, from IRC:

20:29 < nickm> Hm.  So as you see it, it's a forward-secrecy thing s.t. an 
               attacker who compromises the user running Tor should not be able 
               to deanonymize anything already started, or read any keys from a 
               tor process already created.
20:30 < nickm> Where we both agree that keys already deleted and connections 
               already closed at the compromise time are safe...
20:30 < nickm> and that keys created and connections made _after_ the 
               compromise are potentially vulnerable.

Yes, that's correct. We're not pretending we can protect a user forever - we're just protecting things within a specific window and from a specific kind of attacker.

I've pushed an updated branch and it supports both Mac OS X and Gnu/Linux; I think the Mac OS X support is superficial and isn't actually properly enforced as it is in Linux.

Replying to ioerror:

I think the Mac OS X support is superficial and isn't actually properly enforced as it is in Linux.

What makes you think that? My testing seemed to indicate otherwise

Oh hey. This has code, it should be in needs_review.

Trac:
Status: new to needs_review

Trac:
Milestone: N/A to Tor: unspecified
Version: Tor: unspecified to N/A

Merged with some additional cleanup. Please take a look to make sure I didn't miss anything, or mess anything.

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

Whoa - this doesn't look right: https://gitweb.torproject.org/tor.git/commitdiff/68114ca52cbed0b7970a60717be4ca22ffdc5d00

I have no idea why this change is in there:

V(DNSPort, PORT, "0"),

V(DNSPort, LINELIST, NULL),

Was that supposed to be in the diff? I don't remember making that change in my branch and if i did, I believe that is a mistake...?

My branch diff doesn't have it: https://gitweb.torproject.org/ioerror/tor.git/commitdiff/f79a75f59731eab85c019c41827c0c0e89d90498

Trac:
Status: closed to reopened
Resolution: implemented to N/A

Trac:
Status: reopened to needs_review

That's how git represents 3-way merges: note how there are two columns of + and - entries rather than just 1. The first column is stuff added and removed by your branch; the second column is stuff added and removed in master since the version of master that your branch was based on.

I believe the change in question got made as part of the stream-isolation refactoring of how we configure client ports.

Ah - OK - as long as that's noted, I think this looks fine.

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

Just a heads up, this is breaking the connection panel in arm (see the "New arm version doesn't show connections" thread on tor-talk@). I'll look into working around this later, though I'll probably need to warn the user that connection functionality will be broken unless they set "DisableDebuggerAttachment 0".

... yay. :(

I'm reopening this because this change is causing lsof to become nonfunctional, and other utilities like netstat and ss to be missing information. This change is not what Ubuntu is doing to prevent ptrace except by child processes - it's far more disruptive to users and the development I do because it makes '/proc//fd' only readable by root.

According to rransom and ioerror this isn't necessarily a bad thing, but I want to be very certain that this is what we want going forward (with signoff by Nick and Roger) because this is highly disruptive to arm. Here's the backlog...

12:37 < atagar> ioerror: Your ptrace change doesn't just mess with gdb but also changes the /proc permissions, partly messing with system utilities (netstat, lsof, etc) - is this really necessary?
12:39 < rransom_> atagar: I thought it was completely useless (They could just crack root and attach a debugger anyway). (Until it broke arm's connection view.)
12:40 < atagar> rransom_: Thanks, your trolling is charming. You can still get connections as root, and even non-root if you're fine with a few incorrect results.
12:44 < Sebastian> atagar: afaict all we do is prctl(PR_SET_DUMPABLE, 0);
12:44 < Sebastian> on linux
12:45 < Sebastian> atagar: that seems to indicate that whatever happens with /proc is necessary for this too, not sure
12:46 < atagar> gotcha, the thing that breaks direct proc reads (and probably is disrupting the pid/process name entry for netstat, ss and such) is the permissions on /proc/<pid>/fd
12:46 < atagar> dr-x------ 2 root   root   0 2011-12-17 12:02 fd
12:54 < atagar> hmm, the PRCTL man page makes it sound like this should only effect core dumps
12:54 < Sebastian> debuggers use the core dump facility
12:54 < Sebastian> (getting a core dump doesn't mean your process has necessarily crashed)
12:56 < Sebastian> there's also a documentation patch
12:57 < Sebastian> to explicitly mention that PTRACE_ATTACH is disabled
13:20  * atagar goes back to writing the stem general auth function
13:20 < atagar> Pathetically I've been meaning to write it for two weeks now but keep getting distracted by other things. Today victory *will* be mine. :P
14:40 < ioerror> atagar: yes, well, the new ubuntu sets it for all processes
14:40 < ioerror> atagar: so normal users can't dump your process that is already running (in the case of malware, it can't dump your ssh keys in memory and they're encrypted on disk, right?)
14:40 < ioerror> so this does actually help users
14:40 < ioerror> and yes, obviously if you can root the box, you win
14:48 < atagar> ioerror: if you're taking about the change for Maverick then that's something different (https://en.wikipedia.org/wiki/Ptrace#Support)
14:50 < atagar> The tor change is preventing lsof results, and dropping pid identifiers from others. I'm running natty and any builtin ptrace disabling isn't doing that.
14:53 < Sebastian> atagar: can you explain how exactly it is different?
14:54 < Sebastian> reading the wikipedia page doesn't directly tell me how it differs
14:54 < ioerror> thta is exactly the same
14:54 < ioerror> atagar: if you launch tor - can you attach to it?
14:55 < ioerror> atagar: in any case, with the ubuntu kernel set to disallow dumping, does arm break also?
14:56 < atagar> 'can you explain how exactly it is different?' -> I mean that it's differnt behaviorally. If natty is preventing ptracing (as the article suggests) then it's doing it in a way that doesn't break proc/lsof/netstat/etc.
14:57 < bliss> you might be seeing problems with yama
14:57 < bliss> try echo 0 > /proc/sys/kernel/yama/ptrace_scope
14:57 < bliss> (not on a production machine, just if you're developing on that box)
14:58 < ioerror> atagar: i don't buy that me setting PR_SET_DUMPABLE breaks all those tools alone
14:58 < ioerror> atagar: can you show me documentation of that?
14:58 < atagar> 'in any case, with the ubuntu kernel set to disallow dumping, does arm break also?' -> I don't have any reports of breakage, except via the tor change. The other report (from Stephan) looks to be a difference in proc formatting on debian.
14:59 < atagar> ioerror: did you read my last message on the tor-talk@ thread?
14:59 < atagar> if so then you should be able to easily repro
14:59 < ioerror> atagar: i don't have arm on aan ubuntu box right now
15:00 < atagar> you don't need arm, you need netstat/ss/lsof
15:00 < bliss> PR_SET_DUMPABLE just prevents non-root process from ptracing the calling process
15:00 < ioerror>  ps auxw|grep tor|wc -l
15:00 < ioerror> 12
15:00 < ioerror> io        2096  0.1  1.2  71700 26724 ?        S    Dec15   2:28 /usr/sbin/tor
15:00 < ioerror> so i have a tor running as me
15:00 < bliss> Yama, which is on more recent ubuntus, prevents ptrace attaches to anything except child processes
15:00 < ioerror> and yes, i agree:
15:00 < ioerror>  lsof -ni|grep -i tor|wc -l
15:00 < ioerror> 0
15:01 < ioerror>  sudo lsof -ni|grep -i tor|wc -l
15:01 < ioerror> [sudo] password for io: 
15:01 < ioerror> 11
15:01 < ioerror> so lsof on ubuntu no longer shows the connections of my own tor
15:01 < ioerror> ironically, ssh and other things do show up :)
15:01 < ioerror> good to know which processes that i can dump when i'm malware
15:01 < atagar> also try "netstat -np", you'll find that tor connections are missing the PID/process name identifier
15:01 < ioerror> that's awesome
15:02 < bliss> you shouldn't be able to dump those as malware either though
15:02 < ioerror> bliss: depends on the platform
15:02 < bliss> not sure if it's ptrace behavior that's affecting the lsof output there
15:02 < bliss> on ubuntu
15:02 < bliss> (maverick or later)
15:02 < ioerror> atagar:  netstat -tnp shows:
15:02 < ioerror> tcp        0      0 127.0.0.1:9051          127.0.0.1:36248         ESTABLISHED -  
15:03 < ioerror> tcp        0      0 127.0.0.1:9050          127.0.0.1:59626         ESTABLISHED -  
15:03 < ioerror> tcp        0      0 127.0.0.1:9050          127.0.0.1:60560         ESTABLISHED -  
15:03 < atagar> bliss: the PR_SET_DUMPABLE option that he's setting is making /proc/<pid>/fd only readable by root, which is what's breaking lsof
15:03 < atagar> ioerror: right, that "-" is the issue :)
15:04 < bliss> atagar: you sure that changes permissions on /prrc/pid/fd?
15:05 < Sebastian> bliss: yeah, some googling also reveals reports of that
15:06 < bliss> ok, that's interesting, wasn't aware of that
15:06 < ioerror> atagar: it is?
15:06 < bliss> finding the kernel code now, should be easier
15:07 < atagar> ioerror: dr-x------ 2 root   root   0 2011-12-17 12:02 fd
15:07 < ioerror> atagar: i'm not sure what to tell you other than "damn, that is really annoying that this kernel hardening feature works so well."
15:07 < ioerror> atagar: i think this means that tor must send that info to you via the control port
15:07 < ioerror> atagar: and actually, i think that is good
15:08 < ioerror> atagar: it means that a local user on a box can't tell what tor is doing for another user (!) unless they can pop root (!)
15:08 < ioerror> atagar: is that actually waht you're telling me? If so, I can't believe that worked so well
15:08 < ioerror> atagar: also, man, that really relaly needs to be well documented 
15:08 < ioerror> atagar: like, whoa bug in documentation :(
15:09 < atagar> If you're trying to match the protection in ubuntu then this isn't getting parity. If your goal is to break lsof/netstat/etc then ok, I'll try to make arm take this into account and warn the user.
15:10 < atagar> 'it means that a local user on a box can't tell what tor is doing for another user' -> Hm? It breaks if you're the same user too.
15:11 < bliss> code is in fs/proc/base.c, if you're curious :-)
15:12 < bliss> ownership of /proc/pid is changed to pid only if the task is dumpable
15:14 < Sebastian> that's what happens during setuid?
15:14 < bliss> no, during prctl with PR_SET_DUMPABLE
15:14 < Sebastian> interesting
15:15 < bliss> setuid has other behavior
15:15 < bliss> ownership is rewritten during setuid, but /proc/pid/fd has a special handler so a process can always access its own fd directory after setuid
15:19 < atagar> I'm not really clear from this backlog, are we trying to break those utilities or is this a bug? May I reopen 3313 with this backlog? nickm: you should probably be aware of this too :)
15:22 < Sebastian> atagar: From what I gather from what ioerror and rransom_ said it was an unintended but not unwelcome side-effect
15:33 < ioerror> atagar: my goal is to prevent dumping
15:33 < ioerror> atagar: ubutnu has a kernel patch to try to do it system wide but tor runs on lots of systems and not just ubuntu
15:34 < ioerror> atagar: my thought is that you should not be able to get that info unless tor gives it to you or you are root (which can sniff the network anyway)
15:34 < ioerror> I think this is not unwelcome for me but clearly, it is a pain in your ass :(
15:34 < ioerror> it was not intentional to break lsof and sss
15:34 < ioerror> and other tools
15:37 < atagar> 'unless tor gives it to you or you are root' -> I agree with the added bit of "or if you're the same user as tor". We don't want to suggest root for controllers and tor isn't gonna be emulating every *nix utility.
15:37 < atagar> armadev, nickm: Please confirm that this is what we want going forward, and then I'll try to take it into account for the future. I've relied on utils like lsof quite a bit so I want to be clear that they'll be routinely non-functional from now on since this impacts how I develop things.
15:37 < atagar> (And just to be clear, this really bugs me. I hope this added protection over what Ubuntu does by default is important because it puts me in the awkward position of either dropping a major feature or suggesting that users routinely set "DisableDebuggerAttachment 0")
15:38 < ioerror> atagar: i don't want to sugget root for controllers - i think tor should give you the info you want if you're authorized to have it
15:38 < ioerror> atagar: DisableDebuggerAttachment should not be set to 0; we should find a way to fix this for everyone
15:38 < ioerror> i have to go now
15:39 < atagar> Ok. We need to continue this discussion and get nickm and armadev's input so I'll move this back to trac.

Trac:
Resolution: implemented to N/A
Status: closed to reopened

My two cents on this, btw, is that this is a major bug with this feature and DisableDebuggerAttachment should be disabled by default until it's fixed (probably by asking Ubuntu how their ptrace protections work). The arguments for breaking lsof and others on purpose has been...

"< ioerror> atagar: my thought is that you should not be able to get that info unless tor gives it to you or you are root (which can sniff the network anyway)"

Which I disagree with for a couple reasons...

Realistically we will not be investing the time to re-implement connection utilities. I made a proposal for getting this information from the control socket years back. It's collecting dust because I'm the only tor dev that cares about it, and C coding isn't the sort of thing I do for fun after a day of work. ;)

In essence by saying "unless tor gives it to you" you're saying that controllers should never have this information which I strongly disagree with. If people have an issue with how I'm scrubbing the data then please file a ticket against arm. Otherwise, relay operators have a right to have some idea of the activity going on with their own systems.

Also, this change does not prevent controllers from getting tor connection information, it only prevents controllers from differentiating tor connections from others that aren't associated with applications. In other words this change screws with arm, but not malware in this respect.

That leaves the "or you are root" and we do not want to start encouraging controllers to need root permissions. We already do this for writing to the Debian torrc which has been a pita (breaking SETCONF and leading to weeks of effort by Jake to make a setuid workaround). Most platform already restrict the connection information when your lack the permissions of the tor process, and this seems good enough for me.

I'm flagging this as a blocker since I really don't want to see this make it out of alpha without being addressed.

Trac:
Priority: normal to blocker

Replying to atagar:

My two cents on this, btw, is that this is a major bug with this feature and DisableDebuggerAttachment should be disabled by default until it's fixed (probably by asking Ubuntu how their ptrace protections work). The arguments for breaking lsof and others on purpose has been...

"< ioerror> atagar: my thought is that you should not be able to get that info unless tor gives it to you or you are root (which can sniff the network anyway)"

Which I disagree with for a couple reasons...

Realistically we will not be investing the time to re-implement connection utilities. I made a proposal for getting this information from the control socket years back. It's collecting dust because I'm the only tor dev that cares about it, and C coding isn't the sort of thing I do for fun after a day of work. ;)

ssh-agent does this exact protection - it is assumed that the stuff in memory is more sensitive than the stuff on disk. This is the same case for Tor - the circuits I just built are sensitive and should be forward secret as much as is possible.

In essence by saying "unless tor gives it to you" you're saying that controllers should never have this information which I strongly disagree with. If people have an issue with how I'm scrubbing the data then please file a ticket against arm. Otherwise, relay operators have a right to have some idea of the activity going on with their own systems.

I think that it is reasonable for Tor to send it to controllers at the level it feels is safe to reveal. I think it's weird to suggest that this is a right and furthermore it is a bit odd to suggest that my patch violates that right... You can still get a lot of that information and I think a good fix would be to extend what Tor sends to arm.

Also, this change does not prevent controllers from getting tor connection information, it only prevents controllers from differentiating tor connections from others that aren't associated with applications. In other words this change screws with arm, but not malware in this respect.

Malware can't connect to Tor at all unless it has the control password, right? If it can dump memory of Tor, it can get the password and of course all the previously built circuits still in memory, etc.

I don't think this patch is perfect but I think it's not reasonable to suggest that it has no impact on malware running as the same user or as a different user that is not root on the same system. Can you demonstrate otherwise? Without restarting Tor?

That leaves the "or you are root" and we do not want to start encouraging controllers to need root permissions. We already do this for writing to the Debian torrc which has been a pita (breaking SETCONF and leading to weeks of effort by Jake to make a setuid workaround). Most platform already restrict the connection information when your lack the permissions of the tor process, and this seems good enough for me.

This is a side effect of stopping someone from core dumping Tor as it is running unless it launches it. Another way to fix this might be to launch Tor from arm as a normal user?

I'm flagging this as a blocker since I really don't want to see this make it out of alpha without being addressed.

This doesn't block a release; I agree that we should consider the impact.

Trac:
Priority: blocker to major

Little update from what ioerror and I have been discussing on irc. We have a partial workaround that limits the impact on arm - since we still have netstat results I can filter on the uid of the tor owner rather than the pid. This has the obvious disadvantage that it may be overly inclusive if tor isn't run under a dedicated user, but should be fine for the deb use case.

I'm not sure how this will work for BSD platforms because neither netstat nor proc contents are available there. That said, I'm not sure if this feature effects lsof/sockstat/procstat at all on that platform so it may not be an issue.

-Damian

PS. Sorry for flagging this as a blocker. I didn't realize that we reserved that status for critical security issues. At work it just means that it needs someone to look at it before final release.

Replying to atagar:

Little update from what ioerror and I have been discussing on irc. We have a partial workaround that limits the impact on arm - since we still have netstat results I can filter on the uid of the tor owner rather than the pid. This has the obvious disadvantage that it may be overly inclusive if tor isn't run under a dedicated user, but should be fine for the deb use case.

Right - so in essence we get all the security features we want, we look at /proc/net/tcp for a reasonable guess and on Debian systems or any systems with a dedicated uid, we're pretty much certain.

I'm not sure how this will work for BSD platforms because neither netstat nor proc contents are available there. That said, I'm not sure if this feature effects lsof/sockstat/procstat at all on that platform so it may not be an issue.

Using these tools as an API is not stable. What if the OS had changed this? That is - what if the Ubuntu kernel change had caused this? As it stands, arm won't work on grsec enabled kernels that have similar restrictions as far as I can tell.

-Damian

PS. Sorry for flagging this as a blocker. I didn't realize that we reserved that status for critical security issues. At work it just means that it needs someone to look at it before final release.

We're pretty far from a final release and it's good to highlight the issues.

The good news is that what we have lost by adding this feature is literally this and this alone:

01:16 < atagar> if we're looking for the subset then we can simply look at the return values for the connection utils - that's all I care about :)
01:17 < atagar> so that would just be the current ip/port on the local and foreign end
01:17 < atagar> everything outside of that I discard
01:17 < atagar> getting this from the control socket has the obvious advantage that we can get extra information that I currently need to infer
01:18 < atagar> like which connections are exit/client and hence private
01:18 < atagar> or which are directory/hidden service/client related
01:19 < atagar> here's the proposal we came up with: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/172-circ-getinfo-option.txt
01:20 < atagar> hm, forgot we had dropped connection info from that proposal

So - the main change is the connections that are ESTABLISHED or in a phase of connecting is that only information that is lost. I think that this is something that we could add to the heartbeat - arm could then get the information directly from Tor and it would be portable. We already have an internal state for those connections that includes important metadata anyway, right?

Right - so in essence we get all the security features we want, we look at /proc/net/tcp for a reasonable guess and on Debian systems or any systems with a dedicated uid, we're pretty much certain.

Yup. I'll probably check if the uid belongs to debian-tor and, if not, give a warning about possible bad data in the connection panel since custom setups are more likely to have non-dedicated users.

Is there anything tor could check to see if the kernel already has ptrace protections built in and, if so, not do it ourselves? This would mean that on Ubuntu or other platforms with ptrace disabling built in arm would work normally (between that and our workaround I'd be happy to call this good).

Using these tools as an API is not stable. What if the OS had changed this?

I know, more than any of us, just how unstable these utilities are. I've spent months making them work on Debian, Ubuntu, Gentoo, OSX, FreeBSD, OpenBSD, and others, some of them with some damn strange quirks. For instance on OpenBSD the ps variant shows a process' uptime in...

in local time
with AM/PM rather than 24 hour time
the whole f*ing format changes based on if the uptime is over a day or not

... in the end I decided that one was simply unparseable. I agree that ps, netstat, and other system commands are, in git terminology, porcelain. Proc contents tend to be more stable but don't exist in the BSD family. If I could get the data I need from tor then great. My use of system commands are simply because they both work well enough in practice and don't require developing in C (something I find about as appealing as an unanesthetized root canal).

Cheers! -Damian

Replying to atagar:

Right - so in essence we get all the security features we want, we look at /proc/net/tcp for a reasonable guess and on Debian systems or any systems with a dedicated uid, we're pretty much certain.

Yup. I'll probably check if the uid belongs to debian-tor and, if not, give a warning about possible bad data in the connection panel since custom setups are more likely to have non-dedicated users.

Why not exclude the data in that case?

Is there anything tor could check to see if the kernel already has ptrace protections built in and, if so, not do it ourselves? This would mean that on Ubuntu or other platforms with ptrace disabling built in arm would work normally (between that and our workaround I'd be happy to call this good).

I don't think that is a good idea. I do not believe there is a portable way to test for such a similar kernel feature across the platforms where we call ptrace.

Using these tools as an API is not stable. What if the OS had changed this?

I know, more than any of us, just how unstable these utilities are. I've spent months making them work on Debian, Ubuntu, Gentoo, OSX, FreeBSD, OpenBSD, and others, some of them with some damn strange quirks. For instance on OpenBSD the ps variant shows a process' uptime in...

in local time

with AM/PM rather than 24 hour time

the whole f*ing format changes based on if the uptime is over a day or not

... in the end I decided that one was simply unparseable. I agree that ps, netstat, and other system commands are, in git terminology, porcelain. Proc contents tend to be more stable but don't exist in the BSD family. If I could get the data I need from tor then great. My use of system commands are simply because they both work well enough in practice and don't require developing in C (something I find about as appealing as an unanesthetized root canal).

That sounds painful! So I'm on the same page with that - can you confirm that the one thing you are now missing is the state of the connections as the system would see them? If we can export that from tor, would that improve your (arm development) life overall? :)

Why not exclude the data in that case?

Certainly could. Couple options are to disable the connection panel or show the uid filtered results anyway, hoping that they just belong to tor. I should probably make the choice between those a config option.

I don't think that is a good idea. I do not believe there is a portable way to test for such a similar kernel feature across the platforms where we call ptrace.

Pity. Cest la vie.

can you confirm that the one thing you are now missing is the state of the connections as the system would see them?

Almost. The most noticeable file descriptor use was the periodic snapshot of our current connections [1]. As we've discussed, at its core that's just a tuple of the form... [(local_ipAddr1, local_port1, foreign_ipAddr1, foreign_port1), ...]

Another usage that comes to mind (and this isn't vital) is that I'm using the proc contents to determine the number of file descriptors tor is currently using [2]. This is so I can warn the user when they're reaching their limit and show the count (Roger one mentioned that he thought this was a neat feature). We planned to get this from the control socket in one of our proposals [3] but it wasn't implemented.

If we can export that from tor, would that improve your (arm development) life overall? :)

Get connection information that matches system resolvers from tor? There is a Santa Clause! :P

Cheers! -Damian

[1] https://gitweb.torproject.org/arm.git/blob/HEAD:/src/util/connections.py#l212 [2] https://gitweb.torproject.org/arm.git/blob/HEAD:/src/util/torTools.py#l1218 [3] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/173-getinfo-option-expansion.txt#l68

Oops, forgot about another use. Before authenticating to the control port I use connection results to determine tor's pid, which in turn is used to get its cwd. This is to work around... https://trac.torproject.org/projects/tor/ticket/1101

rransom has been working on a fix so that workaround might be needed soon. :)

Few more broken things (uggg)...

10:07 < atagar> awww, pesky - the anti-debugger change also makes the /proc/<pid>/cwd symlink only readable by root, which in turn breaks pwdx
10:07 < atagar> "pwdx 3341" => "3341: Permission denied"
10:07 < atagar> "lsof -a -p 3341 -d cwd -Fn" => "n/proc/3341/cwd (readlink: Permission denied)"

This was implemented. If someone wants to argue further for reverting the patch, open a new ticket. (It sure has been a pain in my, er, backend.)

Trac:
Status: reopened to closed
Resolution: N/A to implemented

Trac:
Keywords: N/A deleted, tor-client added

Trac:
Component: Tor Client to Tor

closed

mentioned in issue #4650 (moved)

mentioned in issue #15259 (closed)

moved to tpo/core/tor#3313 (closed)

mentioned in issue tpo/core/tor#4650 (closed)

Security enhancement against malware for Tor

Child items ...

Activity