Signature checking in Wine

[Paul Millar]

Hi Juan,

On Friday 25 July 2008 16:49:34 Juan Lang wrote:
[...]
> > Please, either tell me I'm wrong, or make Wine honest about what it's
> > telling the user.
>
> No, you're not wrong, and this email was my attempt at being honest.

... and your honesty is appreciated!

> I'll point out that there are other avenues of attack that can lead
> Wine to "mislead" the user about who signed an executable.

Security often involves providing many barriers.  There's a tacit assumption 
that none are going to be perfect.  A common mantra is "security in depth".


> [...]  With the size and complexities of today's software, 
> and with signatures only being affixed to the largest and most complex
> software, I'll state that in my opinion it's the signed software which
> is more at risk than the unsigned software.

As an aside: this looks to me like a logical fallacy.  If I may rephrase your 
argument:
  1. Most signed software is from a large code-base (probably true)
  2. Large code-bases are more likely to have vulnerabilities (probably true)
  3. Therefore, signed software is more likely to have vulnerabilities (wrong: 
not deducible)
See:
	http://en.wikipedia.org/wiki/Fallacy#Logical_fallacy


> If you believe a piece of software signed by Microsoft (or Apple, or...) is
> any more trustworthy than some random piece of code, you needn't
> look far to disabuse yourself of that notion.

Whether the code operates correctly (e.g., doesn't crash, taking out your 
filesystem and burning down your house) isn't under scrutiny.  You are quite 
right in saying that a software having a valid digital signature from 
Microsoft makes no statement whether the software will work.  Maybe it does, 
maybe it doesn't.  But, this isn't what digital signatures are about.

Instead, signed software attempts to prevent silent injection of Trojan 
software.  The question is rather: did this software which claims to come 
from Microsoft really do so?  Has it been hacked to include some "additional 
functionality"?

A digital signature makes one precise statement: that someone (or some agent) 
with access to the corresponding private key decided to sign the software. 

If you also trust that:
  1.	you have the correct public key for the certificating authority
	(CA) that issued the code-signing certificate,

  2.	the CA are doing their job correctly,

  3.	the recipient of the code-signing certificate tries to ensure that
	the key is only used to sign their own software (e.g., hasn't been
	silently stolen).

then you can be pretty certain that, if some software was signed by a valid 
code-signing certificate, that the software is the genuine article.


> Even so, an exploit is far more likely to target Windows, and perhaps
> to fail on Wine, than it is to target Wine.

Well, maybe, but (without being too paranoid) it is possible to target attacks 
against individuals through on-the-fly rewriting of packages, or through DNS 
poisoning, or transparent web-proxies that parse the HTTP User-Agent string, 
or ...

> I'm not attempting to hide behind a security through obscurity defense.
> I'm pointing out that even if digital signatures meant anything--and I
> maintain that they don't--the probability of their being attacked in Wine is
> very low.  Therefore, from a risk management point of view, there's no
> compelling reason to fix it.

The risk-analysis processes I've been involved with combining two metrics, 
likelihood and impact, to provide a combined risk metric (e.g., multiplying 
the two numbers).

So, if I may counter your argument: I believe your analysis fails to take into 
account that the vulnerability may be targeted and that automated updates may 
make use of digital signatures (so greatly increasing the likelihood) and the 
effect is the end-user running an arbitrary, targeted payload (so the impact 
is pretty high).

> I may fix it someday, but as I said before that wouln't remove all code
> signing vulnerabilities from Wine, it would only remove this particular one.

OK, but generally speaking bugs are fixed one at a time.  I may have missed 
your point here, but (in general) just because there are other bugs exist 
doesn't preclude fixing an specific bug.


> If you disagree, patches are welcome.

Sure ... and this is the acid test!

If no one spends the time to fix the problem then it isn't so important. (I 
know I fall foul here from having far too little spare time ;-)

But, to be honest, I'm a little surprised this made it into wine.  The policy 
used to be something like "no hacks to support a specific application".  I 
haven't seen the patch(es) but from how you've described it, this doesn't 
seem to pass the sniff test.

I think one should at least warn the user that the code has not been check 
thoroughly.  The alert dialogue box could include a "don't show this message 
again" check-box, but I feel we should allow Wine users to care about this.

Friendly,

Paul.