It sounds like its all very muddy water and fraught with dangers. and still you wont be sure.

Why not just test the WHOLE executable code itself? Thats definitive for ALL Tors and especially the ones who download the exe nd dont build their own (thats 95% - I’ve tried following Tor build instructions for many days and failed - its obviously a black art - “build your own version” is a Torland devs euphemism for - “go to hell”).

If each Tor also had a, rarely changing - no
more than every 2 years - & simple - so they could all compile it, binary comparator service running on port 9002 (say). Then this service could contact each other and request a segment (size to be determined - a reasonable chunk) of a fellow Tors exe, to check against their exe code.

If this check was done by every Tor on the network with one other Tor every 10 minutes, then gradually descrepencies could be found and offending servers isolated and informed.

A kind of voting system could be used.

Of course, Tors could only check like with like, if they ran the same version (& same os version).

But that wouldnt stop the Tor devs from putting all versions up for checking from the systems servers themselves, and by removing such support for old versions they could push those Tors into upgrade.

2 birds with one stone as it were!

The only problem, perhaps, with this system is those persons who have “custom built” their executables.

But they know who they are anyway, dont they, so no problem there then.

And its only fair that other TOR servers should also know who has “custom built” executables, so they may take action to protect themselves, if they feel the need!

Have you started work on a paper already?

No, not yet. I am considering it, but am still unsure whether it is worthwhile. The idea is quite obvious and the threat fairly obscure so I don’t think it would make a fantastic paper. There might still be some value in writing it up properly though. I felt the blog post was on the long side, but I did have to miss out many details. A short paper would still give a lot more space for expanding on these points.

As far as I can see, the only possible weak link is the process by which the user is informed where to check for the correct hash. If there is a centralised repo. for all open source software (like sourceforge etc.) this is a clearcut process. However if every software developer uses his/her own server to publish the hash, there is no secure way for the user to be directed to the uncompromised directory server.

Have you started work on a paper already?

my position is that if you want the OS to do the verification automatically, the process has to be real-time and online.

I don’t think the verification process can be automatic, at least until operating system vendors integrate a tool which will perform it. When the user downloads the source code, the build tools in the package are untrusted, so cannot be used. All the user has is what came with the operating system, of which I am using a hashing tool.

He can then manually compare the hash of the source package with the online list. It is tedious, but I cannot think of a work-around. However, it only needs to be performed by those who worry about being a target of the attack I describe.

Using a predefined list of servers does have the problem of a DoS on the process.

Yes, but a fairly minor one in my opinion. It only affects users who have just downloaded the source code. On discovering that the servers are down, potentially due to attack, they then have a choice of whether to just hope everything is OK, or to wait. The timestamping service I mentioned distributes hashes through Usenet, which provides some DoS resistance.

Also, I think that getting an authentic list of hashes is easier than anonymously getting a source code package.

I do need to go through the literature you pointed out but my position is that if you want the OS to do the verification automatically, the process has to be real-time and online. Using a predefined list of servers does have the problem of a DoS on the process. The crash of the one of the core Tor servers (moria?) that left all Tor server nodes hanging for couple of hours comes to mind.

How do you think this is going to play out?

Probably compromise of the distribution server, along with the signing key. If the attacker controls the downloading client then there is the additional problem of how to get hashes securely, but I discuss this more below.

This is important as in the latter case, the scheme you propose can be exploited to perform an effective DoS if all software installations report different hashes

Correct, but I am treating a DoS is better than compromise. In this case I would hope someone would raise an alarm that the developer key is compromised. Because OpenPGP signatures have non-reputability, anyone could publish two source packages, with the same version number and valid signatures, but with different hashes. Unless the developer has a very good excuse then the compromise would be revealed.

Does your threat model assume that except for the downloaded software, all the other system parts (compiler, OS etc.) of the user are trusted?

