Lua lobby?

[Licho]

What sandbox? Each game dev has different need. Or you mean the sandboz where engine keeps game devs?

[smoth]

I'll let you boys hash it out

I think that the lobby chat should not be synced to the server in a way the requires us to be online to play otherwise I don't have any preference.

[aegis]

I wasn't advocating handshake as a long-term solution, just something they could implement *now* with the code they already have.

and the cool thing about handshake, you don't trust the socket to send data before the handshake is complete (server sends TASSERVER command, client send LOGIN command, server sends ACCEPTED command)

when they implement other trust mechanisms (firewall prompt, trusted existing connections, w/e), they can remove the need for a login handshake and end up with working socket code.


it's simply an easy way to trust your sockets without doing anything but shuffling around our current code (they're not talking to something on my LAN I don't want them talking to)

right now we have NO progress, instead of progress with a temporary restriction and no longterm downsides (handshake requirement can be removed at any point)

if they think it's *already* a nil security risk (I think unrestricted socket access in a mod/map is a huge security hoe), then they can add them without restrictions. otherwise this accomplishes the short-term goal (we can connect to known services) without having a major holdup in security

[AF]

Just implement raw sockets isntead, if we use a temporary handshake we all know it won't be 'temporary' and will last far longer than we would like.

Setting up a raw sockets system in unsynced code would put the emphasis on progress in a place were we can make rapid moves forward without being shackled by engine or lobby releases.

We also don't end up with a legacy of horrible work arounds either.

A handshake is a bad idea, and a TASSERVER login based handshake is an awful idea. It makes sense for talking to the current lobby server, but as soon as you think about other things, or further development, it becomes a ball and chain.

Security wise, there is nothing gained from a handshake, anything malicious can just prefix its opening traffic with 2 or 3 lines of text that are well documented and incredibly simple. Trying to bundle in signatures would make everything more complicated and break the existing lobbies without getting us anywhere further with better security.

What's more there's no case for an improvement of security via this scheme, and a verifiable detrimental effect to flexibility. Lock in of the protocol, increased complexity of client and server code, more code to maintain in the engine.

And what's to stop me running a socket proxy that fires off the TASSERVER handshake then forwards all connections, negating all the security benefits of the handshake?

I doubt the spring developers are willing to issue certificates, nor will content devs be happy that they have to wait for their lobby system to be 'approved', or that we have no means of ensuring these thigns without super complicated systems.

Raw sockets is the simplest, easiest solution, with the most flexibility. The handshake road is a well intentioned road paved with pitfalls and booby traps that immediately removes the possibility for a lot of things.

[AF]

Roughly how to thwart such a handshake in java:

Code: Select all

public void listenSocket(){
  try{
    server = new ServerSocket(4321); 
  } catch (IOException e) {
    System.out.println("Could not listen on port 4321");
    System.exit(-1);
  }

listenSocketSocketserver.acceptSocket
  try{
    client = server.accept();
  } catch (IOException e) {
    System.out.println("Accept failed: 4321");
    System.exit(-1);
  }

listenSocketBufferedReaderclientPrintWriter
  try{
   in = new BufferedReader(new InputStreamReader(
                           client.getInputStream()));
   out = new PrintWriter(client.getOutputStream(), 
                         true);
  } catch (IOException e) {
    System.out.println("Read failed");
    System.exit(-1);
  }
}

listenSocket
    while(true){
      try{
        //line = in.readLine();
        //Send data back to client
        out.println("TASSERVER 0.35 0.72b1 8201 0\n");
        out.println("ACCEPTED USER\n");
        out.println("OHAI IM A MALICIOUS MESSAGE THAT CANNOT BE TRUSTED\n");
      } catch (IOException e) {
        System.out.println("Read failed");
        System.exit(-1);
      }
    }

Code mostly taken from: http://www.oracle.com/technetwork/java/ ... tml#server

Lua lobby should have the login and server stuff in a lua header/library, not in the engine, and the initial login does not need to be in the engine, as it is highly detrimental as a design and development decision.

We managed it in python/Java/C++/C#/php, why not lua?

Here's a lua sockets library as a starting point if it's too much to adapt the existing lua lobby APIs:

http://w3.impa.br/~diego/software/luasocket/

[Cheesecan]

