High-risk Security vulnerabilities Left Unche

eosforceeosforce Posts: 2 Brand New

Why BP Candidate Alliance Couldn’t Successfully Launch EOS Mainnet NO GO

Final Warning From EOSForce.io

This is a technical article for the developers of the BP candidate team and those interested in EOS security research.

As a team has conducted in-depth research on EOSIO software and has conducted extensive deployment testing, EOSForce.io has repeatedly warned the security risks of mainnet, and has fixed some problems identified already. Recently, as the research deepens, we have discovered more potential security risks, and some other BP candidate have begun to pay more attention to the safety of the mainnet.

We are going to reveal nine core security issues that still plague us up to now. We have made some preliminary solutions ourselves since Block.one claims not to be responsible for the security of any mainnet. We also attempt to help you understand why EOSForce.io's changes to EOSIO are necessary. If there is a better solution, we also hope that you could communicate with us and contribute to the safety of EOS. EOSForce.io promises not voting for the Block Producer, and will not start the mainnet until the public testing is completed. It is highly not recommended that users import private keys to activate mainnet assets before that.

In order to tackle the current troubles of EOS, EOSForce.io has made the latest precautions, hoping to start the EOS mainnet safely with minimum functionality. Then slowly release the corresponding functions after the formal verification of each restriction module and the large-scale test verification passed.

1st Problem: EOS proposes a resource-based mortgage model, but the implementation is far away from its original expectation. The public chains already in operation all use fee-based model.

There are two benefits of charging transaction fee:
1. To prevent chain-level DDOS, it is well-known that the reason that Ethereum's POW test network is often attacked is testnet token has no value and there is no threshold to prevent chain-level attacks. The reasonable setting of each code gas price for Ethereum in the past is also on this purpose. Everyone knows that the best way to prevent DDOS is to enforce the cost of attacks much greater than the profits.

2. Transaction fee can be used as a source of incentives to maintain the ecological stability of the entire chain. The Idea of ** EOS Based, Mortgage Model ** is innovative, free of charge, at the beginning everyone (including BM) expects to prevent DDOS via staking resources, and later expects to establish EOSraM and other related resource tokens to generate incentives. What solves the problem of transaction fees. However, the issue of transaction fee is only a bit of a connection between the System contract and bottom layer, and it does not meet the expectation. For developers, as long as you randomly launch a testnet, you can send transactions without any cost, which could verify the problem I mentioned. This is a fatal problem at chain level, far more severe than 360 "epic" traditional memory leak. As long as any person opens a computer, continuously to send batch transactions to EOS network. The network will fail.

EOSForce.io Prevention 1 :In response to this issue, EOSForce.io adds a price setting to each action based on EOS. At this moment, EOS has not implemented a fully opertional resource model, so we add a fee-based filter for transaction. When BM Master get it completely done, EOSForce could turn off the transaction fee filter and eventually prevent DDOS attacks through resources staking.

2nd Problem:EOS has a root user, which means that the super-privilege can be authenticated without a private key. Besides accounts that start with the characters eosio. are all quasi-super-authority accounts (there is already eosio now). This goes against the sacred inviolability of personal assets under the protection of private keys in the basic function of blockchain philosophy.

EOSForce.io Prevention 2: In response to this problem, EOSForce.io restricts the entire system to have only one privileged account, which is eosio, whose public key is all zero, the address is EOS1111111111111111111111111111111114T1Anm. No one owns or knows its private key.

3rd Problem: The design structure of the transaction is too complicated You can see the complete EOS block data we have extracted. A transaction in EOS could consist of an array of actions and multiple context free action arrays. Inline action could be added in the action , context free action does not require signature, and actions can contain a large number of inline actions. EOS is executed sequentially in action units. The transaction can also be delayed. All these designs are very innovative, thanks to BM. However, such a sophisticated system is too large and there are many points that can be attacked. Transaction with delayed transaction, an action could include multiple inline action. Such complex functionalities require long time, variety of case combinations and strong test validation.

