I quick test with strace and git shows that git doesn't use scp for handling ssh remotes. I suspect that git is hardened against similar attacks (a malicious server dropping files into .git/hooks would be worrisome).
35-year-old vulnerability discovered in scp
11–20 of 158 posts
Re: 35-year-old vulnerability discovered in scp
#12I 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…
I think what it's saying is that in the event you connect to a malicious server, that server is able to do more damage to the client than it ought to.
Should be fixed, but clearly not the worse vulnerability ever.
Re: 35-year-old vulnerability discovered in scp
#13I read: * [...] only directory traversal attacks are prevented * [...] can overwrite arbitrary files in the scp client target directory * [...] the server can manipulate subdirectories as well ... so nothing points to the ability of the server to "fiddle with" parent directories. Thus.. Is it an OK temporary workaround to _only_ perform scp from within a freshly created directory in /tmp/?
I read it as being MitM and manipulating target (final, originally intended server) directories and files only, and in addition to spoof output to client to hide the fact it's doing so. In that case it does not matter where you run the client. What makes MitMs possible is that checking fingerprint of new host is left to user. Instead we should have processes to automatically 1. acquire via other means and add fingerp…
If you let a something MITM you it will always be able to steal your files, no path validation will fix that. If you let something MITM you when copying files from client to server it should have no way of changing the destination directory (assuming you authenticate using asymmetric crypto), regardless of path validation. This vulnerability has nothing to do with that.
This vulnerability is only about copying files from the server to the client, and lacking path validation when that happens. This problem can be fixed without fixing MITM.
Re: 35-year-old vulnerability discovered in scp
#14I 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…
Which either means the server your home directory is on is compromised, in which case scp is the least of your worries
Well but what if the server doesn't tell you it's compromised?
Re: 35-year-old vulnerability discovered in scp
#15I 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…
> Which either means the server your home directory is on
How did you arrive to the conclusion that the server has your home directory? The threat model: It's a server that you can authenticate to, retrieve files from there but otherwise you don't trust. It has nothing to do with your home directory. The PoC attack just shows the danger of invoking scp from the client's home directory.
Re: 35-year-old vulnerability discovered in scp
#16I read: * [...] only directory traversal attacks are prevented * [...] can overwrite arbitrary files in the scp client target directory * [...] the server can manipulate subdirectories as well ... so nothing points to the ability of the server to "fiddle with" parent directories. Thus.. Is it an OK temporary workaround to _only_ perform scp from within a freshly created directory in /tmp/?
I read it as being MitM and manipulating target (final, originally intended server) directories and files only, and in addition to spoof output to client to hide the fact it's doing so. In that case it does not matter where you run the client. What makes MitMs possible is that checking fingerprint of new host is left to user. Instead we should have processes to automatically 1. acquire via other means and add fingerp…
There is already a solution to this problem, which is host key certificates.
All you need to do is configure your SSH client to accept only host keys signed by your CA.
However, setting that up is complicated. You need a lot of knowledge to set that up securely. On the other hand, manual verification of host keys is trivial -- anybody can compare a short string of characters.
Re: 35-year-old vulnerability discovered in scp
#17I 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…
I accept incorrect host keys a couple of time per year because the IT has changed an IP adress or when a server is replaced. I do not always bother to check that I have a mail notifying me that the change was planned. Knowing this new vulnerability, I will take care to not perform a scp toward my home directory and I will double check PATH when logging to a new account (check that PATH does not contain "." before /usr/bin and /bin). IMHO, this is a major vulnerability for unix users.
Re: 35-year-old vulnerability discovered in scp
#18I 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…
> Which either means the server your home directory is on How did you arrive to the conclusion that the server has your home directory? The threat model: It's a server that you can authenticate to, retrieve files from there but otherwise you don't trust. It has nothing to do with your home directory. The PoC attack just shows the danger of invoking scp from the client's home directory.
I see so in the case that I scp from an untrusted host, I could have added risk that it is silently overwriting filed in my local home dir.
That makes sense I suppose. I never scp files from untrusted hosts, nor can I think of a use case to do so, so it hadn’t really crossed my mind.
Re: 35-year-old vulnerability discovered in scp
#19I 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…
I accept incorrect host keys a couple of time per year because the IT has changed an IP adress or when a server is replaced. I do not always bother to check that I have a mail notifying me that the change was planned. Knowing this new vulnerability, I will take care to not perform a scp toward my home directory and I will double check PATH when logging to a new account (check that PATH does not contain "." before /us…
The risk mitigation part here is that you know in advance a server has moved before you try to SSH to it. The real risk is less than cautious people who might choose 'yes' to accept a new host key when sshing towards a sshd that they have no prior knowledge of having changed IPs, or having been re-imaged, etc.
Re: 35-year-old vulnerability discovered in scp
#20I 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 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 a server has covert access to your local working path. Whereas normally you know which files SCP touched, so you can verify they are as intended.