5 ms·

"SCP – Familiar, Simple, Insecure, and Slow" - slightly sensationalized title. All you need to know - if you scp with an evil machine, bad things can happen. Th

"SCP – Familiar, Simple, Insecure, and Slow" - slightly sensationalized title. All you need to know - if you scp with an evil machine, bad things can happen. That's all.

oehpr 6y ago
Is there a way in which you can connect to an evil machine and protect yourself from the possibility of it sending you evil bytes? What protocol is able to detect bytes as being evil without knowing at the outset what the file should look like? This doesn't even seem like a valid security concern. But I'm open to hearing about some ways that SCP would be vulnerable in ways that SFTP would not. I am by no means an expert in this subject.
- zeroimpl 6y ago
  One security concern is that the filenames for recursive transfers are determined by the untrusted machine. Thus if you fail to validate those, they could send things like ../.bashrc and a naive tool would write that to your home directory, leading to remote code execution. Presumably by now scp is sufficiently tested not to have this bug. But this is precisely a defense against an evil server sending bad bytes.
  - ollien 6y ago
    This was a CVE last year (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111). AFAICT this exploit has been patched.
- gpderetta 6y ago
  As long as the evil bits [1] are set correctly, you can filter by that. [1] https://tools.ietf.org/html/rfc3514 https://tools.ietf.org/html/rfc3514
  - matheusmoreira 6y ago
    That RFC is a work of art. Are there more like it?
    - joombaga 6y ago
      Oh yes. My favorite: A Standard for the Transmission of IP Datagrams on Avian Carriers https://tools.ietf.org/html/rfc1149 https://tools.ietf.org/html/rfc1149 Check the dates.
      - Groxx 6y ago
        And what good is a standard without an implementation: https://en.wikipedia.org/wiki/IP_over_Avian_Carriers https://en.wikipedia.org/wiki/IP_over_Avian_Carriers
    - keeganpoppen 6y ago
      > In networks protected by firewalls, it is axiomatic that all attackers are on the outside of the firewall. Therefore, hosts inside the firewall MUST NOT set the evil bit on any packets. LOL > Intrusion detection systems (IDSs) have a harder problem. Because of their known propensity for false negatives and false positives, IDSs MUST apply a probabilistic correction factor when evaluating the evil bit. If the evil bit is set, a suitable random number generator [RFC1750] must be consulted to determine if the attempt should be logged. Similarly, if the bit is off, another random number generator must be consulted to determine if it should be logged despite the setting. i am ashamed (or maybe not) to say that i have engaged in this form of debugging during past moments of desperation...
- gowld 6y ago
  Hmm? We safely connect to evil machines all day long. That's what web browser sandboxes and BitTorrent are for. We download files from evil machines and use checksums to verify the files.
pengaru 6y ago
> if you scp with an evil machine, bad things can happen. That's all. The problem is that remote hosts, even ones you think you control, should be assumed potentially evil (compromised).
- noobermin 6y ago
  There has to be a limit to this logic, because the obvious response should be not to log into machines you control, or by extension do anything for that matter.
  - pengaru 6y ago
    The limit certainly isn't here. There's zero reason for a file transfer utility to support running arbitrary commands on the local machine at the remote host's command. That capability shouldn't exist in the protocol, full stop. But since it does, if you're going to use scp regardless of what we know about it, there's clearly a broad spectrum of risk separating a random VPS in who knows what cloud running who knows what bits vs. the NAS machine in your closet that's only on a wired LAN behind a firewall running nothing that talks to the outside. Probably not the best choice to use scp to copy files to/from the former.

"SCP – Familiar, Simple, Insecure, and Slow" - slightly sensationalized title. All you need to know - if you scp with an evil machine, bad things can happen. That's all.

oehpr 6y ago

Is there a way in which you can connect to an evil machine and protect yourself from the possibility of it sending you evil bytes? What protocol is able to detect bytes as being evil without knowing at the outset what the file should look like? This doesn't even seem like a valid security concern. But I'm open to hearing about some ways that SCP would be vulnerable in ways that SFTP would not. I am by no means an expert in this subject.

zeroimpl 6y ago
One security concern is that the filenames for recursive transfers are determined by the untrusted machine. Thus if you fail to validate those, they could send things like ../.bashrc and a naive tool would write that to your home directory, leading to remote code execution. Presumably by now scp is sufficiently tested not to have this bug. But this is precisely a defense against an evil server sending bad bytes.
- ollien 6y ago
  This was a CVE last year (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111). AFAICT this exploit has been patched.
gpderetta 6y ago
As long as the evil bits [1] are set correctly, you can filter by that. [1] https://tools.ietf.org/html/rfc3514 https://tools.ietf.org/html/rfc3514
- matheusmoreira 6y ago
  That RFC is a work of art. Are there more like it?
  - joombaga 6y ago
    Oh yes. My favorite: A Standard for the Transmission of IP Datagrams on Avian Carriers https://tools.ietf.org/html/rfc1149 https://tools.ietf.org/html/rfc1149 Check the dates.
    - Groxx 6y ago
      And what good is a standard without an implementation: https://en.wikipedia.org/wiki/IP_over_Avian_Carriers https://en.wikipedia.org/wiki/IP_over_Avian_Carriers
  - keeganpoppen 6y ago
    > In networks protected by firewalls, it is axiomatic that all attackers are on the outside of the firewall. Therefore, hosts inside the firewall MUST NOT set the evil bit on any packets. LOL > Intrusion detection systems (IDSs) have a harder problem. Because of their known propensity for false negatives and false positives, IDSs MUST apply a probabilistic correction factor when evaluating the evil bit. If the evil bit is set, a suitable random number generator [RFC1750] must be consulted to determine if the attempt should be logged. Similarly, if the bit is off, another random number generator must be consulted to determine if it should be logged despite the setting. i am ashamed (or maybe not) to say that i have engaged in this form of debugging during past moments of desperation...
gowld 6y ago
Hmm? We safely connect to evil machines all day long. That's what web browser sandboxes and BitTorrent are for. We download files from evil machines and use checksums to verify the files.

pengaru 6y ago

> if you scp with an evil machine, bad things can happen. That's all. The problem is that remote hosts, even ones you think you control, should be assumed potentially evil (compromised).

noobermin 6y ago
There has to be a limit to this logic, because the obvious response should be not to log into machines you control, or by extension do anything for that matter.
- pengaru 6y ago
  The limit certainly isn't here. There's zero reason for a file transfer utility to support running arbitrary commands on the local machine at the remote host's command. That capability shouldn't exist in the protocol, full stop. But since it does, if you're going to use scp regardless of what we know about it, there's clearly a broad spectrum of risk separating a random VPS in who knows what cloud running who knows what bits vs. the NAS machine in your closet that's only on a wired LAN behind a firewall running nothing that talks to the outside. Probably not the best choice to use scp to copy files to/from the former.