Fact: People don't know to be careful when downloading games and maps.

Scenario: The last thing we want is widgets accessing the filesystem and sending credit card information over the Internet.

Certificates are not really that troublesome, as long as you don't require them to be signed by a CA.

[AF]

certificates are meaningless without an authority. Who would be that trusted authority? Also the people most likely to be handed certificates ar the ones most likely to be circumventing them.

This all fails to address the myriad of issues raised by having a handshake at all, be it the TASSERVER logon, or a certificate based system.

Projects that are impossible if a handshake is added:

• Rival lobby protocols
• Visualisations based on service data
• Pulling in news and twitter feeds
• Built in support for ladders
• My game has a site with profiles and achievements? How do I make requests to SOAP APIs or XMLRPC or requests in teh form of XML or JSON strings if the target needs to respond with TASSERVER etc?
• Automate user metrics for UI a b testing
• Various custom systems for games
  ( e.g. I have a cookiebank system with cookie totals, how would a hypothetical cookie mad Smoth add cookie counts to his cookie game if we had a handshake without resorting to apache mods or lobby bot proxies? )
• Improved debug tools
  Widgets that report directly to a much more capable html or native UI in another window?

Not to mention that:

Other Engines have Sockets and work just Fine

The Unity engine has a networking API, the Unreal engine has one, why can't we?

The main reasoning I see put forward for handshakes is security. Sockets in unsynced code would not cause desyncs in that way, any more than file read access could cause desyncs, and we already have that.

Any talk of a handshake is thus misguided and silly. It's not just that using the TASSERVER logon is inappropriate, it's that the idea of a handshake or that it's a security issue that can be solved this way is incorrect.

[Cheesecan]

Trusted authority could be a springdev. Would need a little page where people submit mods/maps to be checked by some poor bastard with not enough time(app store model).

But there should be better solutions than that snail old model. Not having security at all, well that is not even a real solution. That's like saying come and exploit me. Who will be the first to write spring malware?

Oh yeah engine x has no security, why should we bother to be better? Just be like the rest.

Then again spring is open source, so we could simply blame the user who becomes a victim. "You could have read the source code yourself, noob!".

[AF]

Your proposal adds no improved security, only complexity, while taking away flexibility and ruling out features. It is quite clearly flawed.

Not to mention that spring 'malware' doesn't need a lua socket API to work, we already have a socket API in the engine. Your security concerns are unfounded and poorly thought through.

[AF]

Not to mention that your certificate scheme assumes the content itself is the risk, rather than the people in the lobby or the server its connecting to.

At which point why would you use a lobby mod when you can write a python bot in 5 minutes to do the same job but with a fraction of the overhead?

Lobby protocol security is a lobby server issue, not an engine issue.

[aegis]

filesystem security is a different issue. as it stands, a widget with filesystem access could send data over the spring protocol to another player. this has nothing to do with a lua implementation of sockets.

if we have filesystem security, the only socket restrictions we need are on services that *don't* want connections from spring. this is the entire purpose of flash crossdomain policy files, and we absolutely should address this issue before including any sort of unrestricted socket code in the protocol.

if our filesystem is open, we shouldn't lock down the network to fix it. we should lock down the filesystem access. that's an entirely different issue and just serves to misdirect when used as an argument in this case, even if it should be addressed before sockets.

I don't think it's wise to allow spring to act as a potential blind entry point into a network, given the automatic downloading of maps/mods and easy downloading of widgets - all unpoliced and easily published by anyone.

giving untrusted code unrestricted socket access to localhost (or to any arbitrary system inside my NAT) is completely unacceptable security-wise.


I've suggested a rearrange of the code we already have to give us more access to do *anything* useful, instead of barely-working chat. whether or not you have a better idea, attacking mine for limitations I've already acknowledged won't help progress on this front.

[Licho]

There is no point limiting game devs.
Game devs have to be reliable.
If they not engine cannot stop them from doing bad things anyway.
SL or ZKL or engine update could format your disk. You have to trust devs, if you trust those.
Any malicious widget or game would be spotted much faster because its easier to read lua.

So imo dont try to sandbox them. Its like limiting capabilities of phone because some apps might be malicious instead making sure there are no such apps.

This is obscure game engine with almost no players (and decreasing). Hack attemp would probably target something with known technology - like server.

