Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 2019 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 2019 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Hudson Jameson
@Souptacular
No it's actually that I can somewhat manipulate WiFi and Bluetooth signals.
But weakly.
Danny Ryan
@djrtwo
keep practicing
Hudson Jameson
@Souptacular
So it's a shitty superpower.
Lane Rettig
@lrettig
Actually I think that sounds like a cool superpower
Nick Johnson
@Arachnid
That's okay, this evening I'm playing a druid who's literally a walking medicine cabinet, so...
Lane Rettig
@lrettig
Can we have an all core devs RPG session once Constantinople is over and done with? @Souptacular can DM
Nick Johnson
@Arachnid
:+1:
5chdn
@5chdn
@veox not understanding the question
Noel Maersk
@veox
@5chdn It still "would be nice" to have an estimate of when block #7080000 will be. Not just roughly (from memory, or guess).
May I also remind all that Ropsten, Rinkeby, Kovan, Goerli, Gangnam, and (pretty soon) Ikmyeong Na's ProgPoW fork are open for demonstration of the "fresh" vulnerability, without much cost (time) of experiment set-up.
Michael Zhou
@Dominator008
What's the fate of EIP-1283?
Will it be included?
Noel Maersk
@veox
Some projects are offloading data storage to testnets. Others are doing pegs. The possibility of disruption to feed back into ETH main-net is not zero.
@Dominator008 To be discussed on (regular) Friday meeting.
Michael Zhou
@Dominator008
Ok thanks
Tomasz Kolinko
@kolinko

Ok, so we found a contract in the wild that can be exploited. An old unused one, but shows the pattern in the wild. 0x693399AAe96A88B966B05394774cFb7b880355B4 - reentrancy between agreeToTrade and offerTrade to trigger balance underflow.

More details on EthSecurity telegram group, since here it's offtopic if I understand correctly (or I can copy the details here as well, @holiman )

Noel Maersk
@veox
I'd say it's reasonably on-topic... But that's IMO. Perhaps a link?..
Benjamin Burns
@benjamincburns

@MicahZoltu I think one part of the story might be the not-so-long-yet availability of Constantinople dev tools. We released the EthereumJS Constantinople VM 22 Nov 2018, it took Truffle some time to integrate and the first Constantinople-ready Ganache version came out just 6 days ago. Since ChainSecure uses this first beta to test the vulnerability my assumption is that these releases might have triggered experimentation, will investigate this further.

One outcome of this might be to take dev tool readyness stronger into account when planning a hardfork date, and make release of the 2-3 most used tools (and not just the VM as some base layer) a precondition for some date settlement.

I share the concern (I'm a member of the Truffle team and oversee the development of ganache-core and ganache-cli).

Who should I be coordinating with to make sure we're supporting things appropriately here?

also if there's a formal (or informal) retrospective on this, I'd be happy to participate
Noel Maersk
@veox
@kolinko Did you detect it by scanning or manual review?.. If the latter, and the scanners don't detect it when they finish their runs, it's a rather strong signal that the scanners' capabilities are insufficient.
Tomasz Kolinko
@kolinko
scanning + manual review
and here's the description of the example contract exploit
Nick Johnson
@Arachnid
Oh god, we have a telegram group too?
Tomasz Kolinko
@kolinko

Quoting Hubert from ChainSecurity who double-checked my findings:

Here is how it works for contract 0x693399AAe96A88B966B05394774cFb7b880355B4. This is a contract that can be used to exchange ether and tokens. The attacker acts as follows within one transaction:

We assume that the balance of the attacker is one token.

  1. The attacker first calls offerTrade(1,1) from the attacker's smart contract deployed at attackerAddress => Exchanging one wei for one token
  2. The attacker calls agreeToTrade(attackerAddress) with 1 wei as value. This will perform some checks and then execute _from.send(), which activates the attacker contract.
  3. The attacker contract calls offerTrade(0,2) which know only costs 1513 gas and sets the tokensOfferedOf[attackerAddress] = 2.
  4. agreeToTrade() continues and balanceOf[_from] -= tokensOfferedOf[_from]; underflows. The attacker now has a quasi infinite balance and can transfer all these tokens.

The problem is this sequence.
if (balanceOf[_from]<tokensOfferedOf[_from]) throw;
if (!_from.send((msg.value*(100-ethTaxRate))/100)) throw;
balanceOf[_from] -= tokensOfferedOf[_from];

It is expected to be executed atomically, but this is not true due to the reentrancy.

@Arachnid telegram group is EthSecurity - mostly about security talk, this channel is for core development as far as I understand
(if anyone is interested more about this contract, pm me for the invite to telegram, to keep this group on topic)
Nick Johnson
@Arachnid
@kolinko I'm not griping about the existence of another channel, I'm griping about the use of yet another protocol. :)
Tomasz Kolinko
@kolinko
c'est la vie :)
5chdn
@5chdn
yeah, but it's not a reactive channel ("vulnerability response") but a proactive one ("security research").
@benjamincburns check maybe ethereum-cat-herders/hard-fork-checklist#1
Benjamin Burns
@benjamincburns
thanks! will add my response there as well
I'm a bit late to the party here, but it seems there's some consideration of removing EIP1283 and proceeding with the fork? Is this a time-sensitive decision, or is the time-sensitivity mainly focused on delaying the fork?
Nick Johnson
@Arachnid
@benjamincburns The current plan is:
  1. Delay the fork (done, basically)
  2. Either remove the EIP (most likely) or fix it (less likely)
  3. Reschedule the fork.
Since 1. is done, 2. and 3. are less time-critical.
Benjamin Burns
@benjamincburns
specifically I'm wondering if we should work quickly to get out a beta build of ganache-cliwhich removed EIP1283
Nick Johnson
@Arachnid
That's the most likely result, I think, but I don't think you need to hurry to do it until we have a new hardfork-meta.
(Others may believe otherwise.)
Benjamin Burns
@benjamincburns
ah, we'll do our best to get a jump on it, either way
seems like a "the sooner the better" sort of thing
Nick Johnson
@Arachnid
Yes, but better if we all work on the same thing. It'd suck to have Ganache implement a variant that nobody else does. :)
Benjamin Burns
@benjamincburns
probably won't resort to heroics, but yeah - we'll do our best to be prompt :-)
is EIP1283 already isolated as a flag in the ejsvm? if not, is someone working on that PR already?
Noel Maersk
@veox
@holiman Before I forget: http://forkmon.ethdevops.io/ recommends now-outdated versions. It might still be valuable as-is, though.
Ghost
@ghost~5bf74ce8d73408ce4fafd49f
:clap: :clap: :clap: :clap: :clap:
Lane Rettig
@lrettig
@Arachnid Why was SSTORE changed rather than introducing a newer, cheaper opcode eg SSTORE_CHEAP? Was the desire to reduce gas costs for existing contracts?
Nick Johnson
@Arachnid
@lrettig What would the advantage of a new opcode have been?
Liam Horne
@snario
Mentioned this earlier to @lrettig too ^ -- if it were a new opcode it could then be added to new versions of Solidity and other languages down the line as an upgraded feature (e.g., in Solidity 0.6 or with pragma experimental SStoreCheap); thus giving people time to develop using this instead, read about the changes and potential security risks, and implement their contracts with this knowledge in mind.
Noel Maersk
@veox
It would've been vulnerable in the same manner, though...