Dell Wyse Thin Client scores two perfect 10 security flaws Dell, which pitches its Wyse ThinOS as "the most secure thin client operating system," plans to publish an advisory on Monday for two severe security vulnerabilities. CVE-2020-29491 and CVE-2020-29492 are both critical flaws, managing a perfect (although unwelcome) CVSS score of 10 out of 10. The vulnerabilities, which affect …
According to Dell's website, "Wyse Thin Clients Accelerate your cloud strategy and enhance virtual workspaces with intelligent unified management and the ultimate security solutions."
Way to go Dell - a perfect 10 for 10 - definitely the ultimate security (security fauilure, that is)! Evidently security was part of the "fat" they removed to get to a "thin" client.
Indeed. Lots of predictable comments here about how stupid everyone else¹ is, etc., but the thing is, I really have difficulty believing that in 2020 anyone in a position to implement this product would not have been aware of the risks involved in something like using FTP (and anonymous, at that) so I tend to think "there but for the grace of God…"²
I doubt Dell will do this, but a public report of how they managed to ship with such a fundamental holebarn door wide open should make, I expect, for some very instructive reading.
¹ I don't understand how companies don't just go and hire every commentard in here, surely no more bugs ever, all the code would be at its most efficient, the design would be clean and clear, etc., etc.!
² Former commercial pilot. Even knowing how impossibly stupendous we all were (source: ourselves), things still went wrong from time to time and it was always good to learn how the holes in the cheese managed to line up.
I wondered why TF the clients needed write access to the server and it wasn't explained in either CyberMDX or Dell's reports.
In the referenced Thin client reference guide, however, reveals all (p. 7, my emphasis):
7 {username}.ini Files must be Write-EnabledAll {username}.ini files must be write-enabled to allow the thin client to place the encrypted user passwords in the files.
At that point, I stopped reading.
> Nothing wrong with good old FTP, when used properly.
Could you offer some examples of when it would be used properly these days?
I am just trying to understand how Dell managed to wreck this train and I reject the facile explanation that "they're just idiots". Perhaps each team thought they were taking limited risks but they failed to see how in the big picture all the risks lined up like a railway tunnel? I don't know, but honestly interested to know: in which application would you use FTP in (nearly) 2021 and why? Cheers.
"Could you offer some examples of when it would be used properly these days?"
I don't know about anybody else, but I use it to maintain my website. It is simple. It moves files. It is scriptable. It needs a userID and password for access. What alternative would you propose that doesn't do pretty much the same thing -- probably in a more complicated way -- with pretty much the same vulnerabilities?
It took me many decades, but I eventually learned by trial and error that overly simplistic "solutions" don't work because they are flawed and overly complex "solutions" don't work (for me) because I am flawed. FTP seems a reasonable compromise (for me).
Thank you for offering an example.
Are you aware that your username and password are being sent in the clear for everyone to see (as is the data), and that due to their diminished popularity FTP daemons are not receiving as much love as they used to, making them more vulnerable to 0days?
For my personal website (when I had one), I usually opened Dolphin, split the window into two panes with F3, then clicked on the shortcut to the SFTP URL pointing to my server's files (e.g., sftp://example.com/srv/www/htdocs/) and dragged the files across.
Alternatively, you could achieve the same thing on the command line via scp.
Aside from the low-hanging security advantages, it also saves you from having to install a dedicated server process, assuming that your remote box already runs sshd anyway.
FTPS over TCP/990 is inherently encrypted. Plus, it solves all the shit with NAT, passive port ranges and those shenanigans.
FTES over TCP/21 is better than no encryption, but reverse proxies/security appliances sometimes have problems with it. This uses explicit encryption, eg: the client must request a secure channel prior to credential passing. A FTP server that I am familiar with allows for per-login name enforcement of explicit encryption. Thereby preventing any client that isn't an idiot, eg: follows the relevant RFC, couldn't accidentally disclose a password over clear-text.
FTP has evolved just like HTTP has.
FTP has evolved just like inherently encrypted SMTP (TCP/465) has.
At the end of the day, there are several ways to skin a cat securely.
FTP / TFTP might still be suitable for some niche roles. But if then there isn't much excuse in the general case for not using something more secure like scp. At least then the user/password authentication is encrypted. Most embedded devices will go even further and will implement something like port knocking or a USB master key so the device won't even listen for ssh commands unless it is preceded by some signal. That's in addition to signed firmware, locked down / disabled root etc.
I don't know a thing about these Wyse clients, but if they use VNC for any part of their function I wouldn't be caught dead recommending it or using it. I use VNC at home to remotely control and use the PC's in my home network (8 of them,) and the performance is awful. Barely usable. So, No Thanks Wyse.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
