Okay, It's been some time since I had to deal with coding of this tricky nature. But I just now was able to present that snip to someone who codes extensively/daily for a living, and he confirmed what I said. "Read and send" (NOT write!!!). For those more familiar with linux, it's like a remote kind of 'cat' command. It dumps text files to the screen or output pipe. Presumably directory structure as well (if readable/owned by same user), as they're files too. All this exploit would do is put a backdoor into the infected wallet client such that someone knowing the backdoor existed could start looking around on the hard drive of the infected client for files that were set readable by the same user account that was running the infected client.

So on a multi-user system, this should not have happened as Cryptsy said -- unless cryptsy was doing some incredibly negligent stuff regarding their server allocation and file permissions thereon. They would have had to have global read permissions set on all their wallet files, either at the system or group level. OR, they were running all the clients (including the bitcoin client) under the same username/account -- which then gave each and every one of the clients the ability to read the files created by all of them. Again -- INCREDIBLY irresponsible, and unbelievable. And it still doesn't explain why they'd be running them on the same physical or virtual machine that had wallet files containing keys protecting access to $6.6+million dollars (price of btc on the date of the alleged hack was ~$582).

This would have been a firing offense for anyone at any modern corporation. I can assure you. And anyone who has real-world experience would know better than to have made the mistakes that would have had to have been made if Cryptsy's account is true.

If you had $6.6 million sitting in a wallet.dat file on a computer, would you download strange unknown executables onto that same machine and run them? Give me a break...

Epinnoia

Posts

Merits