4 ms·

What you're missing is very simple: downloading files from a server need not imply that you trust the server even slightly. That's true whether you're downloadi

What you're missing is very simple: downloading files from a server need not imply that you trust the server even slightly. That's true whether you're downloading them via HTTPS (e.g. to view this web page) or via SCP. Many of us have jobs in which we typically only use SSH to connect to servers that we trust and control. But that assumption is no more baked into the security model of SSH than it is into the security model of HTTPS. The argument that "you trusted this server enough to connect to it and download a file, therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false in both cases.

nathan_long 8y ago
> The argument that "you trusted this server enough to connect to it and download a file, therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false in both cases. Great point. Also, imagine that you control the server and you know that it was compromised. Surely you want to be able to download logs and other files from it for inspection without having your own machine compromised.
- toyg 8y ago
  > Surely you want to be able to download logs Uhm, nope: you want to shut it down and perform forensics on the disk. Once it's rooted, I wouldn't touch it with a barge pole.
  - XCabbage 8y ago
    I've been a web developer for over 5 years and never once worked somewhere where I'd have any imaginable way of physically accessing the disk of a server. Everything's been cloud-based. I don't know the exact ratios, but I'd expect my experience not to be unusual.
    - detaro 8y ago
      You can't physically access the disk, but you often can download a snapshot or disk image, which is created at the hypervisor level.
    - organsnyder 8y ago
      You should still access that data in an offline manner, though—ideally: 1. Shut down the instance 2. Connect the storage as secondary storage on another (disconnected from the network) instance 3. Do forensics using your cloud provider's out-of-band management interface 4. Throw away that instance as soon as you're done
    - deleted 8y ago
      [deleted]
    - spenczar5 8y ago
      Every cloud provider out there would help you get an image of the disk if you told them it was due to a security breach.
peterwwillis 8y ago
A lot of what we do implies trust. We trust the browser not to have bugs, the TLS protocol to remain secure against attack, every CA to not grant MITM power to a state actor, the TCP/IP stack not to be remotely exploitable. Much of the world downloads unsigned code and exectues it locally, whether it be a Go client, an interpreted library code dependency, or "curl | bash". Windows has warnings before you run unsigned code, but most people run it anyway. We trust a lot of things, and maybe we shouldn't. The important thing, to me, is how informed I am about the trust I'm giving, and to whom, and what risks I'm willing to take. I use scp infrequently and on machines that I control, so that's a level of risk I'm comfortable with. But if the bug had been in curl, my blood pressure might be slightly higher.
VRay 8y ago
> therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false Unless you run your browser without an ad blocker
- XCabbage 8y ago
  Yeah, I thought that sort of quip might come along. ;) On the one hand, you have a real point. On the other, JavaScript running in my browser has significantly less power to do anything bad to me than arbitrary executable programs running directly in my OS do.
  - JohnFen 8y ago
    > JavaScript running in my browser has significantly less power to do anything bad to me than arbitrary executable programs running directly in my OS do. I think that depends on what you mean by "significantly less power". It's entirely possible to use Javascript to place malware (such as installing a binary executable) and do other assorted nastiness on a target machine. If the target machine is properly secured, it's still possible, it just requires more effort. This is the primary reason why I do not allow Javascript to run on my machines by default. If I'm at a site that I trust and I have no alternative to using, and the JS in question is essential, then I'll allow just the specific piece of JS to run. Otherwise, it's not happening.
    - miohtama 8y ago
      > It's entirely possible to use Javascript to place malware (such as installing a binary executable) and do other assorted nastiness on a target This sounds interesting. Can you kindly link an example for this technique?
    - Cpoll 8y ago
      But if you want to go that far, it's entirely possible with Javascript disabled. Not every browser bug is a JS engine bug. Your best bet (not guaranteed) is reading the html as plain text, not rendering any images, etc.
  - 8y ago
Bartweiss 8y ago
> The argument that "you trusted this server enough to connect to it and download a file, therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false in both cases. Nicely put. This feels like yet another variant of the same confusion we see around web browsing, with people saying "oh, if you don't want a virus don't go to sketchy sites". Agreeing to receive HTML or even run unfamiliar Javascript in a browser shouldn't be equated with trusting that website to run anything outside the sandbox, and in a world where ads on major sites are frequently resold through a half-dozen shoddy networks it's an important distinction.

