View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006358 | unreal | json-rpc | public | 2023-11-02 17:53 | 2023-11-25 10:35 |
| Reporter | Jellis | Assigned To | syzop | ||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 6.1.1.1 | ||||
| Target Version | 6.1.3-rc1 | Fixed in Version | 6.1.3-rc1 | ||
| Summary | 0006358: Placing a gzline in the panel on an ident causes the server to ban everything and not allowing SSL/TLS connections | ||||
| Description | gzlines cannot be set on idents on the ircd side, because of [ERROR] (G)Zlines must be placed at *@ipmask, not user@ipmask. This is because (g)zlines are processed BEFORE dns and ident lookups are done. If you want to use usermasks, use a KLINE/GLINE instead. This is great and doesn't allow the input on the IRCd side via commands, however: The panel does not validate like this and allows the input causing undesired issues (not allowing clients because of being banned and disallowing all SSL/TLS connections...) After manually removing the gzline via the IRCd the problem remained untill rehash -global was performed (or I diden't wait long enough). To my opinion the panel should validate this input but even when no validation occures the JSONRPC interface inside the IRCd itself shouldn't allow it to happen | ||||
| Steps To Reproduce | The way it was added was via the admin panel: Add an ident gzline ban in the following format: uiuorfurz@* - via the unrealircd admin panel The operator then stated: "the browser looked to be hanging and clicked "modify ban" because of running out of patience" | ||||
| Additional Information | [16:30:54(02/11/23)] Z uiuorfurz@* 532129 2448 RPC:adminpanel [Andy] Banomzeiling (ID: Y7UDHC6QBR) The ban was indeed listed as gzline set by RPC:adminpanel | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | saprivmsg,ojoin and other | ||||
|
|
It should be noted the impact was even more severe because the panel is on another host using TLS/SSL to connect to the ircd, when the input was done the panel was non functional till the line was removed (and rehash was performed). So it can be used as a DoS rendering the panel useless (offcourse opers have other ways to do harm but still I feel this should not be possible). |
|
|
This bug report is about a bug, an unexpected issue, where a xyz@* acts as a *@*. That is indeed a bug and it should be fixed! I've put it on the 6.1.3 TODO. This bug report is NOT about something else, but i just wanted to mention it: i will not change UnrealIRCd to prevent/block placing broad bans via JSON-RPC, similar to having no set::options::allow-insane-bans. Filtering out broad bans is something that is up to the webpanel or any other JSON-RPC user. There can be good reasons for placing such bans and we (UnrealIRCd) cannot know the permissions and the reasons for placing a ban. It is similar to us not filtering out such GLINE in server or services traffic. |
|
|
Fixed, thanks for the report :) https://github.com/unrealircd/unrealircd/commit/fe8e8e127448b65267863322ec6d2bebd5b6808f commit fe8e8e127448b65267863322ec6d2bebd5b6808f (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD) Author: Bram Matthys <[email protected]> Date: Fri Nov 24 07:14:23 2023 +0100 Via JSON-RPC one could place a gzline on ident@host, which is invalid. The effect it had was actually *@host, so ident@* became *@* -grin-. Was caused by add=0 at the server_ban_parse_mask() causing a check not to happen. Fixed now. Reported by Jellis in https://bugs.unrealircd.org/view.php?id=6358 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-11-02 17:53 | Jellis | New Issue | |
| 2023-11-02 18:17 | Jellis | Note Added: 0023071 | |
| 2023-11-20 17:27 | syzop | Status | new => acknowledged |
| 2023-11-20 17:27 | syzop | Target Version | => 6.1.3-rc1 |
| 2023-11-20 17:33 | syzop | Note Added: 0023092 | |
| 2023-11-20 17:33 | syzop | Sticky Issue | No => Yes |
| 2023-11-24 07:16 | syzop | Assigned To | => syzop |
| 2023-11-24 07:16 | syzop | Status | acknowledged => resolved |
| 2023-11-24 07:16 | syzop | Resolution | open => fixed |
| 2023-11-24 07:16 | syzop | Fixed in Version | => 6.1.3-rc1 |
| 2023-11-24 07:16 | syzop | Note Added: 0023094 | |
| 2023-11-24 07:16 | syzop | Note Edited: 0023094 | |
| 2023-11-25 10:35 | syzop | Sticky Issue | Yes => No |
