View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003054 | unreal | ircd | public | 2006-09-05 05:07 | 2006-09-06 08:19 |
| Reporter | jerrcsnet | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | any | OS | any | OS Version | any |
| Product Version | 3.2.5 | ||||
| Fixed in Version | 3.2.6 | ||||
| Summary | 0003054: incorrect reverse dns | ||||
| Description | If 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) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
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. |
|
|
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. |
|
|
I'll check out what other ircds do before I close this ;p |
|
|
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? |
|
|
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. |
|
|
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. |
| 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 |
