Nick Chong · 2 days ago · 2 min read
Some may place EOS near the end of its post-mainnet launch teething stage; however, several developers of the dPoS blockchain have stepped in to fight off another memory-related bug—this time, allowing malicious transaction recipients to hijack the RAM of senders.
Addressed by EOS developers in a GitHub bug report, the issue permits users to insert large quantities of bogus data into the transactions of senders, thereby parasitically consuming their resources. The report explains:
“A malicious user can install code on their account which will allow them to insert rows in the name of another account sending them tokens. This lets them lock up RAM by inserting large amounts of garbage into rows when dApps/users send them tokens.”
A means of proxy transfer has since offered a solution by developers; however, blockchain-based casino EOSBet, which has already fallen prey to the issue, maintains that the fix is strictly a “temporary workaround.”
‘RAM Attack’ Hits EOSBet
Unlike vulnerabilities discovered before exploitation, the issue forced EOSBet to go offline after discovering a “malicious actor” that had been feeding on their resources. They have since resumed operations and assured no players were affected, stating:
“We temporarily disabled gameplay and took our site offline to prevent further attacks. All funds are safe and players who experienced payout glitches have been manually reimbursed.”
While the EOSBet team claims to have worked “around-the-clock” to achieve this, the team also reports working alongside other developers to devise a more permanent solution to the network-wide vulnerability. Currently, users must send tokens via a RAM-less, and thus bugless, proxy account to assure the welfare of their memory.
— EOSBet (@EOSBetCasino) August 26, 2018
As a finite resource integral to the operation of EOS dApps, RAM appears to have become both a hot commodity and chronic headache for the fifth largest cryptocurrency by market capitalization.
As reported previously by CryptoSlate, several EOS block producers crashed in early June when they exceeded a net 1Gb of memory consumption, and while lead block producer EOS New York put the fault down to human error, one might eye the platform’s emerging RAM-hoarding market or recurring governance issues as exemplary elephants in the room.
Coupled with the latest bug and its seemingly enterprise-foreign solution, such issues would certainly appear as a number of kinks to be ironed out; at least before the proverbial ribbon-cutting ceremony of a truly industry-ready smart contract platform.