Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Super Meat Boy leaves database wide open

forums.somethingawful.com

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Super Meat Boy leaves database wide open

#41

Post by Natsu »

funkah wrote: post #26
z92 wrote: post #13

So what would be the solution? He used a password protected database connection and put the password compiled in binary. If I was doing it I would have probably done the same. How else can it be done? Use web service? That would still look "open" to someone digging inside the compiled binary and getting the keys.

I can't believe how many people here think this is okay. YES, a web service! Please never apply to a company that I am working for!

Maybe the new FizzBuzz should be to show prospective devs some DailyWTF articles and see whether they laugh, cry, or think it's a great idea....

Re: Super Meat Boy leaves database wide open

#42

Post by pferde »

ojbyrne wrote: post #12

So it could be that they create a mysql "database" for each user, and give them all the privileges needed there, and no privileges anywhere else. And conceivably you could have some kind of proxy that looked like mysql but actually sanitized/logged/whatever any queries, before passing them on to the real server.

Since that would take more effort and time than simply doing it right, I call Occam's razor.

Re: Super Meat Boy leaves database wide open

#43

Post by TillE »

socksy wrote: post #33
zyb09 wrote: post #30

Earlier quoted context omitted.

In good tradition the most critical comment is the top voted on HN. Yada Yada indie life is hard, but no one with a right mind would think of connecting the client directly to the remote master database. This is just so WTF on so many levels, you can't help but wonder how they even managed to produce such a good game after all.

