5 ms·
Pirates is way too heavy a term here. This is for-profit and closer to true piracy than file sharing is. It could be unintentional, but if they've already been
by smosher 14y ago
Pirates is way too heavy a term here.
This is for-profit and closer to true piracy than file sharing is. It could be unintentional, but if they've already been contacted about it they really should be quicker to resolve the situation.
They're also shooting themselves in the foot,
No surprise there, see http://img820.imageshack.us/img820/1641/itsfinetrustme.png http://img820.imageshack.us/img820/1641/itsfinetrustme.png for an example of the judgment they've shown.
- hdra 14y agowhat was that? an exploit in the SMB game?
- smosher 14y agoYep. MySQL credentials in the binary.
- vially 14y agoHonest question: how could they have avoided that?
- benwerd 14y agoOne obvious, safe way: set up an API on their servers, abstracting away the need to send actual MySQL calls over the Internet.
- thom 14y agoWhile this case is particularly egregious, you are still accepting data from an untrusted remote client.
- uxp 14y agoYes, but you can fine grain permissions so a unique client can alter a high score that they previously held, but not alter everyone's scores, which is difficult if not completely impossible in MySQL directly, as well as sanitize data to reject wildly incoherent submissions. The possibilities of pre-formatting data are endless with an API. Not so much with an INSERT statement.
- xsmasher 14y agoEvery public web site on the planet is "accepting data from an untrusted remote client" - but allowing public db access is something else entirely.
- thom 14y agoNot every public web site enforces its business logic in client-side JavaScript and just accepts as valid the data that's submitted to a server. Every game that wants to submit a score to a central scoreboard has this problem, and it's a little absurd to debate the exact protocol by which an insecure-by-design architecture gets exploited.
- rictic 14y agoYou can submit the input sequence used along with the high score. You've then transformed the problem for the attacker from simply sending up an artificial score to writing a program to solve the game, which is harder and was an existing vulnerability already.
- thom 14y agoI thought this was my exact point. I was responding to a comment that replacing the database connection with an API would solve the problem. It wouldn't. Accepting a score from the client is insecure by design.
- makomk 14y agoEvery game basically has to trust the scores submitted by users. That doesn't mean it should trust users to mess with other users' scores, and it certainly doesn't mean it should trust users to mess with levels that other users have designed.
- sk5t 14y agoIf one must directly access the database from a client application, the right way is to make sure each user has an unique, secure database credential with only the minimal permissions necessary. However, direct database access is still a terrible idea in most cases, as it is a lot of work to prevent a resource starvation attack.
- lutze 14y agoFrom what I recall of the story, the login for SMB's level database was stored in plaintext in the exe. That picture is the guy who found it telling the devs, and the devs not understanding why it's a problem. Cue their database being "hacked" a short while later... and another internet meme is born!
- raverbashing 14y agoHere's a lesson, never trust user input! This is not the first time, and not the last time either. (I'm waiting for the posts saying they should be using PostgreSQL)
- smosher 14y ago(I'm waiting for the posts saying they should be using PostgreSQL) I'm not that guy, but I've always liked Postgres.
- rcgs 14y agoAs someone who likes to understand potential security issues, and who has just embarked upon a project which is using PostgreSQL, what is the subtext of your comment?
- phoboslab 14y agoTommy Refenes has stated in an interview[1] that he said "it's fine" just because at the time he couldn't do anything about it. The level editor was programmed in a rush and he didn't think that anyone would exploit something offered to them for free. In the end, the guy who warned him that an "evil hacker" could compromise the system, turned out to be that evil hacker himself. For us web devs it pretty obvious that anything that can be exploited will be exploited. Tommy was naive about it. Imho, his "it's fine" comment made it worse - what he should have said is "thanks, but I can't fix it right now". [1] http://www.youtube.com/watch?feature=player_detailpage&v=C2Y-gUIan88#t=3679s http://www.youtube.com/watch?feature=player_detailpage&v...
- incision 14y ago>The level editor was programmed in a rush and he didn't think that anyone would exploit something offered to them for free. There's simply no way he actually believed that. It reads as a way to further shift blame to the exploiter by painting him as someone who hasn't just exploited an indie game darling, but has taken advantage of their altruism. >In the end, the guy who warned him that an "evil hacker" could compromise the system, turned out to be that evil hacker himself. I really wonder if Mr. Hacker would have gone ahead and done that if Tommy hadn't been so smug about blowing the guy off. If "it's fine" was asking for trouble, "I've done this for a while now" was positively begging for it. I vaguely recall this incident from when it happened, but having recently watched Indie Game The Movie puts a new perspective on it. That chain of events fits the personalities demonstrated in the documentary like a glove.
- chris_wot 14y agoThat, my friend, is called spin. I don't believe for one moment that the response "I've done this for years" doesn't smack of eye rolling and dismissiveness. The right answer would have been "DM me", but that was done by the other side.