EOSForce.io Prevention 3: We are also organizing a lot of teams to conduct testing and verification in this area. But for the safety of stakeholders, we enforce a transaction can only include a single action, limiting context free actions requiring no signature. After the successful implementation of various tests formal verification results, as well as large-scale case test verification, this layer of filter would be removed.

json { "timestamp": "2018-06-06T15:44:45.000", "producer": "biosbpu", "confirmed": 22, "previous": "000014ee93515ae0d7db528464af6224bfa737473b139055857220f106aeb187", "transaction_mroot": "ff20a984b5e09e16b2811f7377ae2c8010807f4bac9701d54781003f71900572", "action_mroot": "959829c9db819ba40ef1bf5ec2319c3bd8bb076ed21f28a74d2f6a68f0bafb29", "schedule_version": 30, "new_producers": null, "header_extensions": [], "producer_signature": "SIG_K1_JuPuQsU1GgaQZamaEsS79MsNtDCWxD2oimddjviMUrqBPTSYomXCNwyQjxiNvvPnDnLNHbeCpPjVpnrpGrFKvk4AxKSvkF", "transactions": [{ "status": "executed", "cpu_usage_us": 1121, "net_usage_words": 18, "trx": { "id": "074506ccd74de27ac8b09a0778321044104760e0495c9797cf51314169284efc", "signatures": [ "SIG_K1_KhhQGWkyxsB4NwgBvNZ6N4yLgPNjnXHaZ88ziE384rkL7f6rBnWVaar5nVj1gmNJ4C78AUS7q6GrxMvXLKjeoXc4Aobkne" ], "compression": "none", "packed_context_free_data": "", "context_free_data": [], "packed_trx": "a301185bea1497eb03b500000000010000000000ea3055000000572d3ccdcd01000000004fb3305500000000a8ed323221000000004fb330550000000028c9a6e100c2eb0b0000000004454f53000000000000640000000000000004454f5300000000", "transaction": { "expiration": "2018-06-06T15:45:39", "ref_block_num": 5354, "ref_block_prefix": 3036933015, "max_net_usage_words": 0, "max_cpu_usage_ms": 0, "delay_sec": 0, "context_free_actions": [], "actions": [{ "account": "eosio", "name": "transfer", "authorization": [{ "actor": "eosfans", "permission": "active" } ], "data": { "from": "eosfans", "to": "wangme", "quantity": "20000.0000 EOS", "memo": "" }, "hex_data": "000000004fb330550000000028c9a6e100c2eb0b0000000004454f530000000000" } ], "transaction_extensions": [], "fee": "0.0100 EOS" } } } ], "block_extensions": [], "id": "000014ef2f4789fee56fd374ca113003ada0b638d45e5fef7a1bf0ac3f8d4770", "block_num": 5359, "ref_block_prefix": 1960013797 }

4th Problem: EOS queries such as get table query interface can't specify keyword query in batches Here I have to marvel at BM's technical genius. He uses multi plugin pluggable module programming. Multiple modules are single-rowed and can be accessed by each other. In addition, he also used the message bus microservice programming mode. As long as each module is interested in the corresponding message and registers the corresponding message bus, corresponding messages can be accepted. However, many of the query interfaces in these modules can only be queried in batches. When the data is small, it is acceptable. But when there are a million tps, such a query allow basically no machine to meet the need. Although --key is a field in EOS, it is always as the memo parameter in the transfer interface in EOS code, only has a name, no implementation.

EOSForce.io Prevention 4: Add-key A fixed-point small query by keyword.

5th Problem: The faucet plugin in EOS has been deprecated for a long time and it's broken now. This plugin allows users to register a user name through a third party.

EOSForce.io Prevention 5: Reactivate faucet plugin.

