MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002838Zandronum[All Projects] Bugpublic2016-09-19 20:082018-09-30 21:49
ReporterUnknown 
Assigned ToTorr Samaho 
PriorityhighSeverityexploitReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version2.1 
Target Version3.0Fixed in Version3.0 
Summary0002838: sv_maxclientsperip and Votes .
DescriptionVotes in Zandronum have been most time unfair, I'd like to report this issue so Maybe you can fix it, Apparently on servers that have high sv_maxclientsperip Value it is possible to increase success rate of your vote if you just join Multiple times at same time, This means it can be easily used to "Troll" and initiate votekicks and successfully votekick players even if they vote "no" .

I Suggest refusing votes from same IP, This would make the voting system fair .
Steps To Reproduce1 - Join a Server Multiple times and initiate a votekick against someone or a votemap using one of the running game processes .
2 - Vote yes from Every process .
3 - Success ?
Additional Information
TagsNo tags attached.
Relationships
related to 0002590closed  A little addition to vote success/fail condition 
related to 0002801closed  Votekicks can be avoided by disconnecting, thus resulting in not getting banned. 
related to 0002802closed  prevent newly connected clients from voting too soon 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-09-19 20:08UnknownNew Issue
2016-09-19 20:09UnknownNote Added: 0015668
2016-09-19 23:24EmpyreNote Added: 0015669
2016-09-20 00:20UnknownNote Added: 0015670
2016-09-20 00:21UnknownNote Edited: 0015670bug_revision_view_page.php?bugnote_id=15670#r9521
2016-09-20 00:26UnknownNote Edited: 0015670bug_revision_view_page.php?bugnote_id=15670#r9522
2016-09-20 01:11Ru5tK1ngNote Added: 0015672
2016-09-20 03:54WaTaKiDNote Added: 0015673
2016-09-20 09:56UnknownNote Added: 0015674
2016-09-20 09:57UnknownNote Edited: 0015674bug_revision_view_page.php?bugnote_id=15674#r9524
2016-09-20 10:06UnknownNote Edited: 0015674bug_revision_view_page.php?bugnote_id=15674#r9525
2016-09-20 10:07UnknownNote Edited: 0015674bug_revision_view_page.php?bugnote_id=15674#r9526
2016-09-20 10:13UnknownNote Edited: 0015674bug_revision_view_page.php?bugnote_id=15674#r9527
2016-09-20 10:13UnknownNote Edited: 0015674bug_revision_view_page.php?bugnote_id=15674#r9528
2016-09-20 10:32UnknownNote Edited: 0015674bug_revision_view_page.php?bugnote_id=15674#r9529
2016-09-20 10:33UnknownNote Edited: 0015674bug_revision_view_page.php?bugnote_id=15674#r9530
2016-09-21 01:57Ru5tK1ngRelationship addedrelated to 0002802
2016-09-21 02:08Ru5tK1ngRelationship addedrelated to 0002590
2016-09-21 02:16Ru5tK1ngRelationship addedrelated to 0002801
2016-09-21 02:56AlexMaxNote Added: 0015677
2016-09-21 03:00Ru5tK1ngNote Added: 0015679
2016-09-21 03:00Ru5tK1ngStatusnew => confirmed
2016-09-21 08:42DuskNote Added: 0015680
2016-09-21 08:42DuskAssigned To => Dusk
2016-09-21 08:42DuskStatusconfirmed => assigned
2016-10-08 00:39Ru5tK1ngNote Added: 0015788
2016-10-08 00:39Ru5tK1ngAssigned ToDusk =>
2016-10-08 00:39Ru5tK1ngStatusassigned => needs review
2016-10-08 00:39Ru5tK1ngTarget Version => 3.0
2016-10-09 12:29Torr SamahoNote Added: 0015842
2016-10-09 17:46Torr SamahoStatusneeds review => feedback
2016-10-11 23:38Ru5tK1ngNote Added: 0015912
2016-10-11 23:38Ru5tK1ngStatusfeedback => needs review
2016-10-12 18:41Torr SamahoNote Added: 0015927
2016-10-12 18:41Torr SamahoAssigned To => Torr Samaho
2016-10-12 18:41Torr SamahoStatusneeds review => feedback
2016-10-13 00:33Ru5tK1ngNote Added: 0015943
2016-10-13 00:33Ru5tK1ngStatusfeedback => needs review
2016-10-13 06:16Torr SamahoNote Added: 0015946
2016-10-13 06:16Torr SamahoStatusneeds review => needs testing
2016-10-13 20:31Ru5tK1ngNote Added: 0015963
2016-10-13 20:31Ru5tK1ngStatusneeds testing => needs review
2016-10-13 22:25Edward-sanNote Added: 0015968
2016-10-13 22:25Edward-sanStatusneeds review => needs testing
2017-02-06 20:12DecayNote Added: 0016795
2017-02-06 20:19DuskStatusneeds testing => resolved
2017-02-06 20:19DuskFixed in Version => 3.0
2017-02-06 20:19DuskResolutionopen => fixed
2018-09-30 21:49Blzut3Statusresolved => closed

