[Mono-bugs] [Bug 81450][Nor] New - Two authenticode issues

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by pieter at mentalis.org.

http://bugzilla.ximian.com/show_bug.cgi?id=81450

--- shadow/81450	2007-04-25 10:34:50.000000000 -0400
+++ shadow/81450.tmp.13773	2007-04-25 10:34:50.000000000 -0400
@@ -0,0 +1,89 @@
+Bug#: 81450
+Product: Mono: Class Libraries
+Version: unspecified
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: Mono.Security
+AssignedTo: sebastien at ximian.com                            
+ReportedBy: pieter at mentalis.org               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Two authenticode issues
+
+I'm working with the authenticode classes in the 
+Mono.Security.Authenticode namespace, and I've hit two issues which I 
+believe are bugs.
+To let you guys quickly duplicate the problem, I've uploaded some binary 
+test files I'm using:
+http://pieter.mentalis.org/signed_files.zip
+ - "signed_file.exe" is a hotfix file I downloaded from Microsoft.com. It 
+is signed with a Microsoft Software Publishers certificate. According to 
+WinVerifyTrust, the file signature is correct.
+ - "invalid_signed_file.exe" is the same file, but I've changed a few 
+bits here and there. WinVerifyTrust says that the signature is invalid 
+(as I expected).
+ - "Microsoft_Root_CA.cer" is the Microsoft Root certificate. I extracted 
+it from 'signed_file.exe'. I copied this file to the Mono trusted CA 
+store (C:\Documents and Settings\All Users\Application 
+Data\.mono\certs\Trust)
+
+
+
+Problem 1:
+----------
+
+I've written a small application to test the Authenticode deformatter. 
+Basically, it consists of the following two lines of code:
+
+    AuthenticodeDeformatter adf = new AuthenticodeDeformatter
+(@"xxx\signed_file.exe");
+    bool it = adf.IsTrusted();
+
+Oddly enough, IsTrusted always returned false. The reason, according to 
+the defotmatter, was that the root certificate is not trusted (which 
+should not be the case, as I copied the certificate from the authenticode 
+file into the trusted store). Upon investigation, I found out that the 
+X509Chain.Build method always returned false, because a deeper call to 
+the 'IsTrusted' method (via the 'FindCertificateRoot' method) always 
+failed. Using QuickWatch, I was able to see that the TrustAnchors 
+collection _did_ contain the MS root certificate, and that 
+the 'potentialTrusted' certificate was indeed the same root certificate, 
+yet the Contains method returned that the certificate could not be found 
+in the collection.
+
+The reason of this error is that the comparison between the certificates 
+tries to compare MD5 hashes with SHA-1 hashes. The Hash property of the 
+certificate that is loaded from the authenticode file returns a SHA-1 
+hash, while the Hash property of the certificate loaded from the mono 
+trusted CA store returns an MD5 hash. Obviously, things go wrong when 
+trying to match these hashes.
+I don't know why one instance of the MS Root CA returns one type hash, 
+and the other instance another type of hash. I'll leave that up to you 
+guys :-)
+
+One last thought: if I remember correctly, the Windows CryptoAPI offers 
+you the choice between the 'defatult' hash of the certificate, the MD5 
+hash or the SHA-1 hash. It would be nice if Mono could do this too. In 
+this case, the bug would be trivial to fix: instead of asking for 
+the 'default' hash, you could match specifically on, for instance, the 
+SHA-1 hash.
+
+
+
+
+Problem 2:
+----------
+
+After changing some code such that the MS Root CA would be recognized as 
+a trusted CA, I tried verifying the "invalid_signed_file.exe". To my 
+amazement, this returned no errors. The AuthenticodeDeformatter.IsTrusted 
+method returns true, even though I would have expected it to return false.
+It could be that this is the intended behavior of the IsTrusted method 
+(there were no docs, so I couldn't be sure about that), but I don't see 
+any other method to verify the signature on the file.