Input map server storage

[Zruty]

Please guys, let's limit this thread to the actual technical stuff? If you want drama, please conttribute here

So, I've read the ticket 176 on Trac, and I've taken my time to read Imago's source (which, I suspect, only a few of the drama-makers did). Here's my observations:

1. Only input map is stored on the server, nothing else.
2. The name of the remote file probably on the INPUTMAP_FILE constant, which is probably supplied by ASGS and is dependent on the callsign. Not sure about this though (hey, I'm not a source code magician, and c++ isn't even my 'native' language).
3. There actually IS a possibility for the security breach, described below.
4. I personally think saving the input map remotely isn't that good thing.

Possible security issues:
1. If someone manages to reverse engineer, trace, or in other way crack ASGS, he'll be able to both get and set other people's input maps on the remote server. I think this is a minor matter, since the possible ASGS hacker will probably have own wider variety of destructive tools to annoy the community.
2. If someone is able to replace the remotely-stored version of the input map with another file, not necessarily an input map (for example, a trojan or a virus), it will be downloaded onto the target user's machine (I'm not sure if the file is deleted/replaced afterwards). Usually such malware requires user interaction to start working (i.e. run the file).
3. If the 'cloud' server logs the network traffic, the information of how IP is bound to the callsign (or its hash) will be available to the cloud server owner.

There's nothing else I can think of, security-wise.

[fuzzylunkin1]

I'm not really in a position to comment on most of these points, but I'll comment on this:

QUOTE (Zruty @ Aug 23 2010, 01:56 PM) 3. If the 'cloud' server logs the network traffic, the information of how IP is bound to the callsign (or its hash) will be available to the cloud server owner.

Do you think I would use that maliciously?

EDIT:
ASGS has nothing to do with the inputmap storage code, by the way.

[CharlieTester]

"(I'm not sure if the file is deleted/replaced afterwards)."


then you DIDNT take the time to read and UNDERSTAND the source because you would see the DeleteFile() calls, dip@#(!.

[Zruty]

QUOTE (fuzzylunkin1 @ Aug 23 2010, 11:02 PM) I'm not really in a position to comment on most of these points, but I'll comment on this:

Do you think I would use that maliciously?

If you are the owner, you have the POSSIBILITY of doing this. What you do and what you don't do is your business.

What I think is my business But I'll tell you what I think: I don't know you enough to make a conclusion. But I'm sure it's quite a bit of work involved, and it's against the 'proper' way of things. So, I settle with 'unlikely'.

EDIT for your edit: I didn't find the constant in the source, so that was my wild guess. Please point me at the location, if you please.

[pkk]

QUOTE (Zruty @ Aug 23 2010, 08:56 PM) 1. If someone manages to reverse engineer, trace, or in other way crack ASGS, he'll be able to both get and set other people's input maps on the remote server. I think this is a minor matter, since the possible ASGS hacker will probably have own wider variety of destructive tools to annoy the community.

That could be already done with R1. This is nothing new or specific with uploading Inputmap to server.

QUOTE R1 was the first and arguably the biggest development step made by the FAZ dev team. Their major acheivements were rewriting the code to incorporate the security features provided by SOVLogin and updating Allegiance for a modern compiler. The first of these changes meant that Allegiance was suddenly a lot more accessible to the average user. Instead of mucking around with router settings, SOVLogin, and ASGS, players could now simply click on a server and immediately join. This change allowed many new players to join the community.[/quote]

QUOTE (Zruty @ Aug 23 2010, 08:56 PM) 2. If someone is able to replace the remotely-stored version of the input map with another file, not necessarily an input map (for example, a trojan or a virus), it will be downloaded onto the target user's machine (I'm not sure if the file is deleted/replaced afterwards). Usually such malware requires user interaction to start working (i.e. run the file).

Same could be done with ASGS. Unlike storing mdl (config) files on a server, it's downloading and executing files (ASGSClient.exe, ASGSupdate.exe, Allegiance.exe).

QUOTE (Zruty @ Aug 23 2010, 08:56 PM) 3. If the 'cloud' server logs the network traffic, the information of how IP is bound to the callsign (or its hash) will be available to the cloud server owner.

That's already a feature of ASGS/AllLobby/AllSrv, here an example of AllSrv:

Code: Select all

08/19 21:11:31.893 New connection ID: 96231f9 IP: 84.138.183.105
08/19 21:11:32.190 New ship (player): Name=*pkk@GB(21), ShipID=27, PilotType=10
08/19 21:11:32.190 Player *pkk@GB(21) logon succeeded. Sent 1 msgs and 2398B to them in 0.000s, and 0 msgs and 0B to others in the process.
08/19 21:11:32.190 Player *pkk@GB, ship=27 joined mission=ea5b08
08/19 21:11:32.190 Sending PlayerInfo for *pkk@GB to grav@RT's game(97661400)

EDIT:
Quote of FAZ R1 (wiki)