Yes, because if the OS is compromised then the attacker has much easier options. Perhaps curtained-memory could restrict the trusted computing base and allow some components of the OS to be compromised while still allowing my proposal to be implemented securely. I don’t expect this to be the case in the short term.

You are also implicitly assuming a collision-free hash function.

Yes, I do require strong collision resistance (incidentally, even though it used often, I don’t like the term collision-free since message digest functions have collisions, they just should resist discovery). I eagerly await a hash function which is considered to meet this requirement, but the current ones are either not analysed enough or too similar to known broken hash functions to make me confident.

Actually running the attack could be tricky, as the widely published version of the source code would need to have a magic BLOB somewhere, which might be hard to justify. Still, I would not rely on this for security as there have been demonstrations of plausible collisions in certificates and PostScript documents.

If I were deploying this scheme today, I think I would use two different hash functions, in the hope that making two packages which collide in both would be infeasible. Perhaps SHA-256 and RIPEMD-160 combined would be adequate.

So the threat model by extension would assume that these servers are not compromised.

Also true. My hope is that it is easier to have multiple directory servers than software distribution points. Also, I think that getting an authentic list of hashes is easier than anonymously getting a source code package. In principle, the hash of a daily table of version hashes could be published on paper and verified by potential users and server operators. The timestamping literature has a number of other schemes involving hash chains and trees, for example the PGP Digital Timestamping Service.

As I see it the source is hashed by the developed (and probably signed, although it assumed that this signature may be compromised)

The source code is signed, but the signature key might be compromised in my threat model. I assume that a significant number of server operators will compile from source, and the build process hashes the source for them. I also assume that some operators will check for backdoors and verify that the application publishes the true hash. These assumptions may be erroneous, but there doesn’t have to be a 100% guarantee of foul-play being detected. If the attacker has to pay a high cost for being caught, then only a small probability is needed for an effective defence.

Most software - even open source - is distributed as binaries.

Yes, this is one of the problems with the scheme. It only works when some server operators compile from source. The protection my proposal gives is through safety in numbers, but those who run pre-compiled binaries do not help, because they have no opportunity to check the source code for vulnerabilities. So I think that pre-compiled binaries should not publish their hash, and users of such packages should be concerned if they do.

In short the concept of publically available hashes appears to work for source code managment but I see problems in applying this to binaries.

I agree. If everyone uses pre-compiled binaries, then backdoors will not be detected through source-code inspection and my proposal does not improve the situation. Hashing the binary is undesirable because it will vary depending on compiler, it leaks more information than needed (see my reply to Adam S) and if it was not compiled by the user, does not offer protection.

Sometimes, that’s true. Other times, attack variants will crash the target, making it more important to get the right attack the first time. If there’s an attack ordering that gets around the DoS problem. then the worm still needs to fire off n times as many attack packets, which slows down propagation by a factor of N. From the perspective of a worm that wants to be fast spreading, that’s bad. From the defender’s perspective, its great.

You are quite correct that this scheme could be useful to attackers, so there is a trade-off to be made here. I am not particularly worried about this side-effect at the moment for a few reasons.

– Tor already publishes the version number, so this scheme is no worse than the current situation. Server admins concerned with the information leak could just as easily fake the hash and version. However if the scheme is forced, using a TPM, then there would be a problem.

– Fingerprinting networked applications is generally pretty easy. With access to the CVS repository, I think a good distinguisher for security relevant changes in Tor could be found.

– For worms there is generally little need to fingerprint, if it knows about multiple attacks, it just runs them all. Where it does make a difference is if attacks are time-consuming or risk crashing the application. This might be the case when protection mechanisms prevent a NOP “landing-pad” being created and force accurate address guessing (e.g. return to libc).

Attacks against an individual are more of a problem because here the attacker can fingerprint the application, then search for the right exploits. Also, it should be noted that the hash is over the source-code, not the binary or memory image, so compiler and OS added security features (e.g. stack canaries and address space randomisation) are not revealed. TPM based solutions might be more of a problem in this respect.