[SECURITY ADVISORY] Bulletin ID: QSA-21-02

[Toxic17]

QNAP Security Advisory | Bulletin ID: QSA-21-02

Taipei, Taiwan, January 28, 2021 - QNAP® had published security enhancement against security vulnerabilities that could affect specific versions of QNAP products.
Please use the following information and solutions to correct the security issues and vulnerabilities.

Heap-Based Buffer Overflow in Sudo (Baron Samedit)
Release date: January 28, 2021
Security ID: QSA-21-02
Severity rating: Medium
CVE identifier: CVE-2021-3156
Affected products: All QNAP NAS

Summary

The Qualys research team has reported a heap-based buffer overflow vulnerability in sudo, an important utility for Unix-like and Linux-based operating systems, including QTS, QuTS hero, and QES from QNAP. 
If exploited, this vulnerability allows any unprivileged users to gain escalated root privileges on the vulnerable host.  
QNAP is thoroughly investigating the case. We will release security updates and provide further information as soon as possible.

Recommendation

To secure your device, we recommend disabling SSH and Telnet whenever you are not using these services.
Disabling SSH and Telnet Connections in QTS or QuTS hero

1. Log on to QTS or QuTS hero as administrator.
2. Go to Control Panel > Network & File Services > Telnet/SSH.
3. Deselect Allow Telnet connection.
4. Deselect Allow SSH connection.
5. Click Apply.

Disabling SSH Connections in QES

1. Log on to QES as administrator.
2. Go to Control Panel > Network & File Services > SSH.
3. Deselect Allow SSH connection.
4. Click Apply.

 
Revision History: V1.0 (January 28, 2021) - Published
 
If you have any questions regarding this issue, please contact us at https://www.qnap.com/go/support-ticket/.

[OneCD]

Hmm, QNAP were surprisingly fast with this one.

[Toxic17]

Hmm, QNAP were surprisingly fast with this one.

I wonder how long it takes them to patch it however.

[ldir-EDB0]

Hmmm, "QNAP is thoroughly investigating the case." - nothing to investigate, it's vulnerable, simple as!

I don't see 'switching off telnet(!) and ssh' as thorough as it should be. All it needs is a command injection vulnerability in another package, make the injected command 'sudo' and instant root.

At least until sudo is fixed my advice would be 'do NOT expose your NAS in ANY way to the Internet' and be suspicious of users on your lan.

And while you're there Qnap, better fix dnsmasq's dnspooq vuln as well.

[Ericnepean]

I don't see that disabling SSH is a significant or useful action. AFAIK, with SSH you can only log in as admin. If you have logged in as admin, you can already use Sudo to exercise root privileges. There seems little point in privilege escalation.
Same for Telnet (although I do not use it).

I see ldir-EDB0's comment as more to the point.

[Mousetick]

I don't see that disabling SSH is a significant or useful action. AFAIK, with SSH you can only log in as admin. If you have logged in as admin, you can already use Sudo to exercise root privileges. There seems little point in privilege escalation.

1) The admin user doesn't even need to use sudo to obtain root privileges. The admin user is root.
2) QTS provides an option to allow members of the administrators group to log in via SSH. These users are regular users not allowed to use sudo. They could obtain root privileges by exploiting the sudo vulnerability. So disabling SSH altogether would close that particular loophole.

QNAP could instead have advised to not allow any user other than admin to log in via SSH while keeping SSH enabled.

But disabling Telnet and SSH altogether is fine too. The way these services are configured by QNAP makes them giant loopholes. It should not be possible to log in as admin/root with password authentication via the network. It's just basic security.

[ldir-EDB0]

It looks like firmware 4.5.2.1566 patched the problem. sudo --version reports 1.9.5p2

This is good news.