Notes
(0015668)
Unknown   
2016-09-19 20:09   
Not just for votekicks, It can be abused to change timelimit to 1 or even Change map .
(0015669)
Empyre   
2016-09-19 23:24   
I agree that this is a problem, but what about the case when there really are more than one player connected from the same house: brothers, roommates, etc.
(0015670)
Unknown   
2016-09-20 00:20   
(edited on: 2016-09-20 00:26)
Connections from same IP should not be counted on votes, as for brothers, roommates .. etc you could just ask them to change those Since they living with you in the same room / house lol, Assuming that you are playing on a LAN Server (owned by one of you) together .
(0015672)
Ru5tK1ng   
2016-09-20 01:11   
I thought there was already some sort of safeguard against this. Every time my brother votes, my vote doesn't register and vice versa.
(0015673)
WaTaKiD   
2016-09-20 03:54   
that safeguard can be bypassed by disconnecting one of the clients after it has voted yes, which will then allow the next client with the same IP to vote yes, which is how some of the recent votekick abuse has been happening
(0015674)
Unknown   
2016-09-20 09:56   
(edited on: 2016-09-20 10:33)
Since players from same IP can't vote unless the voter leaves, I Suggest removing the voter's vote from votecount once they disconnect / leave the game or timeout to prevent that and Increase the countdown time to at least 30 seconds so if they timeout the game would recognize they left and so it would omit their vote, This way they can only vote once and if they ever leave the game to vote with next same ip their vote would be overwritten .
(0015677)
AlexMax   
2016-09-21 02:56   
I don't think a timeout is necessary. Just remove their vote if they disconnect, or cancel the vote if they started it.
(0015679)
Ru5tK1ng   
2016-09-21 03:00   
I agree with Alex, a timeout can be easily circumvented. Definitely votes need to be taken out or cancelled if the respective player disconnects.
(0015680)
Dusk   
2016-09-21 08:42   
Yes, that we definitely need to fix.
(0015788)
Ru5tK1ng   
2016-10-08 00:39   
This is a bit difficult to test alone, but it seems to work: votes are cancelled if the caller leaves and votes are removed from the vote count if the player leaves. Scoreboard seems to update appropriately

'https://bitbucket.org/Ru5tK1ng/zandoom/branch/votefix2#diff [^]'
(0015842)
Torr Samaho   
2016-10-09 12:29   
Please see my comments on bitbucket.
(0015912)
Ru5tK1ng   
2016-10-11 23:38   
Revised based off your previous comments.

'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/150/votes-were-not-being-removed-or-cancelled/diff [^]'
(0015927)
Torr Samaho   
2016-10-12 18:41   
Thanks! Looking much better now, just one issue remains, see my comment on bitbucket. If you need more info on what I mean, just let me know.
(0015943)
Ru5tK1ng   
2016-10-13 00:33   
Ah yes, moving the function there is much better. I also improved the scoreboard checks.

'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/150/votes-were-not-being-removed-or-cancelled/diff [^]'
(0015946)
Torr Samaho   
2016-10-13 06:16   
Thanks, looks good now! I added the patch.
(0015963)
Ru5tK1ng   
2016-10-13 20:31   
Unfortunately found a flaw in the logic:

'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/152/votes-werent-being-properly-marked-as/diff [^]'
(0015968)
Edward-san   
2016-10-13 22:25   
It was added by changing a bit of history :P
(0016795)
Decay   
2017-02-06 20:12   
Tested in a LAN server by connecting 4 times, could only vote once.