Feeds

How long is too long to wait for a security fix?

Synology finally patches OpenSSL bugs in Trevor's NAS

Top 5 reasons to deploy VMware with Tegile

Sysadmin blog Synology quietly released version 4.2-3250 of its DiskStation Manager (DSM) operating system this month. This squashes critical security bugs in version 4.2 of DSM – bugs that were fixed in version 5.0 in June, so consider this a back port.

Version 4.2 is old but still in use in various models, such as the DS109. The update got me thinking about the security of NASes and similar devices on our networks.

New build 3250 addresses a kernel-level security issue as well as the six OpenSSL bugs found and fixed in early June.

The kernel issue (CVE-2014-0196) allows an attacker to trigger a denial-of-service and escalate his or her privileges once they've gained remote access to a system. The Include Security blog has a truly excellent walkthrough on exploiting this security hole.

The six OpenSSL bugs include a man-in-the-middle vulnerability (CVE-2014-0224) that I find mildly concerning, and a remote-code execution bug (CVE-2014-0195) that is downright alarming.

For most sysadmins, CVE-2014-0195 won't be a huge concern. Your average web server isn't likely to be vulnerable. Web browsers aren't going to be vulnerable. Most devices that are vulnerable are going to live behind a corporate firewall …but not all of them.

CVE-2014-0195 is basically a flaw in the implementation of Datagram Transport Layer Security (DTLS), which uses UDP to send fragmented messages. The long story short is that you can send it a bad packet and crash a service using a vulnerable OpenSSL library. Metasploit already has a module that can accomplish this. In theory, this exploit can also be used to cause remote-code execution, though I have yet to see code in the wild.

Among the possibly affected protocols are SNMPv3 (update your firewalls and routers, everyone), DTLS-SRP (VoIP, WebRTC, etc) and LDAP over SSL and OpenVPN. These latter two are where this becomes relevant to Synology's NASes. Synology NASes are more than just a file server and a web browser. They have their own app store, and you can install all sorts of goodies, including OpenVPN and an LDAP server which can operate over SSL.

An unfortunate number of individuals directly connect their Synology NASes to the internet and then forget to patch them. This has resulted in issues like the creation of the world's least effective altcoin botnet.

It's all about time

Patching your NAS is important, just as it is for your home router, switches, firewalls, servers and endpoints. Sadly, as has been made quite obvious, a great many people simply refuse to do so. For those willing to put the effort in, Synology's DSM 5 has an auto-update feature that largely allows the NAS to take care of itself.

Perhaps more importantly, newer versions of the DSM received the patches earlier. Units using DSM 5.0 started seeing the patch pushed out on June 11, while those using DSM 4.3 saw these patches on June 25. Having a NAS lingering on DSM 4.2 – I don't like to move even minor versions on storage unless I absolutely have to – I have had to wait until July 16 to see the patch.

Any company is going to have resource issues supporting all versions of the software they have shipped. I can't fault Synology for taking time to push out these patches to the very outdated OS I am running; in fact, I'd like to pass on kudos to them for doing so at all.

I'm glad that Synology is growing into a vendor that puts resources into back-porting patches instead of saying "upgrade to our latest greatest or be damned." Not so long ago that would have been functionally unheard of outside of the largest enterprise vendors. Still, this patch cycle does raise questions about the balance between security and stability.

For my home NAS, nestled behind my firewalls and NAT, exposing no services to the outside world, I can afford to wait a month or two to get critical patches like this. There still isn't a known exploit in the wild for the really icky vulnerability, and so I'm OK with how it worked out.

If, however, I was exposing one of those NASes directly to the internet I'd be a lot less happy about having to wait this long. My fear of potential stability unknowns related to moving to the newer operating system version would probably be lower than the fear of some script kiddie crawling through OpenSSL and turning my NAS into a space heater trying to mine Bitcoin.

Where do you draw the line between upgrades and maintaining a known good configuration? How long is too long to wait for security patches, and how will we deal with these same issues when we're not talking about a single NAS or a router, but potentially hundreds or thousands of "Internet of Things" embedded computers and sensors? Answers in the comments, please. ®

Secure remote control for conventional and virtual desktops

Whitepapers

Go beyond APM with real-time IT operations analytics
How IT operations teams can harness the wealth of wire data already flowing through their environment for real-time operational intelligence.
The total economic impact of Druva inSync
Examining the ROI enterprises may realize by implementing inSync, as they look to improve backup and recovery of endpoint data in a cost-effective manner.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Mitigating web security risk with SSL certificates
Web-based systems are essential tools for running business processes and delivering services to customers.