Main menu

Invest in Reynolds Wrap, tin foil hats are back in style!

Security is a delicate balancing act.
On one hand, you have to be paranoid enough to dig into every function and feature of a system looking for a hole that could be exploited.
But you need to be able to step back and consider the real-world probability of such an exploit.

SmartScreen is meant to check that the applications you install are safe (i.e. not any known malware or virus). A researcher noted that when SmartScreen was enabled, information about downloaded applications is sent to a Microsoft server. The particular concern was that the name of the application is sent in simple base64 encoding. According to Mr. Kobeissi, this allows Microsoft to construct a database of every application you install on your computer.
Two problems with this theory:

IP address is the only identifier, which cannot reliably identify a single computer.
Between DHCP, NAT on IPv4, and privacy extensions on IPv6, the vast majority of machines will randomly change their IP address. However, there are systems which require a static IP address (mainly web servers and Internet Infrastructure) which could be tracked by this hypothetical database. Plus, the IP address isn’t not even included in the XML data. It would have to be tracked back on the web server.

Why on earth would they care to do this?
A database like this would be enormous. Why spend the time and resources to maintain such a thing with no tangible benefits. Microsoft would gain no real insight by storing all this data.

Occam’s razor would indicate that Microsoft is just comparing the hashed file contents to a stored blacklist.

Potentially they could do something fancier, like hold the infomation for a few days and cross reference this data with crash reports to find any common applications that may cause problems after being installed. Then they could update the blacklist table to include those new application signatures.

There are some minor security issues that are legitimate here. If someone were able to sniff the traffic from a specific machine, they could learn about some of the software installed. If any of that software is known to contain exploits, then the attacker will know exactly how to get into that system. However, this scenario requires an attacker to intercept and decode an SSL stream (not an easy feat), and after that’s been accomplished, the victim system must have SmartScreen enabled, and then download and install a piece of vulnerable software.

In a risk management analysis, this falls under one of the lowest likelihoods.

Now, although I feel this has been blown out of proportion (as do others), publishing this kind of information can still lead to improved security. In this case, the Microsoft server that received the data reported that it could use SSLv2, which is not as secure as SSLv3. Since the initial blog post, Microsoft has updated their web servers to only accept SSLv3.

I’m all for identifying and reporting security holes, but let’s not pretend a pinhole is equivalent to an open window.