View Issue Details

IDProjectCategoryView StatusLast Update
0003054unrealircdpublic2006-09-06 08:19
ReporterjerrcsnetAssigned Tosyzop 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformanyOSanyOS Versionany
Product Version3.2.5 
Target VersionFixed in Version3.2.6 
Summary0003054: incorrect reverse dns
DescriptionIf you have a reverse DNS, lets say, tiki.jerrcs.net, and tiki.jerrcs.net is a CNAME for something else, and the IP matches, then your host will become the value of the CNAME instead of the true PTR value.
Steps To Reproduce(1) Have a PTR record on your IP (ex: 209.9.235.25 ptr tiki.jerrcs.net)
(2) Set PTR value as a CNAME (ex: tiki CNAME tiki.vo.jerrcs.net)
(3) Set CNAME record to the correct IP (ex: tiki.vo IN A 209.9.235.25)
(4) Connect to any UnrealIRCd server (hostname will be: tiki.vo.jerrcs.net)
TagsNo tags attached.
3rd party modules

Activities

jerrcsnet

2006-09-05 05:13

reporter   ~0012313

argument:
what if did a CNAME to some host like jerrcs.has.a.kewl.rdns.biz, then changed it to another one such as jerrcs.g00gle.com or something? I could ban evade easily without going to the isp at all.

syzop

2006-09-05 05:53

administrator   ~0012314

Trying to understand the "bug" here (set bug as private, just in case)...
UnrealIRCd follows cnames, correct.
As long as the final name resolves back to the IP, there shouldn't be any problem. So it's not like you can 'steal' other domain names.

syzop

2006-09-05 09:55

administrator   ~0012319

I'll check out what other ircds do before I close this ;p

jerrcsnet

2006-09-05 20:08

reporter   ~0012334

So far the other IRCds I have tried with this have not worked (instead my hostname was the original PTR record, like normal), but I don't think this would be very good, because people can change their hostnames on the fly and ban evade.

So if other IRCds frown on this (following cnames), shouldn't Unreal aswell?

syzop

2006-09-06 06:57

administrator   ~0012337

2 bugnotes deleted, so to start over again:

IMHO, there isn't any security problem with this. DNS is volatile, it can be changed at any time... CNAME's at A level have nothing to do with this.
The fact that if you have some hosting provider where you can't easily change reverse dns and this making it easier, doesn't have anything to do with this.

You know CNAME's at PTR level? It's like this:
142.10.168.192.in-addr.arpa CNAME indirect2.testnet.
indirect2.testnet PTR somehost.testnet.
And then, of course, you can do:
somehost.testnet A 192.168.10.142

This is something which every ircd supports (every major one, and proper one), because it's how hosting providers (and others) can easily delegate reverse dns to their customers.

See how easy it is then to change DNS? In fact you only have to update one zone, even.

Anyway, IMO I don't need such an example to illustrate that DNS is volatile... If you have access, which certainly isn't that rare, you can easily update reverse and forward dns to your liking in a minute. And if you have "evil thoughts" you can prepare it and do it like 2 seconds after you connect!

So that's the part where I disagree there's a security problem.

***

I got distracted by this "security problem" talk, so now let's get up to the "what would be right" question...
Now looking into this, and checking out other IRCd's, I think we should indeed use the original value. The CNAME thing is just a "step inbetween" and that name should be ignored.

I'll see how I can fix this.

***

Just to make things clear: I do thank you for the report, I just don't agree with the security argument, which made me heavily focus at that, instead of your original post.

syzop

2006-09-06 07:26

administrator   ~0012338

Fixed in 3.2* cvs (and 3.3* cvs in a minute), noticed some other errors as well:
- Fixed small memory leak in resolver (~40 bytes when connecting to a server)
- Made Unreal use the original name in case of a CNAME, instead of the forwarded name,
  reported by jerrcsnet (0003054).
- The "looking up your hostname" message was always sent, regardless of show-connect-info.

Thanks for the report.

Issue History

Date Modified Username Field Change
2006-09-05 05:07 jerrcsnet New Issue
2006-09-05 05:13 jerrcsnet Note Added: 0012313
2006-09-05 05:50 syzop View Status public => private
2006-09-05 05:53 syzop Note Added: 0012314
2006-09-05 09:55 syzop Note Added: 0012319
2006-09-05 20:08 jerrcsnet Note Added: 0012334
2006-09-06 06:57 syzop Note Added: 0012337
2006-09-06 07:01 syzop Status new => assigned
2006-09-06 07:01 syzop Assigned To => syzop
2006-09-06 07:26 syzop Status assigned => resolved
2006-09-06 07:26 syzop Fixed in Version => 3.2.6
2006-09-06 07:26 syzop Resolution open => fixed
2006-09-06 07:26 syzop Note Added: 0012338
2006-09-06 08:19 syzop View Status private => public