Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

35-year-old vulnerability discovered in scp

sintonen.fi

Post reply on HN
Print view View original

21–30 of 158 posts

Re: 35-year-old vulnerability discovered in scp

#21

Post by reacweb »

leni536 wrote: post #7
askmike wrote: post #4

Earlier quoted context omitted.

> The attacker controlled server [...] drops .bash_aliases file to victim's home directory when the victim performs scp operation from the server. The transfer of extra files is hidden by sending ANSI control sequences via stderr. [...] Once the victim launches a new shell, the malicious commands in .bash_aliases get executed. Sounds to me like everything the user executing the scp command can access can be compromis…

> The attacker controlled server [...] drops .bash_aliases file to victim's home directory This can only happen if scp is invoked from the home directory (or from root or /home).

The server could also drop a "ls" file with execution rights in current directory. If "." is in your path before /usr/bin (I have already encounter that), it may be called as soon as you type ls (generally just after the scp).

Re: 35-year-old vulnerability discovered in scp

#22

Post by jedberg »

walrus01 wrote: post #19
reacweb wrote: post #17

Earlier quoted context omitted.

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.

Unix has usually been pretty good about giving you plenty of rope to hang yourself. :) Tools don’t usually protect from their own misuse — in this case not verifying a changed host key.

Re: 35-year-old vulnerability discovered in scp

#23

Post by eof »

jedberg wrote: post #10

I 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…

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

Re: 35-year-old vulnerability discovered in scp

#24

Post by jedberg »

rocqua wrote: post #20
jedberg wrote: post #10

I 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…

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.

Re: 35-year-old vulnerability discovered in scp

#25

Post by willvarfar »

jedberg wrote: post #18
leni536 wrote: post #15

Earlier quoted context omitted.

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

You should not trust the server. The server may have been compromised.

Re: 35-year-old vulnerability discovered in scp

#26

Post by jedberg »

eof wrote: post #23
jedberg wrote: post #10

I 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…

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

Re: 35-year-old vulnerability discovered in scp

#27

Post by ajdlinux »

jedberg wrote: post #18
leni536 wrote: post #15

Earlier quoted context omitted.

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

There are plenty of use cases where the host you're connecting to isn't completely untrusted but rather it's semi-trusted. Web hosting provider, university machine, etc - all multi-tenant environments which have a tendency to get compromised.

Re: 35-year-old vulnerability discovered in scp

#29

Post by simias »

jedberg wrote: post #24
rocqua wrote: post #20

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

If somebody manages to hack into a server somehow they can then contaminate hosts that attempt to scp from it. It's not the easiest exploit ever made but it's definitely pretty bad.
Post reply on HN