Thursday, April 7, 2016

Microsoft Introduces Early Beta of GNU/Windows

Microsoft recently release Insider Preview Build 14316 of Windows 10. This preview includes the option of adding a GNU/Linux user-land. So, really just a GNU user-land and early support for a Windows-to-Linux kernel call conversion library. Basically, the reverse of the Wine project.

This is hardly the first time Microsoft has done something similar. There used to be UNIX tools for Windows. Initially it was available as a free download, later it required the "pro" version of Windows, and ultimately it was scrapped. To my knowledge Microsoft never published a reason for scrapping the UNIX tools but I have always assumed it was a lack of maintaining the code and eventually the tools just didn't work properly with newer versions of Windows.

There has also been, for a very long time, the open source Cygwin project. This project has provided a GNU (and X11) user-land to Windows for nearly 2 decades now. The last time I tried Cygwin, it worked very well. Of course, Microsoft's solution is technically still in beta. And this being the first release to the Insider program, we should expect improvements on Microsoft's solution.

For its part, Microsoft has chosen the Ubuntu user-land. Complete with package management and development tool. While many people may consider this a success for the Linux community, I'm not convinced it is much more than a marketing ploy to try and attracted Linux users to Windows. It might be an attempt to satisfy the corporate data-center folks who have to deal with Windows on the desktop while managing UNIX and Linux systems in their data centers but I doubt that.

There are too many options these days to need a Linux user-land on a windows desktop. With reliable Secure Shell (ssh) tools easily available, a few options to get X11 to run on Windows, and the robust capabilities and selection of VM solutions available on the desktop, in addition to the age old solution of dual-booting, there is no longer much need for a UNIX user-land on Windows. That being said, if Microsoft is actually going to stay committed to this, I applaud their efforts.

As I said earlier, I suspect that this is Microsoft's attempt to get some Linux users to return to Windows. They would only get the fence sitters and at this point, I think they have missed the reason why there has been an increase in the number of fence sitter. It's not the availability of tools, it's the invasion of privacy and lack of control of one's own hardware that has got many people moving away from Windows since the Introduction of Windows 10.

For those who don't know, Microsoft has made Windows 10 call home so much that many security minded corporations are flat out refusing to let it in their organizations. Only the most expensive of the numerous Windows 10 license options actually lets you completely disable the call-home functionality of Windows 10. In my experience corporations don't generally want to deploy the most expensive version of Windows to every single desktop (they prefer the least expensive pro version that support AD integration).

You only need to perform a quick search to get an idea for just how bad Windows 10 behaves. Every time you click on the "start menu" Windows 10 calls home, even if you disable the "smart" features and active icons. My list of Internet sites to block in order to try and reduce the level of spying that Windows 10 does on my one Windows 10 system contains nearly 60 entries. Those entries do not include Microsoft's software update servers, bing search engine, outlook.com OneDrive, or live.com website.

Even if I am wrong and most converts aren't concerned with the invasive nature of Windows 10, it is still unlikely that Microsoft will get much conversion from long time Linux users. They are comfortable with the operating system they have. Most prefer the freedom and flexibility. Many will expound on the efficiency and reliability of their preferred operating systems.

In the end, I'm not sure this move will get Microsoft what it wants. The developers are going to prefer native Linux for developing Linux applications since they are less likely to run into subtle compatibility issues. Security minded folks aren't going to move back to Windows until Microsoft dumps all the spyware. Data center folks will enjoy the simplicity of  not needing a UNIX system in addition to a corporate desktop (but only if the corporate policy allows installation of the GNU user-land tools) while it lasts. Although those of us who have been around long enough to remember the old UNIX tools package, will doubt Microsoft's commitment for at least the next few releases of Windows.

Tuesday, March 1, 2016

Jumping on the Bandwagon with the SSLv2 "drown" vulnerability.

It has been a while since we've seen a truly newsworthy vulnerability in SSL but we got one today in CVE-2016-0800, more affectionately known at DROWN. The tech news media is sure to be writing very exciting and largely redundant articles about this particular beast. So, I figure why not add to the fray with my own little post.

Last time we saw something this newsworthy was the renown Heartbleed vulnerability way back in 2014. That one had IT shops scrambling to patch systems and executive up at night worrying that something was missed and the hackers would get into their businesses. Scary stuff for both groups.

But, enough background, what does this new vulnerability really mean?

If you have a server that allows the use of SSLv2, then an attacker can use it to figure out what is called a "session key". A session key is the encryption key used to secure the communications in transit between a client and a server. How bad this could be for your business depends on how sensitive the information flowing between your server and your clients.

In the worst case, you are communicating highly sensitive information that falls under strong government regulations or industry compliance standards like personally identifiable information, health care data, or financial transaction data.

In the best case, it represents an embarrassment to the company and the need for customers to change their passwords.

The Good News

This new vulnerability is a variation on one from March of 2015 (CVE-2015-0293) and is much harder to exploit. As a result of that previous incident, organizations that were concerned about that (older) vulnerability should have already disabled SSLv2 in order to protect themselves and their customers. Unless they have re-enabled SSLv2 this should not be a major concern today.

In order to take advantage of this vulnerability an attacker is going to have to make many thousands connection to a  vulnerable server. Any organization with a good intrusion detection system at their perimeter should be able to pick up on this to identify potential attackers fairly quickly.

The Bad News

One server that is vulnerable to the DROWN vulnerability can be used to obtain the session key for another server provided that both servers are using the same server certificates. More specifically the same RSA private keys within those certificates. They don't even have to be the same type of server as long as they use the same certificate. A public facing mail server could be used to obtain the session key for a secure web server in such a case.

Most bigger organizations choose to purchase wildcard certificates for their public servers. This lets the organization purchase one certificate and use it on multiple servers instead of having to purchase (and manage) separate certificates per server. While this simplifies server certificate management, it increases the risk of exposure in this case. A server that would be considered a lower priority could end up being used in an attack against a higher priority server.

Another potential problem arises network appliances. Particularly those whose vendors don't tend to provide patches promptly. These may go for years without a fix even available. The consumer market will be a particular problem in this case.

Conclusion

When this hits the major media news, we will probably see some more sleepless nights for executives and IT staff. It shouldn't be nearly as severe as Heartbleed was because anyone who has been paying attention to their information security should already have SSLv2 disabled all their servers.

The best course of action I can think of at the moment is to do a thorough review of all public facing servers and network equipment and confirm that SSLv2 is disabled. This needs to include even the low-priority systems because one server can be used by an attacker to compromise a different server. With SSLv2 disabled on every server, organizations can take their time and patch systems properly.

References: