[YjSe2GMQ]

> but will not prevent you from sending your cryptoassets to the "wrong" endpoint.

Can you explain how's that a problem? The only thing you can do with a signed transaction is to either broadcast it or not.

MyEtherWallet suffers from the equivalent of supply chain attack here, where the JavaScript gets replaced with malicious code.

[otoburb]

I'm treating network & host attacks as a supply chain attack where the authentic/intended destination address is replaced by the attacker with the attacker's address. Hence my air quotes around the word "wrong".

As with MEW, as far as Ledger is concerned, a correct transaction is being signed and will in turn be broadcast. But the final outputs don't actually end up where the sender intended them to be sent because their host or network was compromised.

[YjSe2GMQ]

Yeah this is plain wrong. Sorry but you simply don't understand how transactions work in cryptocurrencies.

You cannot edit a transaction (for example by changing it's outputs) after it has been signed. That's how cryptographic signatures work, in general.

And the only way to cause an incorrect transaction to be signed on Ledger/Trezor is by tricking the user, which requires malicious code inside the device.

[otoburb]

We're in "violent agreement". You seem to be missing my point.

I completely agree with you that you cannot edit a transaction after it's been signed. I was trying to point out above that if the user is tricked, by signing a transaction they think is correct, but is in actuality not the intended destination because we assume the attacker controls what they are seeing, and where they are going.

Ledger signs transactions with a destination address. If the user can't tell (or is tricked) into believing a malicious address is the authentic one, everything will look koshor. This is similar to the level of sophistication and control required in the MEW incident. It's unlikely, but possible.

[sowbug]

You're not listening. This is the case that otoburb is describing:

1. Install bad browser extension.

2. Visit coinbase.com.

3. Copy deposit address.

4. Paste into Ledger software.

5. Initiate transfer of funds to Coinbase.

6. Scrutinize transaction details.

7. Approve.

Your funds are now gone, and you'll never see them again.

All cryptography worked as designed in this case. "That's how cryptographic signatures work, in general."

Substitute scenarios with receive addresses triple-notarized with medallion guarantees imprinted in blood if you wish for steps 1-3. It doesn't matter. The deputy is confused.

[YjSe2GMQ]

I'll reply here to the three comments: I admit that you're right guys. I have to concede my point about backdoors. If you modify user's view of Coinbase DOM then no security in the Ledger/Trezor is going to help with that.

But also it's independent of the discussion around whether NFC or Bluetooth is a better choice for host <-> device comms.

PS. I love the term "violent agreement".

[paulsutter]

Unless the destination address is changed before it gets to the ledger. Surely you’ve seen the copy/paste malware that changes addresses?

https://techcrunch.com/2018/07/03/new-malware-highjacks-your...

[YjSe2GMQ]

Technically, only copy-paste mutations are not enough as you confirm addresses on the screen. But, for example, DOM edits from a malicious extension are enough.