[the.ynik]

QUOTE (Zruty @ Aug 23 2010, 08:56 PM) 1. Only input map is stored on the server, nothing else.
2. The name of the remote file probably on the INPUTMAP_FILE constant, which is probably supplied by ASGS and is dependent on the callsign. Not sure about this though (hey, I'm not a source code magician, and c++ isn't even my 'native' language).

We need some clarification on what exactly the key for the storage is. The initial commit seems to use the callsign (without token or rank) in clear-text, and the additional commits just seems to add some obfuscation (not sure though, haven't looked at it closely). I don't see ASGS supplying anything but the callsign.

QUOTE (Zruty @ Aug 23 2010, 08:56 PM) 4. I personally think saving the input map remotely isn't that good thing.

I'm not sure on this. It's certainly nice not to have to reconfigure everything when you move to a different machine. Assuming the server-side storage is safe, I think this is a good idea.
But it's hard to do this safely without involving ASGS - maybe even impossible with the information Alleg currently gets from ASGS.

QUOTE (Zruty @ Aug 23 2010, 08:56 PM) Possible security issues:
1. If someone manages to reverse engineer, trace, or in other way crack ASGS, he'll be able to both get and set other people's input maps on the remote server. I think this is a minor matter, since the possible ASGS hacker will probably have own wider variety of destructive tools to annoy the community.

Only if there's some magic secret ASGS passes to Alleg for the purpose of storing the inputmap file. But if I read the code correctly, it's just using an obfuscated version of the callsign. No ASGS hacking is required to get/set anyone's input maps.

QUOTE (Zruty @ Aug 23 2010, 08:56 PM) 2. If someone is able to replace the remotely-stored version of the input map with another file, not necessarily an input map (for example, a trojan or a virus), it will be downloaded onto the target user's machine (I'm not sure if the file is deleted/replaced afterwards). Usually such malware requires user interaction to start working (i.e. run the file).

Thanks for pointing this out, in my previous post I completely overlooked the possibility for attackers to change some else's input map.
The input map is downloaded only if the user presses the 'Load' button, so there's no way to mess up an existing Alleg installation - it's only a problem for people who use the feature (which they'll only do on new installations).
Replacing the input map with a *.exe virus/trojan would probably just crash Alleg (due to invalid input map) but not run the virus. However, if there's an additional security vulnerability (buffer overflow) in the input map loading code -- quite likely as it's MS code from pre-2000 -- then such a virus might run without user interaction.

QUOTE (Zruty @ Aug 23 2010, 08:56 PM) 3. If the 'cloud' server logs the network traffic, the information of how IP is bound to the callsign (or its hash) will be available to the cloud server owner.

Yes, but the same holds for the ASGS and game servers. Still, the number of servers that production alleg depends on should be only the minimum that's absolutely necessary.

So my point of view: Imago's current approach is unsafe. To do this correctly, the input map would have to be stored with the ASGS account, so that uploading/downloading the input map would be possible only after authenticating. Which isn't going to happen as I doubt TE will touch ASGS for such a low-priority feature.

[Zruty]

pkk, I don't want to sound like a paranoid, or to blame Imagg/whoever for intending evil. All I wanted is to make things easier to those who did NOT read the source.

True, there's nothing new about the fact that the server owner may do all sort of bad things to us. The only difference is that formerly it was the AllSrv/ASGS server owner (i.e. Tigereye), and now it's also the 'cloud' server ( http://services.nirvanix.com/1-Planet/C70595-1/ ) owner as well.

[Clay_Pigeon]

This whole thing is a solution in search of a problem. Honestly, how many people hop from computer to computer with their Alleg account (knowing that ASGS remembers each machine you use). If we go ahead with implementation, I would rather do it "correctly" via Alleg-only CSS than as a bolt-on with a 3rd party service which may change over time.

[Zruty]

QUOTE (CharlieTester @ Aug 23 2010, 11:09 PM) "(I'm not sure if the file is deleted/replaced afterwards)."


then you DIDNT take the time to read and UNDERSTAND the source because you would see the DeleteFile() calls, dip@#(!.

Thank you for your timely and helpful contribution!

Obviously, you meant this code?

Code: Select all

LoadMap(INPUTMAP_FILE+ZString("_cloud"));
DeleteFile(GetModeler()->GetArtPath() + "/"+INPUTMAP_FILE+"_cloud.mdl");

What happens if LoadMap() fails? Does the file stay on the HDD, or does it get deleted? I didn't delve into LoadMap() (as I also didn't delve into Extract7z(), which is used in a similar manner), so I can't say. I AM NOT SURE.

2 Clay: That's my original point, thanks for articulating it

[fuzzylunkin1]

QUOTE (Clay_Pigeon @ Aug 23 2010, 02:33 PM) a 3rd party service which may change over time.

It will change soon if you ungrateful $#@!s keep complaining about it.