8 ms·

Security Alert: Ethereum Constantinople Postponement

62 points by Jhsto 8y ago

ascendantlogic 8y ago
Glad they caught the bug before the fork instead of after.
- FracMat 8y ago
  No going back after a fork. Due to this the Ropsten test network will likely be reset completely!
Nanocurrency 8y ago
I wish they could have continued without it. Issuance reduction was really important, we've had too much selling pressure for too long. It might have eased it.
- DennisP 8y ago
  They're planning to, it'll just take a few days to update the code and give node operators time to download the new clients.
xiphias2 8y ago
,,key stakeholders around the Ethereum community have determined that the best course of action will be to delay the planned Constantinople fork that would have occurred at block 7,080,000 on January 16, 2019'' Who are those key stakeholders? And what happens if they don't agree?
- woah 8y ago
  There will be 2 blockchains, like what happened with The DAO and Ethereum Classic
  - xiphias2 8y ago
    It was actually a theoritical question...we all know that Ethereum governance at the end is 1 person (I don't want to say his name here, as the blog post didn't mention it). If you look at Bitcoin governance, there's no way a developer (or developer group) would be able to force any hard fork, which means that you can always use the old codebase to verify blocks and send money, and people will accept it. Backwards compatibility will stay with us for a long time.
    - ymolodtsov 8y ago
      It just means Bitcoin is not advancing.
kpcyrd 8y ago
Is there a CVE yet?
gammateam 8y ago
How much did they win from the Ethereum Foundation's bug bounty program? I can't tell how things are valued
panarky 8y ago
Detail on how the exploit works https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9 https://medium.com/chainsecurity/constantinople-enables-new-...
geoah 8y ago
Was this vulnerability disclosed beforehand to any of the eth foundation or other parties or did they learn about this after it went public? There doesn't seem to be any mention about this being responsibly disclosed.
- davidmurdoch 8y ago
  I work on ganache, one of the tools used to uncover this attack, and we only heard about it this afternoon via a Reddit post linking to a medium article.
aakilfernandes 8y ago
Yikes. And this is why we don't use "clever" solutions. For some context, gas (or operations expense) usage was never designed for re-entrency protection. After the DAO attack, in order to prevent re-entrency attacks the Solidity interpreter limited the gas of external calls. It's clever way to solve the problem. However now when we're trying to change around the gas for certain operations, it's jeopardizing previous contracts that relied on this "clever" solution. To be honest, this is really bad, cause I'm not sure how Ethereum can ever safely adjust gas. Edit: I'm not sure how Ethereum can ever safely adjust gas... until they go back and "monkey patch" all the smart contracts that used the external gas call limit. Since we only can see the compiled code, there's no real way to know if a deployer explicitly wanted that external gas call limit, or was just using it for re-entrency protection.
- api 8y ago
  The whole Ethereum VM is too complex. For a role like smart contracts you'd want something dirt simple with few operations and provability.
  - aakilfernandes 8y ago
    IMHO the VM here isn't really the problem. Its the compiler. The way I look at it this is really a compiler bug, that only gets "activated" with this upgrade.
    - amluto 8y ago
      The whole design is bad. Calls out to untrusted code should never have been allowed. You should be able to send messages out to untrusted code and to send ether. Perhaps the recipient of a message could be allowed to raise an exception, thus causing the transaction to abort, but otherwise the untrusted code should never have been allowed to reenter anything.
      - aakilfernandes 8y ago
        There's a simple way to prevent re-entrency. ---------- bool isEntered = false; function doSomething() { if (isEntered) { throw; } isEntered = true; ...; isEntered = false; } ---------- I don't really understand why they went with this gas-limit solution. I feel like there must be something I'm missing cause its too obvious.
Animats 8y ago
"We want you to install this new version of a program that handles your money by tomorrow or else, and we haven't finished the patch yet." What could possibly go wrong?
- davidmurdoch 8y ago
  That's not how things work here. The software is already installed with instructions to behave differently at some point tomorrow. They are asking that users delay the switch to the new behavior.
  - lvs 8y ago
    That makes it almost worse. You're already holding a ticking time bomb, and we'll let you know how to defuse it in a few hours. p.s. As far as I can tell from skimming the background, no vulnerable contracts have actually been found.

