
Security Alert: Ethereum Constantinople Postponement - Jhsto
https://blog.ethereum.org/2019/01/15/security-alert-ethereum-constantinople-postponement/
======
aakilfernandes
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
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
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
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
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.

~~~
DennisP
A similar method is to put the external call at the very end of your function,
after any state updates, and make sure that function isn't called from another
function. These are well-known techniques in the community and commonly used,
which is probably one reason the researchers didn't find any vulnerabilities
in deployed contracts.

The gas limit on send was more of a belt-and-suspenders thing, not intended as
the sole protection; that may have been a bad idea in retrospect, but at the
time people were pretty focused on adding every protection possible against
another DAO situation.

------
panarky
Detail on how the exploit works

[https://medium.com/chainsecurity/constantinople-enables-
new-...](https://medium.com/chainsecurity/constantinople-enables-new-
reentrancy-attack-ace4088297d9)

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

------
xiphias2
,,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
There will be 2 blockchains, like what happened with The DAO and Ethereum
Classic

~~~
xiphias2
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
It just means Bitcoin is not advancing.

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

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

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

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

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

------
kpcyrd
Is there a CVE yet?