nathan_long 8y ago

> The argument that "you trusted this server enough to connect to it and download a file, therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false in both cases. Great point. Also, imagine that you control the server and you know that it was compromised. Surely you want to be able to download logs and other files from it for inspection without having your own machine compromised.

toyg 8y ago
> Surely you want to be able to download logs Uhm, nope: you want to shut it down and perform forensics on the disk. Once it's rooted, I wouldn't touch it with a barge pole.
- XCabbage 8y ago
  I've been a web developer for over 5 years and never once worked somewhere where I'd have any imaginable way of physically accessing the disk of a server. Everything's been cloud-based. I don't know the exact ratios, but I'd expect my experience not to be unusual.
  - detaro 8y ago
    You can't physically access the disk, but you often can download a snapshot or disk image, which is created at the hypervisor level.
  - organsnyder 8y ago
    You should still access that data in an offline manner, though—ideally: 1. Shut down the instance 2. Connect the storage as secondary storage on another (disconnected from the network) instance 3. Do forensics using your cloud provider's out-of-band management interface 4. Throw away that instance as soon as you're done
  - deleted 8y ago
    [deleted]
  - spenczar5 8y ago
    Every cloud provider out there would help you get an image of the disk if you told them it was due to a security breach.

peterwwillis 8y ago

A lot of what we do implies trust. We trust the browser not to have bugs, the TLS protocol to remain secure against attack, every CA to not grant MITM power to a state actor, the TCP/IP stack not to be remotely exploitable. Much of the world downloads unsigned code and exectues it locally, whether it be a Go client, an interpreted library code dependency, or "curl | bash". Windows has warnings before you run unsigned code, but most people run it anyway. We trust a lot of things, and maybe we shouldn't. The important thing, to me, is how informed I am about the trust I'm giving, and to whom, and what risks I'm willing to take. I use scp infrequently and on machines that I control, so that's a level of risk I'm comfortable with. But if the bug had been in curl, my blood pressure might be slightly higher.

VRay 8y ago

> therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false Unless you run your browser without an ad blocker

XCabbage 8y ago
Yeah, I thought that sort of quip might come along. ;) On the one hand, you have a real point. On the other, JavaScript running in my browser has significantly less power to do anything bad to me than arbitrary executable programs running directly in my OS do.
- JohnFen 8y ago
  > JavaScript running in my browser has significantly less power to do anything bad to me than arbitrary executable programs running directly in my OS do. I think that depends on what you mean by "significantly less power". It's entirely possible to use Javascript to place malware (such as installing a binary executable) and do other assorted nastiness on a target machine. If the target machine is properly secured, it's still possible, it just requires more effort. This is the primary reason why I do not allow Javascript to run on my machines by default. If I'm at a site that I trust and I have no alternative to using, and the JS in question is essential, then I'll allow just the specific piece of JS to run. Otherwise, it's not happening.
  - miohtama 8y ago
    > It's entirely possible to use Javascript to place malware (such as installing a binary executable) and do other assorted nastiness on a target This sounds interesting. Can you kindly link an example for this technique?
  - Cpoll 8y ago
    But if you want to go that far, it's entirely possible with Javascript disabled. Not every browser bug is a JS engine bug. Your best bet (not guaranteed) is reading the html as plain text, not rendering any images, etc.
- 8y ago

Bartweiss 8y ago

> The argument that "you trusted this server enough to connect to it and download a file, therefore you clearly should trust it enough to permit it to execute arbitrary executables on your machine" is false in both cases. Nicely put. This feels like yet another variant of the same confusion we see around web browsing, with people saying "oh, if you don't want a virus don't go to sketchy sites". Agreeing to receive HTML or even run unfamiliar Javascript in a browser shouldn't be equated with trusting that website to run anything outside the sandbox, and in a world where ads on major sites are frequently resold through a half-dozen shoddy networks it's an important distinction.