The hostmask can be exploited

[GoogleCodeExporter]

What steps will reproduce the problem?
From reading the source code.

What is the expected output? What do you see instead?
A different User object if the hostmask has changed.

What version of the product are you using? On what operating system?
2.0.1

From reading the source code there are two places were the hostmask of a User 
is set. That is line 643 in the InputParser for a WHO reply and line 506 in the 
InputParser. So from that it might very well be that the hostmask is null if 
the user has so far only interacted via PM. The Javadoc does not reflect that.

But there is an even greater problem with that. Assuming you are controlling 
your bot and used some kind of authentication (like a password or simply the 
nickserv auth status) and then log off (without having joined a channel in 
which the bot is). Now let's say another user is logging in from another 
location but doesn't know your password. The User object would still be the 
same because the hostmask (which is the only thing that would have changed) is 
not taken into account for creating the User object. The user could now even 
join a channel where your bot is in as well and the bot would still consider it 
beeing the same connection that once authed. And even if he has only a few 
seconds because nickserv will kick him, that's still enough time to cause 
trouble.

So the only way to make sure you are not running into this exploit you need to 
ask the server every time for the hostmask to make sure it is still the same 
user.

That of course is assuming noone is able to use the same hostmask as you do but 
I guess there is no way to then seperate each connection.

Maybe I'm overlooking something huge here but it seems like there is currently 
no reliable way of controlling your bot via PM since you can't make sure that 
no one else has taken over your nickname.

I know that some servers are not sending the hostmask as part of the source but 
having the User object depend on the hostmask AND the nickname would solve this 
problem at least on some servers.

Original issue reported on code.google.com by firewi...@googlemail.com on 22 Jul 2014 at 12:25

• Merged into: #148

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This just seems like Private Message Event is missing a few checks. Shouldn't 
be too difficult. (Not to mention this is very unlikely to happen as both the 
bot and the known auth-user would have to be monitored quite closely)

Original comment by jzhou2...@gmail.com on 22 Jul 2014 at 12:00

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

That is not just a few checks missing, that is the entire User object handling 
that takes the first hostmask and also created only one User object at all that 
is only removed if the user has never send a private message and parts all 
channels. If course I could be wrong on this, but I've not seen any cleanup 
process that would ever get rid of User objects.

This is related to #148.

Original comment by firewi...@googlemail.com on 22 Jul 2014 at 2:40

[GoogleCodeExporter]

This was some of the motivation for Issue #148: By centralizing all user 
creation to one method (createUser) instead of randomly (getUser if one doesn't 
exist) I could make login and hostmask final. On top of other benifits like 
stopping memory leaks with random "users" from the IRC server. Eg 
"chat.freenode.net" was a full user in 2.0

My free time is limited nowadays so I don't have an ETA. Patches are welcome

This issue has better reasons but fundamentally is still the same as Issue #148

Original comment by Lord.Qua...@gmail.com on 22 Jul 2014 at 3:23

• Changed state: Duplicate