7 ms·

> PS: This has been reported to the ethereum foundation but they don’t consider it a valid vulnerability. This is ludicrous. If a torrent client considers this

by cyphar 9y ago

> PS: This has been reported to the ethereum foundation but they don’t consider it a valid vulnerability. This is ludicrous. If a torrent client considers this class of bug to be a vulnerability[1], I don't see why folks who are trying to revolutionise money (something that is far more important than a few small RCEs) don't. While it is true you need to run it with the --rpc option, I'm confused why the RPC is unauthenticated by default, and whether there is any front-end that will start up the RPC server in the background (similar to electrum). [1]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5702 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5702

shp0ngle 9y ago
Because it's Ethereum. And Ethereum is actually terrible.
benchaney 9y ago
I very much doubt that torrent client authors consider this to be a vulnerability in their client, but they fixed it anyway because they prefer to work around browsers being weird than to leave all their users vulnerable. I suspect this will eventually be the position of the Ethereum Foundation, but who knows.
- lolikoisuru 9y ago
  >I very much doubt that torrent client authors consider this to be a vulnerability in their client How could anyone not consider this a vulnerability when it has an actual CVE assigned to it? The discussion in the github issue also shows they took it pretty seriously: https://github.com/transmission/transmission/pull/468 https://github.com/transmission/transmission/pull/468
  - benchaney 9y ago
    It is certainly a vulnerability. It just isn't a vulnerability in the torrent client, but rather with browsers. Note that this PR is to mitigate the vulnerability, not to fix it.
    - mikeash 9y ago
      I don't understand how an unauthenticated RPC service is not a vulnerability just because it only listens on localhost. I'm not aware of any sensible security model which assumes that all code running on the local computer with network access is trustworthy. Even the old, standard UNIX security model only assumes that code running under your user is trustworthy.
      - skybrian 9y ago
        Well, it's all relative to the threat model. It makes some sense on a single-user machine where you don't run any untrusted code, as the same user or not. On a single-user machine, an attack scenario where authenticating localhost would actually do some good would be some other account existing that's easier to break into than the account of the user actually doing stuff. But if no other login exists?
        mikeash 9y ago
        I can see where you might set things up like that on a single-user machine after careful consideration of everything that's running on it. But making that the default seems like madness.
        cyphar 9y ago
        It should be noted that a desktop is not a single user machine, even though there may only be one human user operating the machine. A single user machine is a machine running in runlevel 1 -- in other words every process on the machine is running as one user and you cannot switch users. Modern desktops do not run at runlevel 1. All sorts of services and daemons run under different users, so having an unauthenticated service listening on localhost is less secure even on a desktop machine. If you have network services running on a desktop machine (common) then a simple RCE in an unprivileged user (with respect to the human user) can result in wallet compromise. If the API was authenticated that would not be possible. Unix DAC protects users from one another, so any service which exposes personal information outside of the currently running user has objectively inferior security to a security model invented in the 1960s.
tfha 9y ago
This type of mentality is very pervasive in ethereum culture. They built their scripting language with this mentality. They chose to have multiple clients with this mentality. They designed their 12 second blocks with this mentality. That's why a lot of the more technical people really dislike ethereum. It's not one or two problems. The entire system all the way through want made with the mentality of compromising stability in favor of getting features sooner.
- usrusr 9y ago
  It does keep etherium in the news though. Maybe the most important feature for crypto success is to be exciting.
  - monochromatic 9y ago
    If you're in it to pump up the value of your coin holdings and then dump them, this is absolutely true.
  - tfha 9y ago
    This happened for waltonchain. They got caught red handed faking a community giveaway, and that was a big enough story to bring them into the spotlight and push them into the top 30 cryptocurrencies by market cap for a bit.
    - asenna 9y ago
      I'm not sure I understand what you mean. Are you implying they got into the top 30 when that Twitter debacle happened? Didn't their prices plungem
  - heurist 9y ago
    The general public shouldn't be excited about blockchain. It should be hidden by abstraction to them, like multithreading and device drivers. Products intended for non-technical users that tout their blockchain technology are either really missing the mark on marketing or trying to pull the wool over consumers' eyes with buzzwords. Tech folk should be excited about blockchain but the hysteria over exchanges right now is off-putting once you understand how deeply rigged the markets are. My next venture will be blockchain-based but I have a few years before I'm free to pursue that. I'd rather see the fundamentals of the tech improved in the meantime rather than have it prematurely hyped and have the bubble pop as I seek to raise funding... I imagine there are many others who are in the position of wanting to build apps based on blockchain tech but who are not yet able. For us, slow and steady wins the race.
karalabe 9y ago
Was fixed 2 months ago https://github.com/ethereum/go-ethereum/pull/15962 https://github.com/ethereum/go-ethereum/pull/15962
baby 9y ago
I'm old to the thread but I figured I would bring some arguments against ranking this vulnerability as a high severity one for geth: * This is a "browser bypass of SOP" issue. All your "unauthenticated" local services should be vulnerable. * A good part of Geth's usage is for servers that do not browse the internet. * You usually do not handle accounts inside of a geth node, instead you open the node's API via RPC and have another tool that sends already-signed transactions to it. That means that this attack would probably not yield much if not allow someone to use the geth node as a public node to query public information. * If you do decide to handle accounts in there, you would probably (1) not open the node with RPC and (2) have the accounts be encrypted. See Ethereum's documentation[1] : > It supports interactive mode, when you are prompted for password as well as non-interactive mode where passwords are supplied via a given password file. Non-interactive mode is only meant for scripted use on test networks or known safe environments. [1]: https://github.com/ethereum/go-ethereum/wiki/Managing-your-accounts https://github.com/ethereum/go-ethereum/wiki/Managing-your-a...

