In the wake of the recent Adobe code-signing debacle, this is a good time to revisit other failure modes of code signing. Recently this blogger tried downloading an evaluation copy of Microsoft Office and noticed a strange warning dialog about the installer being signed by “Digital River.” (Granted, that could make the author one of 5 people in the world paying attention to such warnings– and not proceeding with running the installer as a result.)
Who was Digital River and why would software published by MSFT carry a signature of any corporate entity other than MSFT itself? From a pure authentication perspective, the situation looked indistinguishable from a man-in-the-middle attack, where some nebulous attacker on the network observed the download request and clumsily substituted a Trojaned application instead, hoping the user would not notice the difference. The code was downloaded straight from the official Office website, a page that is not served over SSL. Or perhaps the servers hosting the application had been breached and started distributing malware to unsuspecting users hoping for free copies of Office.
Cursory Googling revealed a more benign, mundane explanation that did not involve malfeasance: Digital River hosts the official online MSFT store, serving as the distribution channel for purchasing software via direct download model. (Top search results include a forum post from 2009 featuring an irate customer titled “digital river does not deserve to be microsoft default agent”) But the same search also turned up a disturbing presentation on F-Secure website by Jarno Niemelä, dating back to 2010. The good news: it confirmed that Digital River does in fact handle software distribution for many published besides MSFT, and even digitally signs the applications on their behalf– that would explain the Authenticode dialog above. That alone does not make it safe to proceed past the dialog: all it means is that trust in the purposed Office installer is only as good as the trust in all other software signed by DR. After all any one of the other applications bearing the identical signature could have been substituted in its place, if the only criteria for establishing trust is that certificate. What else has DR signed? That is the really bad news: DR had been caught signing malware, as well as installers which were effectively open-ended: meta-installers designed to invoke other installers from third-party URLs that DR had no control over.
Vouching for the integrity of applications one has no control over is at best extreme naivete, and at worst, willful negligence under the guise of solving a problem for software publishers. There is no question that unsigned code is a user-experience problem: web browsers and A/V react differently, and present danger-Will-Robinson warnings when confronted with applications of unknown origin. That is by design. “Solving” that problem by having another company sign anything thrown its way undermines any security benefit of code authentication. These technologies are rooted in the principle that trust– or lack thereof– in software is derived from trust in the identity/brand of the publisher. When that identity is laundered by having some other entity such as Digital River putting its own brand on the product without conducting due diligence, it removes any semblance of accountability from the original author.
Returning to the example that served as the jumping point for this post, Office derives its credibility from having been authored by MSFT– not by virtue of being distributed by Digital River. That same code carry exactly same degree of trust regardless of its download location. In fact being signed by Digital River subtracts from the credibility of the code, which is exactly the opposite of intended effect. An up-and-coming software company with no brand recognition might benefit from using the service: after all, anything beats the unsigned code warning. (But then again, Digital River is not exactly a household name either. The only reasons to prefer that over having your own certificate could be the cost and difficulty of implementing code signing– just ask Adobe.) In the case of MSFT, there is net loss of trust in the end product.
Luckily Office 2013 preview is also available for download. It carries the expected MSFT signature.