4 ms·

While I understand your point and agree mostly with what you're saying, it's worth noting that a functionally equivalent thing happens with /usr/bin/ssh on most

While I understand your point and agree mostly with what you're saying, it's worth noting that a functionally equivalent thing happens with /usr/bin/ssh on most linux systems. A remote web site is consulted (usually via plain http, not even https!) and new code is downloaded. Signatures are checked locally (using gpg, which is itself bootstrapped from trusted installation media, and can be updated at any time like any other package), and then new software is installed. The update cycle is longer, but it's still there. Under the threat model of "your source of software is compromised", no system is safe.

tptacek 13y ago
So try to articulate why you wouldn't be comfortable just doing a "curl foo.com | bash" every time you SSH'd to a site. Obviously, very few people would be comfortable doing this.
- AnIrishDuck 13y ago
  Because I wouldn't trust foo.com as a source of software, in your hypothetical example. If we're being hypothetical, I would have no problem running something like: $ wget https://openssh.org/releases/openssh-blah.tar.gz https://openssh.org/releases/openssh-blah.tar.gz ; tar -xf openssh-blah.tar.gz ; make && ./bin/ssh host If such a thing were possible (and not hideously slow). I agree with what I believe is your thesis: good crypto is hard to do right and that you should be very careful with which sources of crypto software you trust. I just wanted to point out that trusting trust is a big problem in our industry, and isn't magically solved by using binaries on your local machine.
CodeMage 13y ago
The software source for stuff like /usr/bin/ssh is a thing that has some serious infrastructure, well-established procedures and well-organized people. Right from the start the trustworthiness of that source is higher than average, arbitrary site. I say "arbitrary", because I assume you would want to serve this JavaScript solution from your own site, the way people do with jQuery. On the other hand, if you do decide to serve it from one central place, then you could establish similar level of trustworthiness for that source, but your solution would still be at a disadvantage. Running JavaScript is like downloading new software to your home directory on a regular basis and executing it; you don't need to compromise the software source for /usr/bin/ssh, you just need to compromise a less trustworthy bit of software and then make that bit modify the in-memory behavior of /usr/bin/ssh (because JavaScript doesn't have the kind of security the OS gives processes).
- AnIrishDuck 13y ago
  > The software source for stuff like /usr/bin/ssh is a thing that has some serious infrastructure, well-established procedures and well-organized people. Right from the start the trustworthiness of that source is higher than average, arbitrary site. I agree. That doesn't change my point: JavaScript or binary packages, if you're running crypto you need to be able to trust the source of your software. > Running JavaScript is like downloading new software to your home directory on a regular basis and executing it; you don't need to compromise the software source for /usr/bin/ssh, you just need to compromise a less trustworthy bit of software and then make that bit modify the in-memory behavior of /usr/bin/ssh (because JavaScript doesn't have the kind of security the OS gives processes). This analogy is strained. It only really applies if your site is vulnerable to XSS attacks. After that, JavaScript is generally far more restricted than your average userland code. JavaScript from one site can't modify javascript from another (well-constructed) site. Whereas you correctly point out that once you can execute arbitrary code with user level privileges, the game is usually up. In particular, x session keylogging means you can grab a sudo password from a user once you can spy on their session, which any userland program can do. JavaScript from attack.com can't monitor keypresses on trustedbank.com unless it's explicitly included (which can happen by accident via XSS). Look up the same origin policy to see the kind of constraints that are usually placed on JS code.

tptacek 13y ago

So try to articulate why you wouldn't be comfortable just doing a "curl foo.com | bash" every time you SSH'd to a site. Obviously, very few people would be comfortable doing this.

AnIrishDuck 13y ago
Because I wouldn't trust foo.com as a source of software, in your hypothetical example. If we're being hypothetical, I would have no problem running something like: $ wget https://openssh.org/releases/openssh-blah.tar.gz https://openssh.org/releases/openssh-blah.tar.gz ; tar -xf openssh-blah.tar.gz ; make && ./bin/ssh host If such a thing were possible (and not hideously slow). I agree with what I believe is your thesis: good crypto is hard to do right and that you should be very careful with which sources of crypto software you trust. I just wanted to point out that trusting trust is a big problem in our industry, and isn't magically solved by using binaries on your local machine.

CodeMage 13y ago

The software source for stuff like /usr/bin/ssh is a thing that has some serious infrastructure, well-established procedures and well-organized people. Right from the start the trustworthiness of that source is higher than average, arbitrary site. I say "arbitrary", because I assume you would want to serve this JavaScript solution from your own site, the way people do with jQuery. On the other hand, if you do decide to serve it from one central place, then you could establish similar level of trustworthiness for that source, but your solution would still be at a disadvantage. Running JavaScript is like downloading new software to your home directory on a regular basis and executing it; you don't need to compromise the software source for /usr/bin/ssh, you just need to compromise a less trustworthy bit of software and then make that bit modify the in-memory behavior of /usr/bin/ssh (because JavaScript doesn't have the kind of security the OS gives processes).

AnIrishDuck 13y ago
> The software source for stuff like /usr/bin/ssh is a thing that has some serious infrastructure, well-established procedures and well-organized people. Right from the start the trustworthiness of that source is higher than average, arbitrary site. I agree. That doesn't change my point: JavaScript or binary packages, if you're running crypto you need to be able to trust the source of your software. > Running JavaScript is like downloading new software to your home directory on a regular basis and executing it; you don't need to compromise the software source for /usr/bin/ssh, you just need to compromise a less trustworthy bit of software and then make that bit modify the in-memory behavior of /usr/bin/ssh (because JavaScript doesn't have the kind of security the OS gives processes). This analogy is strained. It only really applies if your site is vulnerable to XSS attacks. After that, JavaScript is generally far more restricted than your average userland code. JavaScript from one site can't modify javascript from another (well-constructed) site. Whereas you correctly point out that once you can execute arbitrary code with user level privileges, the game is usually up. In particular, x session keylogging means you can grab a sudo password from a user once you can spy on their session, which any userland program can do. JavaScript from attack.com can't monitor keypresses on trustedbank.com unless it's explicitly included (which can happen by accident via XSS). Look up the same origin policy to see the kind of constraints that are usually placed on JS code.