back to article 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 …

  1. MacroRodent Silver badge

    The sound of a ball dropping.

    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.

  2. ds6 Bronze badge
    Childcatcher

    When your whole backup solution is centered around SCP transfers...

    Everyone always told me to use rsync; I should have listened, apparently.

    Next up: Rsync CVE posted, file transfers can virtually kick dog in real world.

    1. Peter Gathercole Silver badge

      Re: When your whole backup solution is centered around SCP transfers...

      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!

      1. Crypto Monad

        Re: When your whole backup solution is centered around SCP transfers...

        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.

        1. Peter Gathercole Silver badge

          Re: When your whole backup solution is centered around SCP transfers...

          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.

  3. upsidedowncreature

    WinSCP 5.14...

    ...isn't released yet according to the download page I'm seeing. All the 5.14 versions seem to be beta, it looks like the current released version is 5.13.7.

    1. Matt 18

      Re: WinSCP 5.14...

      Beta versions are more stable than RC builds, and are available on SourceForge. https://sourceforge.net/projects/winscp/files/WinSCP/

    2. Donn Bly

      Re: WinSCP 5.14...

      I thought that this was fixed in the WinSCP 5.13.5 hotfix last November, though it would be nice to get a confirmation on that from someone connected with the project.

      1. Robert Carnegie Silver badge

        Re: WinSCP 5.14...

        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???

  4. This post has been deleted by its author

    1. bombastic bob Silver badge
      Devil

      Re: Is SCP still a thing?

      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...

    2. Gene Cash Silver badge

      Re: Is SCP still a thing?

      ... except where you don't have sftp/rsync (e.g. work) because they're ignorant barbarians.

    3. disgustedoftunbridgewells Silver badge

      Re: Is SCP still a thing?

      scp server:/what/I/want /where/I/want/it

      It is the most convenient way to do simple file transfers by a distance.

  5. sitta_europea

    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?

    Hmmmm....

    1. #define INFINITY -1 Bronze badge

      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.

      1. thosrtanner

        And if for 'malicious' you substitute 'compromised'? As compromised servers seem to be rather more frequent these days. I doubt the run of the mill person is going to be using scp, but this particular hole is more worrying than some that have been published.

        1. Anonymous Bullard

          If they've compromised your server, then can now compromise your client.

          I use scp for one-off transfers.

    2. ibmalone Silver badge

      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.

    3. Jamie Jones Silver badge

      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.

      https://en.wikipedia.org/wiki/Cryptographic_hash_function

      1. Crypto Monad

        > 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.

        1. Jamie Jones Silver badge

          "> 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.

  6. Forget It
    Pint

    Congrats to the headline writer!

  7. PyLETS

    Class of problems inherent in file transfer, may require MAC enforcement.

    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.

    1. cbars

      Re: Class of problems inherent in file transfer, may require MAC enforcement.

      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.

  8. Roo
    Windows

    One way ?

    Am I correct in thinking that this vulnerability *only* affects clients that have initiated a download from the server, so clients uploading would not be affected ?

    1. Richard 12 Silver badge

      Re: One way ?

      Yes.

      Though a broken server install might allow a client to upload files to a place the owner of the server doesn't want, that's a different type of bug.

  9. Kevin McMurtrie Silver badge
    Devil

    brb...

    Going to create a gift for the hackers and botnets always trying to log into my server.

  10. Anonymous Coward
    Anonymous Coward

    You wouldn't get into a stranger's car

    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!

    1. Jamie Jones Silver badge

      Re: You wouldn't get into a stranger's car

      "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.

      https://en.wikipedia.org/wiki/Cryptographic_hash_function

  11. Fabrizio

    Best title ever for an article!

    At ElReg the editors and journalists are *really good* at creating good titles for their articles, but this one is, in my personal and totally subjective opinion, the best I've ever seen since I started reading TheRegister about 20 years ago or so

  12. Michael Wojcik Silver badge

    Secure Copy Protocol?

    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".

  13. Robert Carnegie Silver badge

    Please tell me if this is a stupid question.

    So do we need to update rcp as well?

    1. Jove Bronze badge

      Re: Please tell me if this is a stupid question.

      "So do we need to update rcp as well?"

      A different package to start with. These issues specifically relate to the ssh based packages.

      A more holistic answer is that, like ftp, you are advised not to be making use of rcp.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019