It’s easy to fix. Just rewrite scp in Rust.
There are no memory corruption issues here, so I'm not sure how much this would help.
35-year-old vulnerability discovered in scp
31–40 of 158 posts
Re: 35-year-old vulnerability discovered in scp
#32I think I'm missing something. Step one is getting you to use a compromised server. Which either means the server your home directory is on is compromised (I’m assuming you have a login on the box, separate from your local home dir), in which case scp is the least of your worries, or they get you to bounce through a MITM server, in which case you have to accept an incorrect host key. If you're accepting incorrect hos…
reminds me of this raymond chen post https://blogs.msdn.microsoft.com/oldnewthing/20121207-00/?p=...
with the quote
"It's not really a vulnerability that you can do anything you want once you pwn the machine."
Re: 35-year-old vulnerability discovered in scp
#33Earlier quoted context omitted.
> Step one is getting you to use a compromised server. This is not at all uncommon. Consider I need to send you files, either once or on a batch schedule. You say, "give me your key, you can drop them on this server" I feel safe since I am just writing files to your server, not expecting you are going to drop arbitrary code that will run next time I open my terminal.
Unless I’m mistaken you’d still be safe. The vuln would only work if you were pulling files from an untrusted host, not pushing to it. But if I wanted to share files with you, I’d just put them on the web, unless we already have a relationship where you can ssh somewhere that I have access to. In which case I assume we’re trusted or you’ve at least verified the host key.
Well, it's basically a privilege escalation vulnerability. If you've owned some server, you now have a possibility to get access to the admins local machine too, likely giving you admin access to the whole infrastructure.
If you "trust" any of these things is irrelevant, as that trust might be misplaced and the security model should keep you safe with compromised servers regardless.
Re: 35-year-old vulnerability discovered in scp
#34It’s easy to fix. Just rewrite scp in Rust.
As long as you use vi to write your rust code I'm OK.
Re: 35-year-old vulnerability discovered in scp
#35Earlier quoted context omitted.
> the server your home directory is on is compromised The attack presumes your home directory is client side, and you use SCP to connect to any kind of server, whilst ~ is the client side open directory. Thus, any server you might SCP to could write to your local home dir. In university, I did this with compute clusters, servers of my association and other servers. This breaks the SCP security model because it means…
Right I get all that (I updated to clarify that I understand the attack is against your local home dir, but I assume you have one on the remote side). I just don’t understand the use case of scp’ing from an untrusted host.
I copied over results files from a university cluster to my local home dir. It wouldn't surprise me if it were possible for another user of the cluster to affect the server-side SCP program.
I trust the cluster enough to give me those results. I don't trust it with write access to .bash_aliases . Thats why I did
scp file@host .
scp *@host .Re: 35-year-old vulnerability discovered in scp
#36Earlier quoted context omitted.
> the server your home directory is on is compromised The attack presumes your home directory is client side, and you use SCP to connect to any kind of server, whilst ~ is the client side open directory. Thus, any server you might SCP to could write to your local home dir. In university, I did this with compute clusters, servers of my association and other servers. This breaks the SCP security model because it means…
Right I get all that (I updated to clarify that I understand the attack is against your local home dir, but I assume you have one on the remote side). I just don’t understand the use case of scp’ing from an untrusted host.
That's because you don't work with systems.
Re: 35-year-old vulnerability discovered in scp
#37Earlier quoted context omitted.
> the server your home directory is on is compromised The attack presumes your home directory is client side, and you use SCP to connect to any kind of server, whilst ~ is the client side open directory. Thus, any server you might SCP to could write to your local home dir. In university, I did this with compute clusters, servers of my association and other servers. This breaks the SCP security model because it means…
Right I get all that (I updated to clarify that I understand the attack is against your local home dir, but I assume you have one on the remote side). I just don’t understand the use case of scp’ing from an untrusted host.
Throughout the years my employers have reinstalled servers and consequently changed host keys. I believe many users just accept the new key without realizing what they might get themselves into.
Ideally your organization should keep updated (public) host keys somewhere, say on some https-protected website so you can double check yourself. How common is this?
(I mainly use ssh for interactive/tunneling use, but with a bit of bad luck the host key would change just in time for scp. BTW, don't rsync/unison use scp sometimes?)
Re: 35-year-old vulnerability discovered in scp
#38I think I'm missing something. Step one is getting you to use a compromised server. Which either means the server your home directory is on is compromised (I’m assuming you have a login on the box, separate from your local home dir), in which case scp is the least of your worries, or they get you to bounce through a MITM server, in which case you have to accept an incorrect host key. If you're accepting incorrect hos…
you could do a simple arp mitm or so to have a client connect to you instead of the target server. if they didn't connect before from that client they will be prone to accepting the certificate. subsequently the malicious server can own the client. after that is happen, in the example given, the next login on the victim box runs further commands via bash.
why you would want to fix this; client needs to verify the input it receives from server and not trust it's the right thing. malicious servers is just like how browsers get owned u know. it's not magic and very risky considering how many people have ssh / scp servers in their internal networks, which is just the kind of environment you can get away with a mitm attack on..
Re: 35-year-old vulnerability discovered in scp
#39I think I'm missing something. Step one is getting you to use a compromised server. Which either means the server your home directory is on is compromised (I’m assuming you have a login on the box, separate from your local home dir), in which case scp is the least of your worries, or they get you to bounce through a MITM server, in which case you have to accept an incorrect host key. If you're accepting incorrect hos…
The worst security threat is a human in-front of a terminal... eg. the user can be tricked to do something that is normally unsuspicious, like copy some files off some server.
Re: 35-year-old vulnerability discovered in scp
#40Could anyone comment about whether any file-related Ansible modules use scp by default instead of sftp?
I believe you need to set scp_if_ssh = True in ansible.cfg for scp to ever be used, even if sftp is not available on the remote host.
Nowadays ansible uses a sort-of 'smart' method by default, where it first tries to use sftp, and if that fails, falls back to scp. See https://docs.ansible.com/ansible/latest/plugins/connection/s...