View Issue Details

IDProjectCategoryView StatusLast Update
0004318unrealircdpublic2014-07-05 14:09
ReporterShawnSmith Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.2.10.3 
Target Version3.2.10.4Fixed in Version3.2.10.4 
Summary0004318: Identified users can not being recognized as identified
DescriptionUsers who are identified with services that use accountnames instead of usermode 'r' are not being recognized as identified when dealing with +R/+M channels.

Services being used are Anope 2.0.1
TagsNo tags attached.
3rd party modules

Activities

Jobe

2014-06-19 10:07

reporter   ~0018200

I am able to replicate.

Steps I used to replicate:

1) identify to services using account names in /whois
2) change nick to unregistered nick so mode is set -r
3) join new channel
4) set channel mode +M-o <mynick>
5) attempt to speak

Amiga600

2014-06-19 10:18

reporter   ~0018201

Last edited: 2014-06-19 10:22

Hmm this does happen, But I assume it will do because UnrealIRCd only checks against numeric [307] "is identified" as opposed to numeric [330] user is logged in as accountname

eg.
[307] Amiga600 is identified for this nick
[330] Amiga600 is logged in as Amiga600

(No 307 numeric, which is correct, as "A600" is not a services registered nickname)
[330] A600 is logged in as Amiga600

I would assume it could be made to check the accountname to see if thats valid before allowing the user in +R +M channels to join/speak respectively.

I also assume the accountname will follow you until you either logout of services or disconnect, so this would indeed be useful to add to unrealircd.

Very good point you brought up here Jobe :)

Jobe

2014-06-20 21:27

reporter   ~0018202

Strictly speaking, UnrealIRCd doesnt check WHOIS numeric replies at all. Internally UnrealIRCd stores a "flag" on the user when the user has user mode +r, and has a field associated with the user for account name.

The problem as it stands is that the latter isn't being checked for a non-empty value.

Stealth

2014-06-21 04:45

reporter   ~0018203

Updated issue to reflect the following:
- Priority is "Normal", as we reserve high priority issues for crashes, blocks, exploits, security, etc.
- I lowered the severity from major to minor, as this is simply dealing with how UnrealIRCd is checking a user's access against internally stored information. This bug was introduced when we added support for user accounts.
- I have confirmed the issue based on Jobe's findings.
- I think this should be targeted for the next release of UnrealIRCd (3.2.10.4), though I cannot guarantee it will be fixed in that version.

I have the following suggestions to remedy the issue until a fix can be released:
- If supported by Anope, use +r to ensure users are continuing to be properly evaluated by UnrealIRCd when it comes to registered vs. unregistered permissions.
- Keep an eye on this bug for a patch or a resolution that can be diff'd out of our repository to apply to your own UnrealIRCd installation.

syzop

2014-07-05 14:09

administrator   ~0018206

http://hg.unrealircd.com/hg/unreal/rev/e25a31250723
Changelog:
For services who allow you to log in by account name but still allow you to use a different nick: when you're logged in you are now considered registered as far as channel mode +M (only registered users may speak and +R (only registered users may join) are concerned. Same for user mode +R (only allow private messages from registered users).
Tech: whenever services set SVID and it's not * and does not start with a number, then we consider this user to be 'logged in'. Whenever a user is set +r (s)he is also considered 'logged in'. This way it's compatible with both older and new services and doesn't introduce security issues with older services using servicetimestamp for nick tracking or other means.
This issue was reported by ShawnSmith (0004318).

How to apply the patch:
wget -O patch "http://hg.unrealircd.com/hg/unreal/raw-rev/e25a31250723"
patch -p1 <patch
make && make install


If it doesn't work, let me know. I tested it with anope 2.x and 1.x.

Issue History

Date Modified Username Field Change
2014-06-19 05:30 ShawnSmith New Issue
2014-06-19 10:07 Jobe Note Added: 0018200
2014-06-19 10:18 Amiga600 Note Added: 0018201
2014-06-19 10:22 Amiga600 Note Edited: 0018201
2014-06-20 21:27 Jobe Note Added: 0018202
2014-06-21 04:45 Stealth Note Added: 0018203
2014-06-21 04:45 Stealth Priority high => normal
2014-06-21 04:45 Stealth Severity major => minor
2014-06-21 04:45 Stealth Status new => confirmed
2014-06-21 04:45 Stealth Target Version => 3.2.10.4
2014-07-05 14:09 syzop Note Added: 0018206
2014-07-05 14:09 syzop Status confirmed => resolved
2014-07-05 14:09 syzop Fixed in Version => 3.2.10.4
2014-07-05 14:09 syzop Resolution open => fixed
2014-07-05 14:09 syzop Assigned To => syzop