George Shaffer <George.Shaffer@xxxxxxxxxxx> wrote: > On Mon, 2006-10-23 at 08:22, Fabian Keil wrote: > > George Shaffer <George.Shaffer@xxxxxxxxxxx> wrote: > > > > > > The risks of JavaScript, Flash and friends are mentioned > > > > several times in the docs. > > > > > > Haven't the authors of the report that you seem to object to so much > > > made a dramatic demonstration of this. The products you mention are > > > used by many content providers, and many web surfers, even > > > knowledgeable ones, like the "rich" experience and are willing to > > > sacrifice security and privacy for it. > > > > And they constantly get what they deserve. . . > > If a member of your family is sick with a contagious disease, and you > tend to them, do you "deserve" to get the disease? It might be smarter > to stay away and call a doctor, but perhaps you get infected before you > knew a doctor was needed, or while waiting for the doctor, or can't > afford a doctor. I fail to see the similarities between willingly sacrificing security and privacy for '"rich" experience' and caring about ones family. > > It was already a well known and documented fact that Tor exit > > nodes can alter unencrypted traffic. And even if this wasn't > > documented, just thinking about it would make it clear. . . > > That would depend on how well you understood how Tor works, and more > generally your understanding of computers, which to most people are > pretty much a mystery. Of course you're right, but I assume the people you mentioned wouldn't find and read this paper either. > > > There is another reason for not running a Tor server even if my ISP > > > allowed it. I have a dedicated "stealth" firewall (protecting a > > > personal desktop with little of intrinsic value). There is no chance > > > I would poke holes in its configuration. . . > > > > Anyone interested whether or not your IP address is currently in use > > only needs to do a port scan. > > Are you sure? By "stealth" I mean a firewall that drops packets on > blocked ports (and ICMP) and returns no packets, regardless of whether > probing packets are properly formed or deliberately misformed. A scanner > (at least theoretically) gets exactly the same response as from a > computer that is turned off. This only works if every single port and > ICMP are blocked (stealth). A single open, or closed port, will reveal > unequivocally to a port scan that there is a working computer at the > target IP address. If the target IP address is unused, the scanner gets an error message send from the router located one hop before the target. If the scanner doesn't get this error message, it's safe to assume that the target system is running. > > And if you can't trust your firewall > > enough to work in cases where someone knows that your IP address is > > in use, you should get a firewall that actually works anyway. > > One might conclude, if one assumed these couple smart alec remarks > represented your entire knowledge of firewalls, that you don't seem to > know that once you open a port in a firewall to a server, e.g., Tor and > port 80, that the firewall cannot protect that server. The packet filter can still protect all other ports and increase the chances that the packets arriving at the Tor running server are valid. The Tor server's host system can make sure that a compromised Tor server doesn't cause too much damage. As a OpenBSD user you will be aware of systrace, other systems have similar tools. > It's not that I don't trust my firewall, I just don't want to invite > random attacks, because a broad probe of many port 80s, happens to find > an open one on my machine. I hope you're not suggesting Packet Filter on > OpenBSD does not work. I don't. But if by "random attacks" you mainly mean DoS attacks I can see your point. > Now that I've already told you something about my system, if you think > you are smart or knowledgeable enough to get past my firewall, I'll be > glad to give you permission to try. I didn't claim that. > (Recently when I again got unexpected content as was discussed in a > recent thread, I scanned the Tor exit node from grc.com, and both 80 and > 443 showed as open, where the others showed as stealth. This means Tor > is responding, even though the incoming packet is not a Tor packet. > Other explanations? I did not write down the IP, and have no knowledge > of the OS or firewall in use on that exit node.) Depending on your scan it probably wasn't Tor, but the underlying OS which answered your scan. Of course this doesn't change the fact that Tor doesn't operate invisible, but this shouldn't be a major problem. > Either way though, packets are now sent from the Tor node system that > can be fingerprinted to determine the OS, version, and some other facts > about the OS running the Tor node and possibly firewall. A port scanner > will quickly show other ports as blocked. The attacker can't immediately > know if the open service is on the firewall machine or being passed to a > machine behind the firewall. A careful packet analysis may reveal this. > >From this the attacker can look to see if there are any known bugs for > the probable firewall running on that system, and if so possibly launch > a focused attack. Alternatively, the attacker can focus directly on the > open port 80. > > All this from someone doing random scans for an open port 80. Before the > scan they probably would have not known the IP was in use. Now they have > much of what they need to try to attack the system. So they should see that you don't run a system with known vulnerabilities and the best they can do is to run a DoS attack to clog your Internet connection. Running a Tor node probably increases the chances to get attacked a bit, and if the connection to the Internet isn't good enough this might be quite annoying, but for your security it shouldn't make a difference. > Does Tor have any buffer overflows that can be exploited? I surely don't > know. And no, I am not running Tor as root, but that still does not mean > someone could not make a nuisance of themselves. Perhaps Tor can be > crashed remotely. If so, an attacker might arbitrarily crash Tor every > one to six hours. This could be automated. Every so often I'd have to > troubleshoot to figure out why I could not connect with Tor. Any circuit > passing through the node would be disrupted. You don't have to use the same Tor process as server and client and if such an attack was possible, your server wouldn't be the only one affected and you would probably have connection problems anyway. > The simple fact is that anyplace you have no public (accessible by the > outside) services, your security must be weakened, if you add a Tor node > anywhere in your local computing environment. As mentioned before, if you think the risks for your local network are too high, you can always get a dedicated server for Tor. > Once a single malicious attacker decides to focus on > Tor, he can get the source code to help him, but the Tor community does > not have the resources to find a quick solution, the way the large open > source communities do. Even if this was true, this should only affect your decision to use Tor at all and isn't specific to running Tor as a server. And looking at larger open source projects I fail to see the correlation between community size and security. Just have a look at how long it takes for the average remote exploitable flaw in PHP or Firefox to get fixed. Fabian -- http://www.fabiankeil.de/
Attachment:
signature.asc
Description: PGP signature