by cyphar 9y ago

shp0ngle 9y ago

Because it's Ethereum. And Ethereum is actually terrible.

benchaney 9y ago

I very much doubt that torrent client authors consider this to be a vulnerability in their client, but they fixed it anyway because they prefer to work around browsers being weird than to leave all their users vulnerable. I suspect this will eventually be the position of the Ethereum Foundation, but who knows.

lolikoisuru 9y ago
>I very much doubt that torrent client authors consider this to be a vulnerability in their client How could anyone not consider this a vulnerability when it has an actual CVE assigned to it? The discussion in the github issue also shows they took it pretty seriously: https://github.com/transmission/transmission/pull/468 https://github.com/transmission/transmission/pull/468
- benchaney 9y ago
  It is certainly a vulnerability. It just isn't a vulnerability in the torrent client, but rather with browsers. Note that this PR is to mitigate the vulnerability, not to fix it.
  - mikeash 9y ago
    I don't understand how an unauthenticated RPC service is not a vulnerability just because it only listens on localhost. I'm not aware of any sensible security model which assumes that all code running on the local computer with network access is trustworthy. Even the old, standard UNIX security model only assumes that code running under your user is trustworthy.
    - skybrian 9y ago
      Well, it's all relative to the threat model. It makes some sense on a single-user machine where you don't run any untrusted code, as the same user or not. On a single-user machine, an attack scenario where authenticating localhost would actually do some good would be some other account existing that's easier to break into than the account of the user actually doing stuff. But if no other login exists?
      - mikeash 9y ago
        I can see where you might set things up like that on a single-user machine after careful consideration of everything that's running on it. But making that the default seems like madness.
      - cyphar 9y ago
        It should be noted that a desktop is not a single user machine, even though there may only be one human user operating the machine. A single user machine is a machine running in runlevel 1 -- in other words every process on the machine is running as one user and you cannot switch users. Modern desktops do not run at runlevel 1. All sorts of services and daemons run under different users, so having an unauthenticated service listening on localhost is less secure even on a desktop machine. If you have network services running on a desktop machine (common) then a simple RCE in an unprivileged user (with respect to the human user) can result in wallet compromise. If the API was authenticated that would not be possible. Unix DAC protects users from one another, so any service which exposes personal information outside of the currently running user has objectively inferior security to a security model invented in the 1960s.

tfha 9y ago

This type of mentality is very pervasive in ethereum culture. They built their scripting language with this mentality. They chose to have multiple clients with this mentality. They designed their 12 second blocks with this mentality. That's why a lot of the more technical people really dislike ethereum. It's not one or two problems. The entire system all the way through want made with the mentality of compromising stability in favor of getting features sooner.

usrusr 9y ago
It does keep etherium in the news though. Maybe the most important feature for crypto success is to be exciting.
- monochromatic 9y ago
  If you're in it to pump up the value of your coin holdings and then dump them, this is absolutely true.
- tfha 9y ago
  This happened for waltonchain. They got caught red handed faking a community giveaway, and that was a big enough story to bring them into the spotlight and push them into the top 30 cryptocurrencies by market cap for a bit.
  - asenna 9y ago
    I'm not sure I understand what you mean. Are you implying they got into the top 30 when that Twitter debacle happened? Didn't their prices plungem
- heurist 9y ago
  The general public shouldn't be excited about blockchain. It should be hidden by abstraction to them, like multithreading and device drivers. Products intended for non-technical users that tout their blockchain technology are either really missing the mark on marketing or trying to pull the wool over consumers' eyes with buzzwords. Tech folk should be excited about blockchain but the hysteria over exchanges right now is off-putting once you understand how deeply rigged the markets are. My next venture will be blockchain-based but I have a few years before I'm free to pursue that. I'd rather see the fundamentals of the tech improved in the meantime rather than have it prematurely hyped and have the bubble pop as I seek to raise funding... I imagine there are many others who are in the position of wanting to build apps based on blockchain tech but who are not yet able. For us, slow and steady wins the race.

karalabe 9y ago

Was fixed 2 months ago https://github.com/ethereum/go-ethereum/pull/15962 https://github.com/ethereum/go-ethereum/pull/15962

baby 9y ago

I'm old to the thread but I figured I would bring some arguments against ranking this vulnerability as a high severity one for geth: * This is a "browser bypass of SOP" issue. All your "unauthenticated" local services should be vulnerable. * A good part of Geth's usage is for servers that do not browse the internet. * You usually do not handle accounts inside of a geth node, instead you open the node's API via RPC and have another tool that sends already-signed transactions to it. That means that this attack would probably not yield much if not allow someone to use the geth node as a public node to query public information. * If you do decide to handle accounts in there, you would probably (1) not open the node with RPC and (2) have the accounts be encrypted. See Ethereum's documentation[1] : > It supports interactive mode, when you are prompted for password as well as non-interactive mode where passwords are supplied via a given password file. Non-interactive mode is only meant for scripted use on test networks or known safe environments. [1]: https://github.com/ethereum/go-ethereum/wiki/Managing-your-accounts https://github.com/ethereum/go-ethereum/wiki/Managing-your-a...