Hacker News Reader

Comment by XCabbage | Hacker News Reader

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.

View on HN

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

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

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.

You can't physically access the disk, but you often can download a snapshot or disk image, which is created at the hypervisor level.

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

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.

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.

> 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

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.

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

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

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.

These days, so much happens in browsers (banking, medical records, social communications) that it's hard for me to imagine a more dangerous place to give up execution. What sort of things are you thinking of that scare you more on the OS?

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.

Reply on news.ycombinator.com