62 points by Jhsto 8y ago

ascendantlogic 8y ago

Glad they caught the bug before the fork instead of after.

FracMat 8y ago
No going back after a fork. Due to this the Ropsten test network will likely be reset completely!

Nanocurrency 8y ago

I wish they could have continued without it. Issuance reduction was really important, we've had too much selling pressure for too long. It might have eased it.

DennisP 8y ago
They're planning to, it'll just take a few days to update the code and give node operators time to download the new clients.

xiphias2 8y ago

,,key stakeholders around the Ethereum community have determined that the best course of action will be to delay the planned Constantinople fork that would have occurred at block 7,080,000 on January 16, 2019'' Who are those key stakeholders? And what happens if they don't agree?

woah 8y ago
There will be 2 blockchains, like what happened with The DAO and Ethereum Classic
- xiphias2 8y ago
  It was actually a theoritical question...we all know that Ethereum governance at the end is 1 person (I don't want to say his name here, as the blog post didn't mention it). If you look at Bitcoin governance, there's no way a developer (or developer group) would be able to force any hard fork, which means that you can always use the old codebase to verify blocks and send money, and people will accept it. Backwards compatibility will stay with us for a long time.
  - ymolodtsov 8y ago
    It just means Bitcoin is not advancing.

kpcyrd 8y ago

Is there a CVE yet?

gammateam 8y ago

How much did they win from the Ethereum Foundation's bug bounty program? I can't tell how things are valued

panarky 8y ago

Detail on how the exploit works https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9 https://medium.com/chainsecurity/constantinople-enables-new-...

geoah 8y ago

Was this vulnerability disclosed beforehand to any of the eth foundation or other parties or did they learn about this after it went public? There doesn't seem to be any mention about this being responsibly disclosed.

davidmurdoch 8y ago
I work on ganache, one of the tools used to uncover this attack, and we only heard about it this afternoon via a Reddit post linking to a medium article.

aakilfernandes 8y ago

Yikes. And this is why we don't use "clever" solutions. For some context, gas (or operations expense) usage was never designed for re-entrency protection. After the DAO attack, in order to prevent re-entrency attacks the Solidity interpreter limited the gas of external calls. It's clever way to solve the problem. However now when we're trying to change around the gas for certain operations, it's jeopardizing previous contracts that relied on this "clever" solution. To be honest, this is really bad, cause I'm not sure how Ethereum can ever safely adjust gas. Edit: I'm not sure how Ethereum can ever safely adjust gas... until they go back and "monkey patch" all the smart contracts that used the external gas call limit. Since we only can see the compiled code, there's no real way to know if a deployer explicitly wanted that external gas call limit, or was just using it for re-entrency protection.

api 8y ago
The whole Ethereum VM is too complex. For a role like smart contracts you'd want something dirt simple with few operations and provability.
- aakilfernandes 8y ago
  IMHO the VM here isn't really the problem. Its the compiler. The way I look at it this is really a compiler bug, that only gets "activated" with this upgrade.
  - amluto 8y ago
    The whole design is bad. Calls out to untrusted code should never have been allowed. You should be able to send messages out to untrusted code and to send ether. Perhaps the recipient of a message could be allowed to raise an exception, thus causing the transaction to abort, but otherwise the untrusted code should never have been allowed to reenter anything.
    - aakilfernandes 8y ago
      There's a simple way to prevent re-entrency. ---------- bool isEntered = false; function doSomething() { if (isEntered) { throw; } isEntered = true; ...; isEntered = false; } ---------- I don't really understand why they went with this gas-limit solution. I feel like there must be something I'm missing cause its too obvious.

Animats 8y ago

"We want you to install this new version of a program that handles your money by tomorrow or else, and we haven't finished the patch yet." What could possibly go wrong?

davidmurdoch 8y ago
That's not how things work here. The software is already installed with instructions to behave differently at some point tomorrow. They are asking that users delay the switch to the new behavior.
- lvs 8y ago
  That makes it almost worse. You're already holding a ticking time bomb, and we'll let you know how to defuse it in a few hours. p.s. As far as I can tell from skimming the background, no vulnerable contracts have actually been found.