6th Problem: The instability of chainbase database. For instance, you could call the interface of chainbase and store the same data twice, then the program could core dump. The multiIndex table in the EOS contract also utilized chainbase. When you modified the different columns of the same row in a table, only the last update will be successful.

EOSForce.io Prevention 6: We would review seriously the code related to this issue as well as other problematic parts.

7th Problem: EOS wasm-jit was a direct fork of Andrew Scheideckers code for the past two years, as well as a fork of the official webassembly. There are so many bugs within which requires large-scale testing.

EOSForce.io Prevention 7: EOSForce.io creates a built-in system contract since the genesis block, making the system contracts genuinely. EOSForce.io also limits setcode, setabi interface.

8th Problem: EOS has no world state. If you want to know whether the chain has been forked, the only avaliable approach is the block-level verification.
For example: Node A and B have a same transaction list, that is, the blocks are all the same. However, the two nodes excuted two different databases store for each account and the chain is unknown to that. Possibility of attack: Although BM sets that only contract table owner has privilege to modify in apply_context.cpp. However, it cannot be ruled out that the table of different contract accounts cannot be directly done related state landing attack by constructing the corresponding key value externally. At this time, all the pieces in the chain are the same, but the state storage in each node will be different, even cover the corresponding table across accounts and change the status of different contract accounts.

EOSForce.io Prevention 8:Restricts the function of freely submitting code, they would be released after all of these have been formalized.

9th Problem: Unstability of mongodb, sql plugin. The mongodb plugin works before. After a while, they want to abandon mongodb and replace it with sqldb plugin. However, this change is deadly for eco-developers.

EOSForce.io Prevention 9: EOSForce.io is recruiting blockchain developers on a large scale. There will be better and more continuous updates to the filter module and database plugins.

Blockchain is not like traditional software development. Security and stability must be the first citizen in Blockchain world, otherwise everything is zero. Each vulnerability could incur a large-scale coin-losing accident, in which case even though the million TPS makes any sense. The security and stability cannot be overemphasized. We should extend performance and expand features on the basis of ensuring safety and stability. We believe in BM, and we also respect the brilliance of EOSIO that BM has brought us. However, it is impossible for any program to have no bugs. There are essential differences between blockchain and centralized system. Centralized system's code update and data modification authority are entirely responsible by the centralized organization, and it is free to go online, find BUG, ​​fix BUG, ​​roll back data, offset account, high-speed iteration and other operations. But blockchain can't seem to be bug-free, or it would go online without obvious BUG, the data on the chain is all related to the highest value user assets, even if 99% is no problem, there is still 1% risk, as long as there is any point or dimension that can be attacked, the blockchain network will certainly fail, do not hold any chance. The EOSIO code has continued to iterate over the past year, especially in April and May. It has reduced the previous complex design, revised all the way to the 1.0 version released on 1st June, and few teams have conducted a complete test on EOSIO. The traditional security attack-defense operation and maintenance test can not be considered as a real test. What really needs to be tested is the voting process on the chain, resource-related issues, custom contracts, etc. This kind of test case needs to be written for several months. We all know that the number of Ethereum's test data and test scripts are several times of the codes themselves.

Today, the market value of EOS once reached 100 billion RMB, and the details are so numerous that it far exceeds the scale of Bitcoin and Ethereum when they went online. If the security of the chain itself cannot be guaranteed, the user's assets will shrink substantially or become zero. Block.one has always stressed officially that it will not be responsible for the security of EOS mainnet. EOSForce.io has done a lot of testing and repair of the significant risks inherent in EOSIO. No one dare to say that it is 100% safe at the moment. Now we sincerely invite all EOS community users, BP candidates, and third-party security teams to verify a secure EOS mainnet. It would go online after confirming that there are no major security risks. Welcome to login EOSForce.io to participate in the beta EOS mainnet. We pay tribute to Oracle chain, EOS Shenzhen and other teams that voted “No go”. There is no compromise on security issues.

Sign In or Register to comment.