Oh, SSH, IT please see this: Malicious servers can fsck with your PC's files during scp slurps A decades-old oversight in the design of Secure Copy Protocol (SCP) tools can be exploited by malicious servers to unexpectedly alter victims' files on their client machines, it has emerged. F-Secure's Harry Sintonen discovered a set of five CVE-listed vulnerabilities, which can be abused by evil servers to overwrite arbitrary …
Quite a ghastly problem in software one relies to transfer files safely. In particular, I am disappointed no official OpenSSH fix has been released, even though they have known about this for months, they at least used to have a very good reputation in security.
Hmm. Not totally sure about this, but I think that rsync is layered on a transport layer that you specify, and this used to be rsh/rcp in the old trusting days of computing, and is normally replaced by ssh/scp.
I don't know if it uses ssh as a raw transport, and does all of it's file handling itself, or whether it hands things off to scp. I'm sure someone here knows.
So it may be that rsync is just as compromised!
scp and rsync are completely different protocols.
To use rsync, you need the rsync binary at both ends. It can either use raw TCP as transport (if you run rsyncd at the far end), or it can run over an ssh exec session as transport, but does not depend on scp. It's a streaming protocol in its own right.
Thanks for clearing that up. I know now.
I was thinking that rsync was a little older than it appears to be (the original release was dated 1996, now I look). That means that I was using it very soon after it was released.
The article says yes, but https://www.cvedetails.com/cve/CVE-2018-20684 says:
"In WinSCP before 5.14 beta, due to missing validation, the scp implementation would accept arbitrary files sent by the server, potentially overwriting unrelated files."
Version 5.13.5 apparently is "before 5.14" but perhaps is not counted?
I think, firewall: don't let your WinSCP play with strange servers.
Having said that, I'm looking at an old WinSCP version here, which says:
"SSH and SCP code based on PuTTY 0.63+"
If WinSCP is based on PuTTY, and PuTTY hasn't been fixed, then...…huh???
This post has been deleted by its author
I've used scp many times from "the outside world" into my local LAN, as well as conveniently moving files from one machine to another. sometimes it's faster to use scp than rsync, sometimes not. but yeah they both work.
I DL'd the 'manual patch' and did a test-apply to FreeBSD -CURRENT (which has 7.8) and it seems to apply without TOO much griping, but I didn't try to actually build it. However, I submitted a bug report with the article's URL (and the patch's) to get the devs' attention since it's apparenlty NOT patched in FBSD's version of openssh... (that and mentioned it a whole lot in a dev-related IRC channel, but everyone's apparently asleep right now so it'll be there when they wake up in the AM I guess)
Icon because, well, FreeBSD. And I would assume OS/X is affected as well, since it's based on the FBSD userland from a while back...
Well.... sure, this has been around for 34 years according to the article. I agree the white-hat age is upon us, which involves the exposition of some less likely flaws which some might argue are not all news-worthy. But personally I'd err on the side of disclosure and publication, and less on reminding everyone that we don't need to panic.
This is a problem even if you can verify the results, e.g. you are taking a copy of a large file that is either signed by a third party or there are published checksums for (think ISOs etc.). You'd think copying a file was a relatively safe operation, even if you don't trust the server, the worst that can happen is that the file you get is compromised and maybe you've got a bug in your checksum or signature verification that can be attacked when you attempt to verify (a risk that essentially every computer exposed to the internet runs all the time). The problem here is that an arbitrary file on your end that has nothing to do with whatever you are copying can be attacked. That is a very different kettle of fish.
If you're going to write like a smart-arse, expect someone to pick at any holes in your argument!
Apart from compromised servers, as others have mentioned, many sites mirror software on untrusted sites, making use of crypographic checksums to check authenticity.
> Apart from compromised servers, as others have mentioned, many sites mirror software on untrusted sites, making use of crypographic checksums to check authenticity.
And how does that relate to this article? It's nothing to do with the server serving a file with the wrong content.
The issue is when you ask your client to download a file from server A and store it in location X, the server could also send an instruction to modify location Y. With this scp bug, the client happily does what the server tells it.
So for example you could do:
scp remote:file1.txt file1.txt
and find that the server has overwritten /etc/passwd on your machine instead (or as well).
A comparable example from the web would be: if you click on a link to view a page, and the page can silently modify any file it likes on your local filesystem.
"> Apart from compromised servers, as others have mentioned, many sites mirror software on untrusted sites, making use of crypographic checksums to check authenticity.And how does that relate to this article? It's nothing to do with the server serving a file with the wrong content."
It doesn't relate to the article. It relates to this post I was replying to:
"Somebody used scp to securely copy something that he had no way of verifying from a server he didn't trust, and he was surprised by the results?"
To reitterate: it's accepted practice to download from a "server he didn't trust" when there are cryptographic hashes available from a trusted source.
... Not sure how your repeated explanation changes this.
It wouldn't surprise me if the SFTP and RSYNC _protocols_ are also inherently capable of doing similar. If you don't trust that the client or server software hasn't been compromised, it's likely some kind of Mandatory Access Control is needed, to limit access to the files and folders the user interface says should be accessed. Protocols for transferring or synchronising files are designed to be capable of transferring files, and for the security to be handled by authentication based on user accounts. But the latter approach is discretionary not mandatory and DAC tends to allow access based on user account login.
Tightening up on this in general would require that user interfaces communicate MAC policy before passing file transfer requirements to the back end software which actually _does_ the file transfer. But that only really moves the problem to whether the user interface software is trusted to restrict object access to the finer grained access as intended.
It looks like you've already argued against yourself "that only really moves the problem to whether the user interface software is trusted". Yes, if you can't trust application running to do sensible, non dangerous things then you're in trouble.
That is exactly what these CVEs are. "Hey, please grab some bytes from the network card and put them here: /X"
>> "Nah, I'll just write some other files, as determined by the network card byte stream and ignore your command, silly user t(-_-)t"
This is called a software bug, and reduces the trust in the 'user interface' software in question. The more general problem of "how do we write software which we can prove we can trust" is yet to be solved.
You should never simply connect willy-nilly to a server you don't trust anyway, you wouldn't get into a stranger's car would you! This is a very serious threat if you use your client to simply connect to anyone you fancy. However if you have trusted and verified third-parties you have a little breathing room to get your side of things sorted. No, I'm not suggesting you get blase about this, security is not a dirty word but if you have a secured trust relationship with a third-party then you have to have trust that they will be taking the same precautions as you.
As anyone in financial biz IT will know, file transfers are often the lifeblood of supplying pricing data. Not everyone has the latest SSL secured web APIs, a lot of banks and finance houses are still throwing files around on FTP servers let alone SFTP!
"You should never simply connect willy-nilly to a server you don't trust anyway"
I do regularly, so do most people here. You do too, probably.
Mirrors. Software distributions, patch files, src files, distributed on potentially untrusted mirrors - often a mirror is chosen automatically based on geographic position / load.
But the software is protected by cryptographic checksums kept either locally, or on the main, trusted server.
Surely "Secure Copy Protocol" is a bacronym. "scp" is just "secure cp", by analogy with "rcp" ("remote cp"), which in turn was named for UNIX "cp". And "cp" is just an abbreviation of "copy", not an acronym.1
I see Wikipedia uses the "Secure Copy Protocol" phrase in the relevant article, but the contributors hedge their bets by also using "secure copy", and they don't seem to cite any source for "Secure Copy Protocol". Some of their sources in fact use "scp protocol", which to my thinking has better etymological justification.
(Sure, there's a security issue here, but it's not nearly as important as arguing over terminology.)
1Or for pedants who adhere to the ill-founded "pronounced as a word" restriction for acronym, an "initialism".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