Yes, it seems obvious to web developers and developers that are used to working with databases and CRUD apps, but that's one set of skills over a particular domain. Game development tends to emphasise a whole different set of skills — those of efficient graphic rendering, for example. A points table is no doubt a last minute add on in a field that certainly wouldn't be the expertise of a small indie developer (no-one…

I can't imagine anyone specializing to such an extreme. If you want to make multiplayer games, for example, you have to know this stuff.

Every competent programmer should be familiar with basic security principles. It's then your responsibility to educate yourself about how to apply those principles in a given situation.

Re: Super Meat Boy leaves database wide open

#44

Post by idonthack »

socksy wrote: post #33
zyb09 wrote: post #30

Earlier quoted context omitted.

In good tradition the most critical comment is the top voted on HN. Yada Yada indie life is hard, but no one with a right mind would think of connecting the client directly to the remote master database. This is just so WTF on so many levels, you can't help but wonder how they even managed to produce such a good game after all.

Yes, it seems obvious to web developers and developers that are used to working with databases and CRUD apps, but that's one set of skills over a particular domain. Game development tends to emphasise a whole different set of skills — those of efficient graphic rendering, for example. A points table is no doubt a last minute add on in a field that certainly wouldn't be the expertise of a small indie developer (no-one…

>Yes, it seems obvious to web developers and developers that are used to working with databases and CRUD apps, but that's one set of skills over a particular domain. Game development tends to emphasise a whole different set of skills — those of efficient graphic rendering, for example.

Team Meat got their start in flash games. They should have learned this shit a long time ago.

Re: Super Meat Boy leaves database wide open

#45

Post by HalibetLector »

TillE wrote: post #43
socksy wrote: post #33

Earlier quoted context omitted.

Yes, it seems obvious to web developers and developers that are used to working with databases and CRUD apps, but that's one set of skills over a particular domain. Game development tends to emphasise a whole different set of skills — those of efficient graphic rendering, for example. A points table is no doubt a last minute add on in a field that certainly wouldn't be the expertise of a small indie developer (no-one…

I can't imagine anyone specializing to such an extreme. If you want to make multiplayer games, for example, you have to know this stuff. Every competent programmer should be familiar with basic security principles. It's then your responsibility to educate yourself about how to apply those principles in a given situation.

No, you don't. I work for one of the top social gaming companies around right now and programmers do specialize to a ridiculous degree. The programmers who write code for the actual game are rarely web developers. It's simply a different domain.

I can confidently say this because I'm a web developer in a studio of game developers and most of them don't even know how to run mysql locally. They aren't stupid, they could, if they spent the time to learn it. But they are much more interested in improving the efficiency of their A* pathing algorithm.

Re: Super Meat Boy leaves database wide open

#46

Post by richardeid »

Hi, I registered because I had read this story earlier today and decided to contact Team Meat's developer and ask him a question. His response prompted me to post this here. My question is of a political nature, but you can ignore that part. The part that struck me as odd, and the part that matters for this conversation, was where he claimed nothing happened.

https://lh5.googleusercontent.com/-kc0f6ZQZebY/TvWDhFSHYEI/A...

Note that I sent him the tweet at exactly midnight my time. A short time later, a thread on the Steam forums was updated with:

https://lh5.googleusercontent.com/-itY306KgvLk/TvWGR_cQkiI/A...

To give that a little context, once the details of this vulnerability were in the wild the shenanigans everyone ran on their database had affected everybody's ability to play the game. It would crash upon launch.

Anyway, he responded ~two hours later, just after that post on the Steam forums noted that the game was playable again.

Does "nothing happened" seem accurate here? And for anyone that has the skills to access that database, is it still accessible and...modifyable?

Re: Super Meat Boy leaves database wide open

#47

Post by jrockway »

citricsquid wrote: post #11
kevingadd wrote: post #8

The idea of doing an UPDATE on the custom levels table every time someone dies in order to increment the deaths counter terrifies the database administrator in me. That'll scale REAL well. Yikes.

Asking the database administrator in you, what's the most efficient way to do it? Queue and push updates every 10 minutes?

One is: don't use the database for this. Lock/read/write/unlock is very slow when you need a round-trip over the Internet for each phase. (Remember, with optimistic locking, many transactions are in the Lock/read state as the same time. When someone writes the new death count, all transactions in the lock/read state are rolled back and started from the beginning, as the data read is now invalid. And that's assuming MySQL is not in read uncommitted mode; then you just throw away data randomly.)

The correct way to count something in a relational database is to add a relation (row) for each event, and then COUNT them all. How do you count log message in log files; by having syslogd update a count file? Nope. wc -l.

(And no, I'm not a fan of auto-incrementing integer primary keys, because read/calculate/write is slow. Databases have ACID so that read/calculate/rewrite is safe. But that doesn't mean that type of workload is going to run fast. Of course, autoincrementing primary keys is specially optimized by most databases, so you never notice in this particular case.)

Re: Super Meat Boy leaves database wide open

#48

Post by simonw »

forrestthewoods wrote: post #18
benologist wrote: post #14

Earlier quoted context omitted.

We do millions of operations like that a minute by queuing, aggregating and then committing. SQL Server's MERGE is particularly useful for it, although on our MongoDB stuff (and ironically, for player created levels) we do $incs.

I know next to nothing about this kind of stuff. If I wanted to create a stats + user generated level database system akin to Super Meat Boy (and I do) do you have any recommended resources to read?

I'd strongly suggest looking in to Redis - it's fantastic for stats collection and very easy to work with.

Re: Super Meat Boy leaves database wide open

#49

Post by z92 »

jarrett wrote: post #16
z92 wrote: post #13

So what would be the solution? He used a password protected database connection and put the password compiled in binary. If I was doing it I would have probably done the same. How else can it be done? Use web service? That would still look "open" to someone digging inside the compiled binary and getting the keys.

Fair question. A web service would indeed be a better solution. With a web service, you have a server-side application layer, and all database reading and writing is done by that layer. Sure, you might be able to authenticate and send bogus info to the web service. Even that can be made very difficult, e.g. by cryptographically signing requests or encrypting the data on the wire. So if you do that, worst case scenari…

There is a misunderstanding. Someone connecting to a "open" MySQL server will only be able to run those type of queries (select,update or delete) that he is explicitly permitted to run and only on those database and tables where the admin has granted him access.

Not too different from a web service.

Also no amount of encryption will secure the system because it's not about man in the middle attack. It's about decompiling the binary. The attacker has full access to all your encryption functions, routines and everything you put there. See it as like he has all your client side source code.

The only benefit I see in using a web service is restricting one user from accessing other users data in the same table. It's about only 20% improvement in security as I see it. And that's only because MySQL doesn't support row level authorization.

Other issues that are not any more secure through a web service:

1. Crash the MySQL server by running rouge queries. On the other side an attacker can DOS a web service too.

2. One can run Insert/Update/Delete queries on MySQL. Well web services has to run insert/update/delete queries too based on user input --- where the attacker modifies the source code that generates the input.

3. One can validate input using web service. One can validate input using MySQL trigger/SP too.

Just trying to show that I don't see much improvement in security using a web service when the attacker is controlling your client side source code. Basically MySQL is also a service that you can control, but it doesn't run on port 80.

Re: Super Meat Boy leaves database wide open

#50

Post by __david__ »

funkah wrote: post #26
z92 wrote: post #13

So what would be the solution? He used a password protected database connection and put the password compiled in binary. If I was doing it I would have probably done the same. How else can it be done? Use web service? That would still look "open" to someone digging inside the compiled binary and getting the keys.

I can't believe how many people here think this is okay. YES, a web service! Please never apply to a company that I am working for!

Well they say when all you have is a hammer... Actually, a web service doesn't seem like a bad idea to me--it's easy to implement and would allow finer grained permissions than direct database access. It's also easy to move to SSL. What would you do instead?
Post reply on HN