I'm not asking for any code, but rather some general advice.
If for example, any player could control some ingame 3D2D web screen to go to custom web addresses, what is the worst that could happen, and how?
I know that you can use javascript to run clientside lua, but I thought that was only when explicitly allowing it to the panel.
Is the ingame awesomium browser cabable of causing any actual harm to players?
You can always run the RCON exploit that bans players for invalid attempts. That's the first on that comes to mind.
Right now I don't think there is, but you never know, there are some pretty intelligent people out there, if you were to make something like that, it's only a matter of time before someone manages to exploit with it.
[QUOTE=Revenge282;46914276]You can always run the RCON exploit that bans players for invalid attempts. That's the first on that comes to mind.[/QUOTE]
What are you talking about?
[editline]12th January 2015[/editline]
If you mean that HTML content can run lua to run console commands, I already addressed that. Unless there's some way to run lua even with it supposedly not enabled on that panel?
There's probably more vulnerability in flash / viewing pdfs ( can you even do that with the element? ) than visiting a given site, although illegal/disturbing stuff comes to mind, as well loading pages that specifically just bog down the pc, and other jerk things.
there are websites that just have 50 iframes that try to load server ips, the iframes get counted as rcon log in attempts, and you get automatically banned from that server
Would it be effective to grab the source of a proposed web page load, and strip out all code elements such as pdf, flash, java, and javascript? Iframes too, so there isn't any working around it.
It sounds like it would be very handy to have a function called on all web panels after the source is acquired, before the source is ran, with the source as an argument and as the return.
[QUOTE=bitches;46915462]Would it be effective to grab the source of a proposed web page load, and strip out all code elements such as pdf, flash, java, and javascript? Iframes too, so there isn't any working around it.
It sounds like it would be very handy to have a function called on all web panels after the source is acquired, before the source is ran, with the source as an argument and as the return.[/QUOTE]
[url]http://wiki.garrysmod.com/page/http/Fetch[/url] ??
Depends what you're doing I guess?
I think what you're doing is letting players set a url on something that is shared to other players?
The most likely thing to cause any issue is the rcon exploit as mentioned, but a simple fix for that would be to whitelist your rcon ports at the firewall so that only you can access them.
If the url never gets used by the server, there's no real risk I can think of.
Just make sure your client inputs that affect the server are validated server side.
[QUOTE=Blasteh;46945375]Depends what you're doing I guess?
The most likely thing to cause any issue is the rcon exploit as mentioned, but a simple fix for that would be to whitelist your rcon ports at the firewall so that only you can access them.
[/QUOTE]
Or even better:
sv_rcon_banpenalty
sv_rcon_maxfailures
sv_rcon_minfailures
sv_rcon_minfailuretime
[QUOTE=Hafnium;46946585]Or even better:
sv_rcon_banpenalty
sv_rcon_maxfailures
sv_rcon_minfailures
sv_rcon_minfailuretime[/QUOTE]
I don't see how that's better. Making rcon localhost only is a lot better security wise than removing the limitations that exist for a reason.
[QUOTE=Wyozi;46947450]I don't see how that's better. Making rcon localhost only is a lot better security wise than removing the limitations that exist for a reason.[/QUOTE]
eh... I know its a stupid question and sorry for derailing the thread, but how do I make RCon localhost only?
[QUOTE=GGG KILLER;46949042]eh... I know its a stupid question and sorry for derailing the thread, but how do I make RCon localhost only?[/QUOTE]
My webhosting plan recently expired, so I have to host my documentation on this exploit on my Dropbox now, but [URL="http://rhapsody.droppages.com/"]here it is[/URL]. This documentation contains extensive information as to what the exploit is as well as a few ways to block it from working.
[QUOTE=WitheredPyre;46949737]My webhosting plan recently expired, so I have to host my documentation on this exploit on my Dropbox now, but [URL="http://rhapsody.droppages.com/"]here it is[/URL]. This documentation contains extensive information as to what the exploit is as well as a few ways to block it from working.[/QUOTE]
Thanks, that really helped me alot!(would also be nice if you could fix the link to the picture of the firewall configuration to restrict IPs)
[QUOTE=GGG KILLER;46949839]Thanks, that really helped me alot!(would also be nice if you could fix the link to the picture of the firewall configuration to restrict IPs)[/QUOTE]
I don't have that mirrored anymore and I don't have a service with NFO anymore, so I can't. You can ask them what you need to do to block RCON from outside sources, though. That's what I did.
[QUOTE=WitheredPyre;46949737]My webhosting plan recently expired, so I have to host my documentation on this exploit on my Dropbox now, but [URL="http://rhapsody.droppages.com/"]here it is[/URL]. This documentation contains extensive information as to what the exploit is as well as a few ways to block it from working.[/QUOTE]
"Source Query Exploit Documentation"
I think you have the name mixed up, isn't that widely used to refer to the DoS exploits involving [URL="https://developer.valvesoftware.com/wiki/Server_queries"]source queries[/URL]?
[QUOTE=WitheredPyre;46949737]My webhosting plan recently expired, so I have to host my documentation on this exploit on my Dropbox now, but [URL="http://rhapsody.droppages.com/"]here it is[/URL]. This documentation contains extensive information as to what the exploit is as well as a few ways to block it from working.[/QUOTE]
You still haven't updated that document since I last pointed something out.
[QUOTE=mcd1992;46693041]A lot of that writeup is incorrect though. The min/max values for sv_rcon_banpenalty, sv_rcon_maxfailures, and sv_rcon_minfailures disallow fully disabling rcon bans. Rate limiting TCP on the game port wont fix the issue as it only needs to send one large amount of data, once, to trigger the ban. Blocking rcon traffic from non-whitelisted IPs at the firewall is a good fix. And disabling rcon is not a bulletproof fix as even with rcon_password set to "" clients still get banned for large rcon packets.
sv_rcon_maxpacketbans 0 works just fine though. That is only for the simple [URL]http://serverip:27015[/URL] iframes though. It might still be possible to spoof the source on packets, depending on if the engine checks the TCP state or not.[/QUOTE]
Literally just set sv_rcon_maxpacketbans to 0 and the iframe exploit is 'fixed'.
[QUOTE=mcd1992;46955087]Literally just set sv_rcon_maxpacketbans to 0 and the iframe exploit is 'fixed'.[/QUOTE]
wouldn't this just allow forcebruting of your rcon
[QUOTE=MeepDarknessM;46955169]wouldn't this just allow [B]forcebruting[/B] of your rcon[/QUOTE]
bruteforcing*
sv_rcon_maxpacketbans - Ban IPs for sending RCON packets exceeding the value specified in sv_rcon_maxpacketsize
No, it only prevents banning of clients for sending too large of a packet to the RCON port. Which is what the iframe exploit is doing. Its banning the player for sending all the GET / HTTP/1.1 blahblah data to the RCON port.
[QUOTE=mcd1992;46955470]sv_rcon_maxpacketbans - Ban IPs for sending RCON packets exceeding the value specified in sv_rcon_maxpacketsize
No, it only prevents banning of clients for sending too large of a packet to the RCON port. Which is what the iframe exploit is doing. Its banning the player for sending all the GET / HTTP/1.1 blahblah data to the RCON port.[/QUOTE]
I've had some experience erm.. documenting the bug, and you have to send the rcon request five times for the ban to happen. I don't think packet size has anything to do with it, especially because default HTTP header isn't that big.
Sorry, you need to Log In to post a reply to this thread.
