OpenSSH 6.2 and 6.3 AES-GCM Cipher Memory Corruption

Hi, What's your UTM version #?

Barry

We have recently ran a Nessus scan against our UTM box that flagged a potentially high vulnerability that OpenSSH is out of date and could be affected by memory corruption.

We were wondering whether this is something that will/has been patched via a UTM update, or something we have to patch ourselves?

many external scans throw false positives against things like utm.  Many times it is because the version number is "older" than the latest.  Distributions backport fixes from newer version to older versions.  did you run this against the wan interface or the lan interface?  Also do you have the ssh port on the wan open to all addresses?

Hi thanks for the quick feedback, the UTM version is Sophos UTM 9.308-16, the scan was performed against the WAN interface. The SSH port is not open to all addresses but the Nessus box is on a predefined white list.

ok then the alert is not a real concern.  To be honest i am not sure even if it was world accessible it would be a real concern because of the reasons i noted earlier.  If you ahve a paid sub i would bring this up with support.

I just recently scanned our 9.310-11 and received the same warnings about the OpenSSH AES-GCM Cipher (CVE-2013-4548) and the OpenSSH child_set_env() exploit (CVE-2014-2532)

I see the last response is 'the alert is not a real concern', but I checked and the version of openssh on the Sophos UTM is "OpenSSH_6.2p2, OpenSSL 1.0.1k 8 Jan 2015". According to the release notes for OpenSSH 6.2p2, there is no mention of a fix for either of these issues. That doesn't happen until OpenSSH 6.4.

Can you point to me how you knew this wasn't a concern? I'd like to be able to share it with our auditors.

Following up with this post, I opened a ticket with sophos for CVE-2013-4548 & CVE-2014-2532 and got this response:

CVE-2013-4548 is only about bypassing ForceCommand and login-shell restrictions. This is not supported by UTM, any key configured for SSH access has full access without restrictions.

CVE-2014-2532 is only about not correctly using AcceptEnv restrictions. This is not used by UTM.

Now, the answer is more or less "yes the version we include has these flaws, but we don't happen to support features that would exploit them". Pretty surprising stuff considering the Sophos blog post from 2013 recommends users upgrade their OpenSSH versions "just in case".

Also, the comment of "any key configured for SSH access has full access without restrictions" isn't exactly true, it's only true for accounts setup within their web UI, but that's a different topic.

Note that that blog post was made by a Sophos guy that was likely only vaguely aware of the new tool in their box.  Ducklin's a good guy, but I'll take the developers' words before those of a company that, at the time, was working with decisions that screwed up the UTM for the last year.  At least now the new people at Sophos understand how to manage the development and support of devices like the UTM and it looks like we're almost out of the woods.

How is "any key configured for SSH access has full access without restrictions" incorrect?

Cheers - Bob

Bob,

Sorry, didn't see your note till now. We've learned the hard way that we can't trust Sophos's technical advice unless we independently verify it. The UTM is certainly an odd mix of being fantastic with best-of-breed OSS technologies, and being unusable due to terrible bugs/decisions at the same time.


To your question about the SSH key. You can pretty easily setup SSH users manually on the UTM - it's just a linux box. In fact, it's preferable if you need to add a bot-type user (e.g. a user your saltmaster) and you need to restrict their access for that user to just a handful of commands. 

The web UI happens to only create users with full access, but that's only one way to add SSH users, and that was my comment.