Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Tuesday January 15 2019, @09:50PM   Printer-friendly
from the all-your-files-are-belong-to-us dept.

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 files on a computer connected via SCP. If you use a vulnerable version of OpenSSH's scp, PuTTY's PSCP, or WinSCP, to securely transfer files from a remote server, that server may be able to secretly tamper with files on your local box that you do not expect the server to change.

[...] Sintonen explained that because rcp, on which scp is based, allows a server to control which files are sent, and without the scp client thoroughly checking it's getting its expected objects, an attacker can do things like overwrite the user's .bash_aliases file. This, in turn, would allow the attacker to run arbitrary commands on the victim's box when the user does routine stuff, like list a directory.

"Many scp clients fail to verify if the objects returned by the scp server match those it asked for. This issue dates back to 1983 and rcp, on which scp is based," Sintonen explained in his disclosure this month.

"A separate flaw in the client allows the target directory attributes to be changed arbitrarily. Finally, two vulnerabilities in clients may allow server to spoof the client output."

The CVE (Common Vulnerabilities and Exposures) reports are:

  • CVE-2018-20685
  • CVE-2019-6111
  • CVE-2018-20684
  • CVE-2019-6109
  • CVE-2019-6110

Only WinSCP seems to have released an update that fixes these.


Original Submission

Related Stories

scp Will Be Replaced With sftp Soon 32 comments

OpenSSH 8.8 has been released and with it comes a heads up that there will be major changes to how the scp utility operates, starting in one of the next releases. Specifically, scp has been retooled to use the SFTP protocol under the hood. This will leave most behavior unchanged and most times there will be no perceived difference. However, some scripts which make use of globbing might need minor adjustment to work properly in the future:

A near-future release of OpenSSH will switch scp(1) from using the legacy scp/rcp protocol to using SFTP by default.

Legacy scp/rcp performs wildcard expansion of remote filenames (e.g. "scp host:* .") through the remote shell. This has the side effect of requiring double quoting of shell meta-characters in file names included on scp(1) command-lines, otherwise they could be interpreted as shell commands on the remote side.

This creates one area of potential incompatibility: scp(1) when using the SFTP protocol no longer requires this finicky and brittle quoting, and attempts to use it may cause transfers to fail. We consider the removal of the need for double-quoting shell characters in file names to be a benefit and do not intend to introduce bug- compatibility for legacy scp/rcp in scp(1) when using the SFTP protocol.

