EOS 抵押 漏洞

[etwallet]

攻击的命令示例：
cleos --wallet-url http://localhost:6666 --url http://mainnet.genereos.io:80 system delegatebw sujianzhong1 etokengogogo "0.0001 EOS" "0.0000 EOS" --transfer

攻击示意图：

[etwallet]

can I get eos reward！

[ghost]

By bonuses in general, all are silent, it seems to me that they do not pay.
I've already stopped looking for bugs.

[ghost]

I hope that you will receive a bonus if this is considered a vulnerability.

[jjnetcn]

1：） 系统设计提供 sender帮reciver抵押xx资产的操作
操作中可以打开--transfer开关使得sender的xx的资产转移给reciver之后，然后进行抵押
（语义上就是我帮你抵押， 并且归属给你了不用换了）。

2：） 系统设计对于扣抵押费有一个优先级判断，如果有正在归还的抵押那么优先扣除，否则从账户余额扣除。

当-transfer开关打开的时候，system_contract::changebw优先扣除的抵押错误的扣除在了reciver之上，然后剩余部分才从sender扣除。
从结果上说，这并没有财产损失（reciver的财产从子账户转移到主账户的操作）（sender赠送的金额比操作的要少）。 但是这比较坑， 本来3天以后reciver的refund_request就要到了， 结果sender又继续帮他压进去了， 如果你想坑某个人就过两天就“帮他”吧他的refund_request全部再次抵押，换而言之“有心计的话被攻击者抵押的钱永远在路上取不回来”

实际上，
1：）和2：）因为逻辑上有点冲突， 当同时发生时，有三种可能的操作
a: 因为sender转移xx到reciver了，所以sender应该考虑为reciver同一人，从reciver里面的refund
里面扣除，多的再管a要， 实际上目前代码就是这么个逻辑，从这个意义上说不是bug
b: 无论如何， 分解成transfer(sender, reciver, xx), delegatebw(reciver, reciver, xx)的两步操作，
即首先让sender给reciver个xx，然后reciver在去抵押，并且优先抵押自己的refund部分
c: 逻辑上sender应该转移xx到reciver， 但是因为涉及到refund的抵押，所以抵押部分完全操作sender
1:优先用掉sender的refund，转移到reciver的self抵押上去
2:再次扣除掉sender的余额， 转移到reciver的self抵押上去
此操作不在进行xx的转移

个人建议改成逻辑c更符合系统设计初衷。

try translate from google：
1:) The system is designed a function delegatebw that sender can help recver mortgage net/cpu
resouce operations. this assets's owner is the sender, option --transfer switch the owner to reciver.
(Semantically, I will donate you some money to mortgage)

2:) The system design has a priority judgment in delegatebw operation. first is refund, and then balance of account

When the -transfer switch is turned on, the system_contract::changebw reduce refund from reciver by mistake, and then reduce from sender's balance. in this view, there not lost any asset,
(reciver's asset transfer from refund to mortagage, sender's donate less then it want),
but, because the refund will be return after 3days, you can let everyone refund delegatebw again,
in the other words: everyone's refund will not be return forever!

In fact, 1:) and 2:) has logical conflicts, there are three possible operations when occurring simultaneously.
A: Because the sender transfers xx to the recver, the sender should consider the same person as the reciver,
reciver's refund first, then sender's balance, the logic now use it, in this sense. it's not a bug.
B: In any case, split it into a two-step operation 1:transfer(sender, reciver, xx), 2:delegatebw(reciver, reciver, xx)
first let the sender transfer asset to recver, then the reciver do delegatebw operations
C: logically sender should transfer xx to reciver, but because of sender's refund, we use new logic:
sender's refund first, then sender's balance. all transfer to reciver's mortgage table with assign owner reciver.

i suggest the logical C, original intention of the system design.

[attritionorg]

@arhag Does this constitute a vulnerability? It is difficult to tell from this bug report.