Many security features just force us to hack around them.

For example - gadgets dont have player names, because it *might* be used to secretly give benefits to some players (created by game dev).
All it does is it force gamedevs to make hacks and send those data from widgets.

Likewise, quantum wanted to make voice control for spring and because there is no raw socket access, quantum has to route lobby<-> spring traffic through autohost.

It works, just adds unnecesary latency and complexity and limits the feature to ZKL + springie as always.

[zwzsg]

Thanks Licho.

I was afraid this discussion would lead to even more locking down of Lua. I was already sad when package.loadlib was removed, but if file io were also removed, that'd be super annoying.

As for the Lua lobby, use something simple, leaving all possibilities open without forcing any, or else, yes, people wanting to use it will have to write horrible workaround.

[Cheesecan]

Your proposal adds no improved security, only complexity, while taking away flexibility and ruling out features. It is quite clearly flawed.

If it's so flawed then why is it widely used in industry?

Not to mention that your certificate scheme assumes the content itself is the risk, rather than the people in the lobby or the server its connecting to.

And what threat are they posing?

Not to mention that spring 'malware' doesn't need a lua socket API to work, we already have a socket API in the engine. Your security concerns are unfounded and poorly thought through.

Thanks for stating the obvious. Let's assume engine code is reviewed.

filesystem security is a different issue. as it stands, a widget with filesystem access could send data over the spring protocol to another player. this has nothing to do with a lua implementation of sockets.

Filesystem access was just one nasty example. As you say it is possible to gain access to private networks. Change the password on your wireless firewall.

giving untrusted code unrestricted socket access to localhost (or to any arbitrary system inside my NAT) is completely unacceptable security-wise.

Exactly.

Maybe you should even ask why is Lua lobby so important to have that a whole host of new exploits should be made possible just to have it?

[abma]

raw socket access would also allow to create a downloader in lua... why to allow the lobbies network access and not the engine, too?

users still have to "trust" that downloaded stuff doesn't bad things...

[Satirik]

There is no point limiting game devs.
Game devs have to be reliable.
If they not engine cannot stop them from doing bad things anyway.
SL or ZKL or engine update could format your disk. You have to trust devs, if you trust those.
Any malicious widget or game would be spotted much faster because its easier to read lua.

So imo dont try to sandbox them. Its like limiting capabilities of phone because some apps might be malicious instead making sure there are no such apps.

This is obscure game engine with almost no players (and decreasing). Hack attemp would probably target something with known technology - like server.

Many security features just force us to hack around them.

For example - gadgets dont have player names, because it *might* be used to secretly give benefits to some players (created by game dev).
All it does is it force gamedevs to make hacks and send those data from widgets.

Likewise, quantum wanted to make voice control for spring and because there is no raw socket access, quantum has to route lobby<-> spring traffic through autohost.

It works, just adds unnecesary latency and complexity and limits the feature to ZKL + springie as always.

why don't you commit patches to fix all that crap instead of making ugly hacks ?

[abma]

why don't you commit patches to fix all that crap instead of making ugly hacks ?

+1!

yes, please make patches... and stop discussion here...

[Licho]

My commit rights were removed years ago and frankly I hate git. If it at least was SVN.. there are just too many obstacles, confusing git, confusing mingw environment.. bleh.
I admire engine devs for their ability to withstand that.

[AF]

Cheese, it doesn't work, it's well known in the security industry that certificates and https is a flawed system.

Aegis, we already have that issue with lobbies and native AIs, and there are plenty fo people who've thought of malicious lua widgets. A malicious mod is already possible and yet it hasn't arose, and if someone did abuse sockets then they'd need to distribute the mod and we could easily get around that. Just look at The registered ones attempt to nuke a mod using his models without his permission.

Also you don't know hat a developer will use sockets for, you may be pleasantly surprised, but I'd rather we didn't have to run innovation by a central authority and enforce technical limitations to get there.

[Cheesecan]

My commit rights were removed years ago and frankly I hate git. If it at least was SVN.. there are just too many obstacles, confusing git, confusing mingw environment.. bleh.
I admire engine devs for their ability to withstand that.

SVN is nice if you like to wait for long periods of time when doing checkout and commit on source code. :D

AF: Why not just share the entire contents of your harddrive on the intertubes?