Another area of potential incompatibility relates to the use of remote paths relative to other user's home directories, for example - "scp host:~user/file /tmp". The SFTP protocol has no native way to expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later support a protocol extension "expand-path@openssh.com" to support this.

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 4, Insightful) by jasassin on Tuesday January 15 2019, @10:46PM (3 children)

    by jasassin (3566) <jasassin@gmail.com> on Tuesday January 15 2019, @10:46PM (#787090) Homepage Journal

    I'm glad I've only used scp on my own ssh servers! I hope putty and openssh (more important to me, whatever scp fedora uses). This is scary.

    --
    jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
    • (Score: 1, Interesting) by Anonymous Coward on Tuesday January 15 2019, @11:23PM (2 children)

      by Anonymous Coward on Tuesday January 15 2019, @11:23PM (#787102)

      What would be really scary would be if /sending/ could be tampered with as well. Copying public keys is probably the most common use of scp outside of personally controlled networks (ssh-copy-id doesn't use it though), so if the ssh server that is receiving your key can tamper with your files during that process, it could be a serious vector for exploitation.

      • (Score: 0) by Anonymous Coward on Wednesday January 16 2019, @01:53AM (1 child)

        by Anonymous Coward on Wednesday January 16 2019, @01:53AM (#787167)

        It doesn't sound really scary, or even a little scary.
        You're suggesting that someone, who already has root access to replace the sshd with a corrupted one, would then be able to...

        • read your public keys from .ssh/authorized_keys?
          They can do that already, not that it matters; they're called public keys for a reason.
        • write new public keys to your .ssh/authorized_keys, allowing them to log in as you?
          Yeah, they can do that already too.
          (Or they can just "su acoward".)
        • redirect your public keys to be written somewhere else, perhaps somewhere world-readable?
          See above re public keys.

        Seriously, what do you think this allows them to do that they can't already do?

        • (Score: 0) by Anonymous Coward on Wednesday January 16 2019, @03:15AM

          by Anonymous Coward on Wednesday January 16 2019, @03:15AM (#787196)

          If you're copying your public key to a server, and the server can modify files on YOUR machine, that's scary.

  • (Score: 4, Funny) by requerdanos on Wednesday January 16 2019, @12:28AM (2 children)

    by requerdanos (5997) Subscriber Badge on Wednesday January 16 2019, @12:28AM (#787130) Journal

    Oh, SSH, IT Please see This: Malicious Servers can Fsck With Your PC's Files During scp Slurps

    Here at Fully Retarded Nonsense Headlines, Ltd. we have been racking our brainlike regions, trying to come up with a way to add, remove, change a few words to make this headline worse.

    The conclusion of our experts: While refinements are possible, all of the substantial nonsense retardation has already been performed.

    It's always a sad day when the jokes write themselves.

    • (Score: 2) by el_oscuro on Wednesday January 16 2019, @01:01AM (1 child)

      by el_oscuro (1711) on Wednesday January 16 2019, @01:01AM (#787146)

      This is El-Reg. Fscking up headlines is their specialty.

      --
      SoylentNews is Bacon! [nueskes.com]
      • (Score: 0) by Anonymous Coward on Wednesday January 16 2019, @03:36AM

        by Anonymous Coward on Wednesday January 16 2019, @03:36AM (#787202)

        El-Reg headlines are often only comprehensible to UK local slang savvy persons.
        SCP - glad I don't use it. I can see the OSS devs... read this, glance over at their Patreon / PayPal bucket, which lies near empty, shrug and think "F* it" and reach for another Diet Coke from the mini fridge. Until some 30 minutes later, a _paid_ person at Canonical or RedHat reads this and jumps on the codebase. I expect to see the updates shield light up in the next 24 hours, max. Otherwise the Linux guys are fast asleep which is not their usual self.

  • (Score: 0) by Anonymous Coward on Wednesday January 16 2019, @12:40AM (2 children)

    by Anonymous Coward on Wednesday January 16 2019, @12:40AM (#787136)

    I think a friend (who was developing in the penumbra of ssh) showed me this vulnerability ~10 years ago. By him controlling the server, my client had unwanted files written to my disk when I used scp.

    I had always wanted to ask him when he was going to report it, but I guess he never did.

    • (Score: 0) by Anonymous Coward on Wednesday January 16 2019, @02:29PM (1 child)

      by Anonymous Coward on Wednesday January 16 2019, @02:29PM (#787374)

      I guess the moral of the story is if you know a vulnerability, you report it.

      • (Score: 0) by Anonymous Coward on Wednesday January 16 2019, @03:35PM

        by Anonymous Coward on Wednesday January 16 2019, @03:35PM (#787404)

        I didn't want to snatch it from him just for some stolen glory.

  • (Score: 3, Funny) by bzipitidoo on Wednesday January 16 2019, @02:51AM (3 children)

    by bzipitidoo (4388) on Wednesday January 16 2019, @02:51AM (#787184) Journal

    1. Go back to ftp, encrypting the files with gpg before transmitting them.
    2. Run scp in a sandbox such as a virtual machine.
    3. Harden the destination system with Access Control Lists like in SELinux so scp can't maliciously overwrite important files.

    Anyway, wow, a security hole that's been present for 36 years. Is that a record? Blows away Spectre and Meltdown. I mean, those have only been around for about 20 years.

    I wonder if at some point it'd be worth doing a total reboot. Build a new OS, tool chain, and utilities from scratch. Could write the whole thing in a more modern language than C.

    Meantime, what's next? A security hole in a Fortran mathematical library written in the 1960s that's a dependency for the Vulkan API that our current 3d accelerated graphics uses?

    • (Score: 2) by pkrasimirov on Wednesday January 16 2019, @09:35AM

      by pkrasimirov (3358) Subscriber Badge on Wednesday January 16 2019, @09:35AM (#787309)

      > a Fortran mathematical library written in the 1960s that's a dependency for the Vulkan API that our current 3d accelerated graphics uses?
      Baah, you got me there! :D

    • (Score: 0) by Anonymous Coward on Wednesday January 16 2019, @05:34PM (1 child)

      by Anonymous Coward on Wednesday January 16 2019, @05:34PM (#787465)

      in rust, obviously. i would like to try an OS made to be secure from the beginning.

      • (Score: 2) by Apparition on Wednesday January 16 2019, @11:16PM

        by Apparition (6835) on Wednesday January 16 2019, @11:16PM (#787646) Journal

        Have you looked at Redox OS [redox-os.org]? It's a UNIX-like microkernel OS largely written in Rust.

  • (Score: 3, Informative) by MichaelDavidCrawford on Wednesday January 16 2019, @03:51AM (2 children)

    by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Wednesday January 16 2019, @03:51AM (#787208) Homepage Journal

    $ chroot /tmp/ /usr/bin/scp -P 109 ~/Desktop/MixTapes.txt satori@warplife.com:.

    That doesn't work on macOS Sierra I expect because of its kernel-level protection for vital files. I don't recall what it's called.

    I expect it would work to mount a disk image that had some non-Apple filesystem then chroot to there.

    For this to actually work, you'll need to copy /usr/bin/scp AND ALL ITS DEPENDENCIES to /Volumes/SmashTheState/. Setting all that up is somewhat tedious but not actuall difficult.

    Now there _are_ ways to escape a chroot, but it's helpful of your chroot file tree does not have any shells are build tools. As well, the malware scp won't be expecting to be in chroot.

    Not at first anyway.

    I'll Send You My Bill In The Mail.

    --
    Yes I Have No Bananas. [gofundme.com]
    • (Score: 2) by MichaelDavidCrawford on Wednesday January 16 2019, @10:46AM

      by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Wednesday January 16 2019, @10:46AM (#787324) Homepage Journal

      If I don't use sudo, I get operation not permitted. I _think_ that's perror()'s complaint about insufficient privileges.

      _With_ chroot, I get "killed 9". If that's a linking problem, I figured I would have got some other signal, but really I don't know.

      There's lots of HOWTOs on putting httpd in a jail, have a read of that on do all the same stuff for scp.

      --
      Yes I Have No Bananas. [gofundme.com]
    • (Score: 2) by MichaelDavidCrawford on Wednesday January 16 2019, @02:22PM

      by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Wednesday January 16 2019, @02:22PM (#787372) Homepage Journal

      I _think_ it wasn't SIP giving me grief but that on macOS at least chroot must be run as root.

      To disable SIP, boot into Recovery Mode - search for how - then give the command # csrutil disable then reboot normally.

      I often disable SIP so I can test my unsigned drivers.

      --
      Yes I Have No Bananas. [gofundme.com]
(1)