Ulysses
Ulysses Stuff => General Chat & Help and Support => Topic started by: GoodNewsEveryone on February 28, 2011, 02:38:25 AM
-
Hey guys.
My server, running the SVN version of ULX has become under attack. I am a superadmin and when I connect, after 1 minute, I get dc'd and multiple people are slayed, kicked or banned.
This is a Trouble in Terrorist Town server.
Please help.
Thanks
Good News Everyone
Owner of Mind Blast TTT
-
What makes you think that ULX is the cause of this? Have you checked the ULX logs? Do you have a weak or exposed rcon password?
-
And just to clarify, stating "because when I remove ULX it doesn't happen" isn't a good reason.
We've seen many other mods use poorly written code that allows non-admins to run rcon commands, including the ULX ones.
We're not saying it's not possible that ULX isn't a contributing factor, but without the evidence and logs and errors and MUCH more information, its as likely to be another mod or the TTT gamemode version you're running as it is ULX.
-
Well.
I have checked the logs.I have had a chat with my friends and they seem to think that it's either a Source exploit or something to do with ULX. I have a strong RCON password. I'm not blaming people here, and I think ULX and ULib are really good addons.
Here's a snapshot from my logs:
I timeout before all of this.
L 02/28/2011 - 20:25:29: [ULX] Good News Everyone [M.B] (Me) slayed Themself,-Shish,=Kol= Homertime,DuckThatSits,Matthew,No Fat Cunts,Rumo,Shade [M.B],Sparky,The A.N.B.U Of Black OP,The Tech Wizard(Huey),[ImmortalityGAMING] PrøA†hle,bob 3.0,te-KILL-ya
L 02/28/2011 - 20:25:30: Round ended.
L 02/28/2011 - 20:25:30: Result: traitors win.L 02/28/2011 - 20:25:37: "Good News Everyone [M.B]<><><>" disconnected (reason "Disconnect by user.")
It has stopped for the moment, but it might continue tonight.
-
So it appears in the logs that you're doing all of this? Your client has timed out but the server still thinks you're connected? Does this security problem always happen when your client times out but the server still has you marked as connected?
We're not saying that you blame us, it's just far more likely to be something besides ULX. It's certainly possible it's ULX, though!
-
I may be able to confirm this, although I didn't see it first hand, unfortunately.
I had 3 admins connected to the server, only one admin was high enough to change maps.
He claims his admin menu was positively not open at the time (and I assured him I would not be mad even if he purposely changed the map), when the map changed.
The log shows that he changed the map to a CS:S map, which are not even on his map change list (i deactivated them all) as a dogfight arcade gamemode. The server isnt set up for fretta, so no one was able to do anything once they re joined. the map was then quickly changed again to a different CS:S map, and this time it didn't list anyone in particular as changing it.
I've seen a lot of things done with wire's e2 that were thought impossible in the past, perhaps that has something to do with it?
[17:05:45] ? jebus night hunter ? changed the map to arena_badlands with gamemode dogfightarcade
[17:05:45] Server is shutting down/changing levels.
[17:06:08] New map: arena_badlands
[17:06:19] Client "? jebus night hunter ?" connected (xx.xxx.xxx.xxx).
[17:06:32] Client "??y?h?? m??k?y" spawned in server (xx.xxx.xxx.xxx)<STEAM_0:1:15595126>.
[17:06:50] Client "Logan42" spawned in server (xx.xxx.xxx.xxx)<STEAM_0:1:35871631>.
[17:07:21] ??y?h?? m??k?y: me neither lol
[17:07:27] Client "? jebus night hunter ?" connected (xx.xxx.xxx.xxx).
[17:07:38] Client "gmod lover" connected (xx.xxx.xxx.xxx).
[17:09:08] ??y?h?? m??k?y: :\
[17:09:24] ??y?h?? m??k?y: ugh lol
[17:09:51] Client "Bweihsification" connected (xx.xxx.xxx.xxx).
[17:10:01] Dropped "??y?h?? m??k?y" from server
[17:10:03] Logan42 suicided!
[17:10:03] Server is shutting down/changing levels.
[17:10:40] New map: de_inferno
-
Was night hunter the one that was supposed to have access?
-
Yes sorry I didn't specify.
The others are only allowed to create votes for maps.
I wish this would have happend to me so that I can report with 100% certainty.
I changed my rcon password as a good measure
-
I am also having a problem like this, i timeout from my server and then one of my friends that is in the game says that console has banned me and added some random person that i don't know to superadmin.
Also i have disabled rcon so it must be ulx.
-
Folks, please don't just come and post 'me too'.
Please notify us what version or revision of ULX you're running. (Debuginfo mentioned in next few steps will provide this too)
Notify us what gamemodes you were running, and have installed.
Please attach your logs, at least the portion of when the person joined, and when the incident occurred.
Also, attach the file created from a 'ulx debuginfo', preferably when the incident occurred, but as soon as possible.
(Please 'attach' the files using the 'Attachments and Other options' link at the base of a reply window, this will save screen space)
Other team members may ask for other information, but simply coming here and stating 'it happened to me too' will not help us find where/what or how.
Again, this may not be ULX, it may be another mod open exploit using ULX. (Yes, then again, it could be ULX only, but still, this needs to be determined. Debuginfo (and anything else Stickly/Megiddo ask for) may help us determine this.
-
I am running Trouble in terrorist town with ulx svn.
And in my last post i meant to say that it shows me adding him, anyway here is part of the log
[17:30:12] AussieGamers | iSnipeu [M.B] added Bonkes to group superadmin
[17:30:18] (TEAM) UnForSaken: hi
[17:30:33] (TEAM) [A.G] Jason: ahh yes, bonkes
[17:30:46] (TEAM) Bonkes: just testing something
[17:30:51] (TEAM) Bonkes: /kick Bonkes
[17:30:52] Tango x3: D:D!?
[17:30:53] Gamerooner (high authority): mark it
[17:30:57] Dropped "AussieGamers | iSnipeu [M.B]" from server
[17:30:58] (TEAM) [A.G] Jason: i know, youve done it before
[17:30:59] (TEAM) Bonkes: !kick bonks
[17:31:02] Dropped "Bonkes" from server
I have disabled rcon so i can't get the debug info right now, will get it when few players are on.
-
I may be able to confirm this
Krooks, were you running TTT at the time?
-
Thanks for the log iSnipeu, it's very helpful. One important matter, however: how do you time out? Is it as if the server suddenly died, and you see the timeout countdown in the top right corner of your screen saying that the server isn't responding? Or does your client freeze?
Everyone, I'd recommend taking extra precaution with your servers until we know more about this. I still don't believe that ULX is the root cause here, but certainly ULX is making it easier to wreak havoc on the server. I recommend disabling the use of "ulx adduser*", "ulx userallow*", "ulx luarun", and "ulx rcon" to your admins so that these hackers can't add themselves as a superadmin. This can be done with the following commands in console:
ulx groupdeny superadmin "ulx adduser"
ulx groupdeny superadmin "ulx adduserid"
ulx groupdeny superadmin "ulx userallow"
ulx groupdeny superadmin "ulx userallowid"
ulx groupdeny superadmin "ulx luarun"
ulx groupdeny superadmin "ulx rcon"
-
Well what happens is that the auto-disconnect will come up in the corner and i can't move, but if i right click on the server to view server info, it is still working and it says that i am still on but i am still timing out and get disconnected.
-
Krooks, were you running TTT at the time?
no, sandbox.
Do you want a full log from the day?
current addons:
ULX/ULIB (svn)
Wiremod (svn)
Wire model pack (svn)
Advdup (svn)
URestrict (svn)
sui scoreboard
weightstool
Parachute
Para-deploy
uclip
ChatBubbles
Advanced sleep n wake
AntiAFK
Buoyancy Tool
Chat Gestures
DoorSTool
SimpleKeys
Easy Precision
Falco Prop Protection
GMPaint
keypad
Unbreakable
VehicleControl
********edit*********
Doing some research, it looks as if garrys mod has had issues with spoofed admin ID's in the past:
sept. 7 2010
Garry's Mod Updates:
Added protection from spoofed Admin SteamID’s
-
I can confirm this. It's happened to at least another two AUSTRALIAN gmod community servers (other than the OP's), including ours. I suspect this is a zero-day exploit.
The facts:
-Admins' accounts, rcon password, or physical server has *not* been compromised.
-ULX Log files indicate that admins are executing commands
----- Sometimes: into chat (i.e. "!slay *")
----- This chat isn't logged in the normal gmod log file.
-Admins are *not* executing these commands themselves (i.e. they're not rogue).
-Whenever 'this' occurs, admins/clients receive huge choke and some (the admins, and possibly others?) lose connection to the server. Most (all?) of the other players stay connected.
Correlations
-At least 2 out of the 3 servers being attacked are using the SVN version of ULX. I wasn't able to contact the other.
Related events
-The MOTD (ulx's?) is being *temporarily* changed to be porn-like for *some* users, but the actual MOTD files (ulx_motd.txt/htm) are not being changed.
--- this occurs around the same time as the huge choke/lag.
We're running the the latest stable version of TTT. I'll post the 'ulx debuginfo' output later.
This needs to be solved ASAP.
-
Read my post here:
http://www.facepunch.com/threads/1066753-Very-serious-exploit-hack-currently.?p=28453640#post28453640
This isn't actually directly ULX fault. But he person selling these exploit/hacks are selling it in levels. The cheapest of which just runs "ulx adduser name superadmin" on player just before using a DoS on that player.
-
Mmm, yeah. I think I was experiencing this on another server I'm admin on. We ended up tracing down who the player was and banned him. Although, this server does not use ULX, it still sounds very familiar to what he was doing.
EDIT: I'm not sure if he was able to make himself Super or not.
-
Wow thanks for the insight, I'll be disabling voice chat in the meantime!
-
Figured it didn't have anything to do with ULX, but you can protect yourself from permanent damage by running the commands listed on the previous page. Or does disabling voice chat protect everyone entirely?
-
So it basically works by DoSing an admin (i won't explain exactly how they got their IP, but just via voice chat) and then spoofing themselves as the admin they DoS'd?
I suppose if admins didnt use voice chat, it could also work as a temporary fix?
Figured it didn't have anything to do with ULX, but you can protect yourself from permanent damage by running the commands listed on the previous page. Or does disabling voice chat protect everyone entirely?
That wouldn't really do much, other than stopping themselves from adding them as admin and such. They can still spoof themselves as an admin and do whatever. I suppose this isnt really an ULX issue then.
-
You seem to misunderstand.
It's not done via ingame voice chat.
It is done via STEAM Friends voice chat. They can start a call with you, even if they are not on your friends list. To get a victims IP you do not need to be in a game with them, or vis versa.
They do need to be ingame with you to spoof the packets however.
-
t I can tell of this discussion and the one on Facepunch (which, only has about 4 relevant posts of discussion as of this comment), yes, it is a DDOS, which then uses any admin mod, ULX or not, to then do evil bidding.
I wonder, just theoretically, that most of the affected servers are in AU because the primary (not necessarily only) person causing trouble is in AU.
I'd imagine that attacking non-AU servers, from AU, using a DDOS across a longer route and transatlantic cables would cause a high enough latency that being successful with the DDOS would be more challenging.
-
You seem to misunderstand.
It's not done via ingame voice chat.
It is done via STEAM Friends voice chat. They can start a call with you, even if they are not on your friends list. To get a victims IP you do not need to be in a game with them, or vis versa.
They do need to be ingame with you to spoof the packets however.
Ah, that makes much more sense. So then valve is simply relying on users not knowing other users' IPs in order to not spoof their traffic. And to stop the original client from interfering, it's DDoS'd. Honestly not sure what valve can do to stop this without adding a ton of overhead to their protocol...
-
Disable voice option?
Not giving your IP unless you answer the call would be a start.
-
Disable voice option?
Not giving your IP unless you answer the call would be a start.
Ah, didn't realize it was quite that bad. That would definitely be a good start. :)
-
In ULib rev 184 I added a security feature that stops this exploit from working on ULX, assuming the exploit works the way I think it does. You all will have to let me know if an admin mysteriously times out and another player in the server starts cursing. ;)
Thanks to Stickly Man for the inspiration that led to this.
Technical details:
When a player joins the server, the server generates a random number for the player and hands it off the player. The player must then pass this secret number back to the server every time they execute a command that is registered through ULib. If the player hands off the wrong secret then their command is ignored. In a packet spoof attack, the attacker won't know what this secret is and won't be able to execute the command.
-
Good job! In general, that just sounds like a great preventative even if thats not actually whats going on in this whole mystery.
-
Oh wow. I never realised the exploit was that easy to be abused.
I had 4 players on my TTT server this morning (02:00 - 04:00GMT) abusing the heck out of the server.
They had got access to Sourcemod Admin, and were kicking,banning,slaying,map changing, cvar changing and also got the rcon password.
They also somehow got access to the Sourcebans login and deleted 2 Admins before they banned them from my servers.
Mind you I got no idea how they got the sourcebans login info, as only 2 Admins can delete other Admins.
Myself and another player I trust with that right, we were both online, but neither of us were ingame (I had woke up to find the trouble going on)
So until valve fixes this exploit *cough*, I take it my best bet would be to switch to ULX since it has some sort of protection against this problem?
As at the moment all 3 GMOD servers run Sourcemod and 2 of them run Evolve.
As both my Fretta and TTT servers are quite popular, and I need to have something to deal with any silly players, while keeping it easy for Admins and trouble free for my requlars.
I shall give ULX a try and let you know if things work well.
*If you hear a lot of shouting from the UK it's just me telling my Admins to shut up and deal with a different Admin addon :P
-
In ULib rev 184 I added a security feature that stops this exploit from working on ULX, assuming the exploit works the way I think it does. You all will have to let me know if an admin mysteriously times out and another player in the server starts cursing. ;)
Thanks to Stickly Man for the inspiration that led to this.
Technical details:
When a player joins the server, the server generates a random number for the player and hands it off the player. The player must then pass this secret number back to the server every time they execute a command that is registered through ULib. If the player hands off the wrong secret then their command is ignored. In a packet spoof attack, the attacker won't know what this secret is and won't be able to execute the command.
CURSE YOU!
You're sadly awesome, now I have to update my ULX for the first time in forever and remake all my edits. Like adding Lexi's Sourceban functions to ban etc.
But it is worth it for the fix, I'll update our servers asap -
-
Got it installed on my 3 servers now.
Only "used" it on my TTT server and I do have one little problem.
On map change I have to re-connect for ULX to work for me.
If I try to use any ULX commands or change any settings it does not do the commands or change settings.
However if I re-connect then it works fine.
-
NaRyan, even though it works fine for me I had forgotten about the really annoying bug of utter mystery (http://forums.ulyssesmod.net/index.php/topic,3363.msg22112.html#msg22112), sorry about that. I'll be switching over the data transmission to another method shortly, so let me know if it fixes it for you.
Edit: Changed in ULib rev 185. Be sure to let me know if this fixes it for you NaRyan, as I have never been able to replicate this problem on my test server.
-
Ahh cool thanks :)
I'll let you know how it goes once I get a chance to update my servers....
*edit*
I tested it on my sandbox server, and after changing map I was still able to change settings and use Admin commands.
-
CURSE YOU!
You're sadly awesome
Most interesting complement I've heard in a while.
Kudos!
We hope the changes made help in overall anti-exploitation, but, as this is a Source issue..those abusing it may know other ways around using ULX.
-
Ok so people on the FP thread are suggesting that we disable rcon, I'd rather not ask there how to go about doing that (for obvious reasons), anyone here know how to completely disable rcon?
-
Ok so people on the FP thread are suggesting that we disable rcon, I'd rather not ask there how to go about doing that (for obvious reasons), anyone here know how to completely disable rcon?
Many ways, disable the port, set it to no password.
Not really sure why you would disable Rcon, I mean long as your not silly enough to set it inside a config and use command line.
I don't think there are many exploits that directly get rcon like there suggesting. Just make your rcon something long and obscure ;) I normally go for #randomwords@841235#smells@ etc ;)
-
ah ok, thanks for the information, I'll just go TheL0ngPassw0rdR0ut@! :P
also by not setting in a config, do you mean not to have it in server.cfg? Then where should it go?
I don't and have never used rcon, so I'm very nooby about it.
-
not to have it in server.cfg? Then where should it go?
If you're going to enable it (by setting a password instead of rcon_password "" (which disables it)), you use a command line option in server startup.
I forget if you use a plus (+rcon_password) or minus (-rcon_password), but many Source exploits ago, it was recommended the command line option be used.
-
ah ha, thanks again guys!
-
It's +rcon_password
-
I updated Ulib on my 3 servers, and ULX commands now work fine after gamemode\map change :)
-
I updated Ulib on my 3 servers, and ULX commands now work fine after gamemode\map change :)
Thanks, NaRyan!
-
If you're going to enable it (by setting a password instead of rcon_password "" (which disables it)), you use a command line option in server startup.
I forget if you use a plus (+rcon_password) or minus (-rcon_password), but many Source exploits ago, it was recommended the command line option be used.
Not as long as you think.
The exploit got a refresh recently, still private. Might be patched again I've no idea.
But, here was a new download exploit around 1 month ago.
-
Ugh, not another download exploit..
Now that I look at it, I still have my sv_allowupload/download settings at 0, from the last time :P
-
There appears to be some variation of this exploit floating about... similiar things are happening again
admin timesout --> admin rejoins --> ulx command is spoofed
I'm not entirely sure how this is working now that the server + client share a secret key, but i want to emphasise that this occurs when the admin rejoins and not while the admin is dc/d (like in the original variation of this exploit).
-
In theory- I imagine that the same Source exploit is being used. Now however, because the exploiter can no longer spoof the admin themselves, they now have to use/run a lua command on the admin rejoining that either 1) Show's ULX's key given to them or 2) just has the admin run the command for them.
Remember, the original exploit was never about ULX, it was direct access to exploitees client console through a Source exploit.
Admin mods (ULX included) just made it easier for them just like it makes it easier for you to administer a server.
Are you still using Voice in Steam and Source games? If so, by all means disable it and see if it stops.
-
Unfortunately, we discovered that the exploit is now working in such a way that it can't be blocked by Lua. The protection we added before was aimed at a very particular way that we assumed the exploit might work, and it's clear it doesn't work that way anymore.
I still recommend following the commands I gave a few pages back. You can't stop the exploiters, but perhaps you can minimize damage. Another note of concern is that I don't think that the attacker needs to be connected to a server in order to attack it.
-
In theory- I imagine that the same Source exploit is being used. Now however, because the exploiter can no longer spoof the admin themselves, they now have to use/run a lua command on the admin rejoining that either 1) Show's ULX's key given to them or 2) just has the admin run the command for them.
Yeah i figured it was much the same
Remember, the original exploit was never about ULX, it was direct access to exploitees client console through a Source exploit.
Admin mods (ULX included) just made it easier for them just like it makes it easier for you to administer a server.
Exactly. Although it's not really an exploit per se, i'd call it more of an attack vector.
Are you still using Voice in Steam and Source games? If so, by all means disable it and see if it stops.
We originally stopped using voice in game, but after we discovered it was done via steam friends, we stopped bothering. We did figure out a temporary solution; that is to not reconnect after timing out, but yeah.
Unfortunately, we discovered that the exploit is now working in such a way that it can't be blocked by Lua. The protection we added before was aimed at a very particular way that we assumed the exploit might work, and it's clear it doesn't work that way anymore.
Can you explain exactly how it's working (either on here or privately?). We have a pro coder on our team, and we might be able to block it outside of gmod/lua depending on how it works.
I still recommend following the commands I gave a few pages back. You can't stop the exploiters, but perhaps you can minimize damage. Another note of concern is that I don't think that the attacker needs to be connected to a server in order to attack it.
We might end up having to do that. What we discovered was, that attacker actually connects with a (legit) steam attack (i.e. we have their real steam id), although they can still spoof/proxy their connecting ip address.
Thanks
-
When this exploit first came out we had 2 people try it on us, but, we have connections to a steam mod, and after showing them logs, those people were vac banned. Since then, we have seen _many_ people vac banned for this exploit, and the fact that we have not had another attack since, tells me the word has gotten out within that community.
Hacks cost you (or in their case, their parents) MONEY! LOL
-
The nonce method was good except for the fact that attackers can execute Lua on the client. A more foolproof method is to have an after the fact challenge, such that:
A client will send a command to the server normally like "my admin command kick xyz." The server will buffer the command and challenge the client (with something random), and the client must send the challenge back to the server without storing it. This way it doesn't matter what the attacker can run on the client because they would have to get the challenge after their command has been injected. Because of the way the attack works (desynchronization of the net channel), the client could never get the challenge regardless of anything they do to the lua state.
-
I'm not ignoring this thread, but I'm going to take some time to consult my network security books before making further comments. I've got three tests this week though, so I'll likely get to it this weekend. Thanks for the input, though!
-
Meh, I'll bite.
First, Welcome, and nice to see you here AzuiSleet.
Second, It's a good idea in theory. It would prevent abuse of ULX, if not all other client capable console commands (lua or not)
As discussed (overly perhaps) in the FP thread, it would stop the general 'script kiddy' type folks who simply run the simple stuff, and are unfamiliar or have patience for higher console learning (or lower, as the case may be when it comes to abuse)
I question efficiency though.
Many SVN revisions ago, after the major rewrite of ULib in the rev 70+ era, we tried using datastream for all of our commands.
What a mess that was. If the datastream hooks weren't stopped by some lame poorly written other mod using them, or Gmod's implementation itself placing them out of order or some such, then it was delayed many seconds due to various mods and other net server traffic flooding the channel.
(See http://forums.ulyssesmod.net/index.php/topic,4432.msg18093.html)
We want ULX commands to seem instantaneous.
Figuring the most reliable while fastest method of challenge dialogue may be more challenging than it seems.
-
I agree that, assuming there is a noticeable performance difference (especially on laggy servers), a delay can be pretty annoying. I did come up with a (somewhat complex) idea that may help with the problem:
If you think about it statistically, I'm guessing that well over 95% of commands that will go through this challenge process will pass. What would happen if we were to buffer the command like AzuiSleet mentions, but instead of waiting for the response from the client, go ahead and execute the command immediately? Then, after a specified amount of time, if no response from the client is received, "undo" the command.
This method obviously would require specific parameters on a per-command basis, like so:
For commands with opposites (ragdoll, jail, ignite), this causes no issues, and a fake command against another player would result in being ragdolled only for a second (or however long the wait time is).
For commands that change a state of a player (hp, armor, teleport, bring), we'd need to save the old parameters in order to properly "undo" the command.
For non-opposite commands (slap, whip, maul, asay, csay, thetime), perhaps they could be executed immediately, then a warning message can be displayed to all once ULX doesn't receive the challenge?
For non-important commands (in terms of it not really making a large difference on if it's executed a few seconds late), we can just leave these alone to wait for the challenge. (vote, votekick, voteban, votemap)
And for the most important commands (rcon, luarun, any user management commands), these should all wait for the challenge response. (User management commands could probably be undone, but it's better not to risk it).
Or, you know, we could just enable the challenge on only the most important of commands, then ignore it on the rest.
Handling logging on a method like this may be tricky, too
-
Remember our motto Stickly Man... strive for simplicity.
(I know, you've already shot that out of the water with all the gui code, but, at least it counterbalances with making it simple for prefer-a-gui users)
-
When you say "dialogue" it seems to me that you are suggesting a prompt for the user. The requirement for the challenge I'm suggesting doesn't have to be a confirmation dialog, just a simple usermessage challenge/concommand response. I don't really see the delay being much worse than RTT (500ms if your ping is 250ms), which isn't that big of an issue if say you want to kick someone, since you spent the last 5 seconds clicking or typing the kick button/command.
-
Sorry, no, didn't mean user prompted. I understood your idea (and like it).
Just meant the back-end communication dialog between server and client.
My concern still lies in that buffer time, especially if there is already some sort of response lag for any reason on the server or client.
I send command now, along with our current 'key' method, server sees it and goes 'OK'.
Even if delayed in any way to the server, as long as it reaches the server, the server will execute it as soon as it can.
With the challenge method you suggest, it triples (or more perhaps in some instances) that time, whatever it may be.
If delayed for any reason, that delay gets tripled too.
I'm not disagreeing with safety of the idea. It secures the command structure of ULX.
This additional time difference, and the additional buffer code/timeout complexity may outweigh the need for it.
At least, to be included within ULX by default.
Now that I reach that final statement, this sounds like a good module release idea for ULib itself, if not ULX.
ULib has a few functions that could halt and check for additional authorization before allowing commands to continue.
-
With the challenge method you suggest, it triples (or more perhaps in some instances) that time, whatever it may be.
If delayed for any reason, that delay gets tripled too.
I don't see how it's triple the normal time, since you have to wait for the command to be transmitted, and then wait for feedback, whether it's the user being kicked or an "OK" message, that's the RTT. The second trip for the challenge is the RTT again, which means there's two trips, so it would only take twice as long plus any network congestion.
-
Maybe I'm confused.
Here's how I see it;
1) Original command to server - server buffers,
2) sends random as of that moment challenge back to client.
3) (Real) client back to server - yes, I'm real, see my (server sent key)...perform buffered command now please.
There are 3 trips there, all of which can be affected by various lag (network both ways, server i/o, client i/o)
Or am I totally getting your original idea incorrect? (I'm quite sure this is possible :) )
-
You're missing the return trip, in the normal case:
1) ->server, string command
2) ->client, feedback
In the case of the challenge we're still using that return trip, it's just not the feedback:
1) ->server, string command
2) ->client, challenge
3) ->server, challenge response
4) ->client, feedback
It only takes twice as long to get the same feedback, since it's not useful to measure the time it takes to go to the other end, but rather the time it takes for the other end to respond. I interpreted your concern as "response lag" not the actual time it executes on the server, which would be 3x as long.
Even in a case like a 250ms ping, that's 500ms to get a response, which is still within reason, and a delay of 375ms to execute the command. If the delay really is unacceptable, I suppose it wouldn't be unreasonable to make it an opt-in feature, but that does go against the principle of "security should be opt-out."
-
Having a interesting chat with my host today, he send me a link to a facepunch thread, i will post the link & test below
http://www.facepunch.com/threads/1066753-Very-serious-exploit-hack-currently.
So, before you read this and say it's impossible there are several server owners who will have already experienced this.
How does the hack work:
All I know:
Attacker users steam to get the IP (Steam voice chat)
Attacker can now run any command on him. Logs will show the command came from the victims IP.
I was told, although I have no idea if reliable, that the attacker & victim have to be in the same server. Now this makes me think the attack could be a multitude of things. A friend or 2 believes it could be some form of packet injection, however this seems unlikely.
What does the hack involve:
Well, basically there are a few levels of the hack that someone is selling. Level 1 just gives you superadmin(ULX only), the highest level will allow the user to run any console command on that user.
The attacker just needs to obtain a victims IP and then they are allowed to run any console command on the victim, and I do mean any even the ones safeguarded by Valve. To make things worse, the person selling these tools also provides a simple DoS to knock offline the person there attacking.
Example:
(George = superadmin/owner)
Attacker1 makes George give him superadmin
Attacker1 attacks George and knocks his internet offline for a few hours.
Well, just read through this and I sound like a complete moron. But alas I'm to tired, I'm only posting this here to see who else has been victim of this & to bring it to Garry's attention.
-
Hi Snipe, perhaps previous discussion here didn't make it clear, or it is perhaps you're just tired.
The scenarios you spell out are what we've discussed, and have made it more difficult, at least for those "ULX" combo exploits, to be used in combination. (Must have SVN of ULib and ULX)
Pantho originally posted the same Facepunch thread you point to on page 2 of this thread.
http://forums.ulyssesmod.net/index.php/topic,5205.msg22847.html#msg22847
Additionally, Garry can't fix it (at least, not without rewriting the Source voice engine).
It's a Source engine exploitation, not Gmod itself.
Get some sleep. :)