Mining platform criticized by developer who discovered command injection flaws
Developers of a cryptocurrency miner found to have huge faults in its security have been criticized for their attitude towards plugging the holes.
Flaws found within the SiaBerry mining unit include command injection, which can allow an attacker to take control of the system.
The vulnerability was first talked about seven months ago, when concerned Reddit users pointed out major issues in the platform’s code.
Commenters called out SiaBerry for placing user-controlled data into exec calls, a pattern they deemed dangerous.
But SiaBerry developer Kete Tefid claimed the platform was secure and released a statement which read: “I have put much time into the software to make sure that everything works accordingly.
“I myself have checked things and tried to break possible forms literally more than a thousand times to the point that I was certain that I myself cannot somehow break it and get unauthorized access.”
Tefid’s comments could be taken to infer that he thinks the miner is completely 100% secure and unbreakable.
Perhaps it was this sense of confidence that drove him to be proven wrong months later.
Blogger Space Duck – aka developer Michael Lynch – released a write-up yesterday detailing the security flaws he has discovered in the SiaBerry platform.
The most serious find was a command injection vulnerability on the login page of SiaBerryOS.
He described the “painfully easy” exploit – just three lines of code – on his blog here.
However, it was the response from Tefid and the SiaBerry team that has angered the security community.
Tefid reportedly ignored suggestions that the platform had basic security issues, and failed to address the flaws months ago.
He and Lynch later failed to agree on a disclosure timeline of 60 days, claiming he would need six months to fix the simple flaws.
And despite a quick fix release to address some of the vulnerabilities, SiaBerry has remained relatively silent since yesterday’s disclosure.
It should be pointed out that for typical uses of SiaBerry, the vulnerabilities are relatively low risk, as an attacker needs network access to the device.
Ultimately, Lynch’s report was damning: avoid SiaBerry.
He wrote: “SiaBerry’s team does not demonstrate an understanding or commitment to security.
“I don’t believe they are trustworthy custodians of your Siacoin, so I recommend against using SiaBerry software to manage your Sia node.”
This incident once again raises the issue of how a company should – and shouldn’t – respond to a security disclosure.