[shell.so] Certain commands, when run, can result in ZNC using all the system memory, and being killed by the oom-killer. #287

New Issue

2026-10-05T04:10:14+02:00

adam commented

2026-10-05 04:10:14 +02:00

This applies to 1.0 and later, but was confirmed on 1.2 (1.0 was not tested).

There is an issue in the *shell command under 1.2 in which certain commands can be run and end up using all of the system memory for the buffered output which would be sent to the user.

Examples of this can be:

while true; do echo "test"; done

This can cause ZNC to be killed by the oom-killer on Linux systems, and can ultimately cause multiple problems including possible denial of service by the process being killed by the oom-killer.

This applies to 1.0 and later, but was confirmed on 1.2 (1.0 was not tested). There is an issue in the `*shell` command under 1.2 in which certain commands can be run and end up using all of the system memory for the buffered output which would be sent to the user. Examples of this can be: ``` while true; do echo "test"; done ``` This can cause ZNC to be killed by the oom-killer on Linux systems, and can ultimately cause multiple problems including possible denial of service by the process being killed by the oom-killer.

adam closed this issue

2026-10-05 04:10:14 +02:00

adam commented

2026-10-05 04:10:15 +02:00

Works as advertised?

Seriously, you shouldn't be enabling or allowing access to the shell module
for any user or znc instance that you can't trust. Simple as that.
On Jan 13, 2014 1:50 PM, "Thomas Ward" notifications@github.com wrote:

This applies to 1.0 and later, but was confirmed on 1.2 (1.0 was not
tested).

There is an issue in the *shell command under 1.2 in which certain
commands can be run and end up using all of the system memory for the
buffered output which would be sent to the user.

Examples of this can be:

while true; do echo "test"; done

This can cause ZNC to be killed by the oom-killer on Linux systems, and
can ultimately cause multiple problems including possible denial of service
by the process being killed by the oom-killer.

—
Reply to this email directly or view it on GitHubhttps://github.com/znc/znc/issues/463
.

Works as advertised? Seriously, you shouldn't be enabling or allowing access to the shell module for any user or znc instance that you can't trust. Simple as that. On Jan 13, 2014 1:50 PM, "Thomas Ward" notifications@github.com wrote: > This applies to 1.0 and later, but was confirmed on 1.2 (1.0 was not > tested). > > There is an issue in the *shell command under 1.2 in which certain > commands can be run and end up using all of the system memory for the > buffered output which would be sent to the user. > > Examples of this can be: > > while true; do echo "test"; done > > This can cause ZNC to be killed by the oom-killer on Linux systems, and > can ultimately cause multiple problems including possible denial of service > by the process being killed by the oom-killer. > > — > Reply to this email directly or view it on GitHubhttps://github.com/znc/znc/issues/463 > .

adam commented

2026-10-05 04:10:16 +02:00

This was suggested in #znc on IRC as a possible method of fixing this issue:

so to whoever wants to fix this: Look at bouncedcc for PauseRead() and UnPauseRead() and implement the same approach for *shell

This was suggested in #znc on IRC as a possible method of fixing this issue: <psychon> so to whoever wants to fix this: Look at bouncedcc for PauseRead() and UnPauseRead() and implement the same approach for *shell

adam commented

2026-10-05 04:10:17 +02:00

@jreese This concern came up while I was working on security bugs today, what happens if you have a disgruntled ZNC administrative user who decides to cause problems, and uses *shell (before their admin is stripped) to issue such a command that can cause ZNC to crash so that they can get payback for whatever reason?

That's why I made this issue, the issue I see is this being an issue of someone with access or with a compromised ZNC admin account using this to crash a ZNC instance. That's why I opened this issue, whether it's "works as advertised" or not.

@jreese This concern came up while I was working on security bugs today, what happens if you have a disgruntled ZNC administrative user who decides to cause problems, and uses *shell (before their admin is stripped) to issue such a command that can cause ZNC to crash so that they can get payback for whatever reason? That's why I made this issue, the issue I see is this being an issue of someone with access or with a compromised ZNC admin account using this to crash a ZNC instance. That's why I opened this issue, whether it's "works as advertised" or not.

adam commented

2026-10-05 04:10:17 +02:00

I would probably posit that in those cases where you have a third-party
admin that you may or may not be able to trust, then you should remove
shell.so altogether. Perhaps it should not be built by default, but the
moment you give anyone the potential for shell access, you already have a
losing proposition to try and lock down or protect what they can do, and
trying to blacklist "bad things" is not the answer. It should not be up to
ZNC to try and protect your shell access IMO.

But, for what it's worth, the more traditional way to protect against fork
bombs is ulimit. Setting a ulimit on the user that ZNC runs as should
allow you to mitigate some of the damage a fork bomb can cause, but it's
not a complete answer.

John Reese
noswap.com

On Mon, Jan 13, 2014 at 1:59 PM, Thomas Ward notifications@github.comwrote:

@jreese https://github.com/jreese This concern came up while I was
working on security bugs today, what happens if you have a disgruntled ZNC
administrative user who decides to cause problems, and uses *shell (before
their admin is stripped) to issue such a command that can cause ZNC to
crash so that they can get payback for whatever reason?

That's why I made this issue, the issue I see is this being an issue of
someone with access or with a compromised ZNC admin account using this to
crash a ZNC instance. That's why I opened this issue, whether it's "works
as advertised" or not.

—
Reply to this email directly or view it on GitHubhttps://github.com/znc/znc/issues/463#issuecomment-32216208
.

I would probably posit that in those cases where you have a third-party admin that you may or may not be able to trust, then you should remove shell.so altogether. Perhaps it should not be built by default, but the moment you give anyone the potential for shell access, you already have a losing proposition to try and lock down or protect what they can do, and trying to blacklist "bad things" is not the answer. It should not be up to ZNC to try and protect your shell access IMO. But, for what it's worth, the more traditional way to protect against fork bombs is `ulimit`. Setting a ulimit on the user that ZNC runs as should allow you to mitigate some of the damage a fork bomb can cause, but it's not a complete answer. John Reese noswap.com On Mon, Jan 13, 2014 at 1:59 PM, Thomas Ward notifications@github.comwrote: > @jreese https://github.com/jreese This concern came up while I was > working on security bugs today, what happens if you have a disgruntled ZNC > administrative user who decides to cause problems, and uses *shell (before > their admin is stripped) to issue such a command that can cause ZNC to > crash so that they can get payback for whatever reason? > > That's why I made this issue, the issue I see is this being an issue of > someone with access or with a compromised ZNC admin account using this to > crash a ZNC instance. That's why I opened this issue, whether it's "works > as advertised" or not. > > — > Reply to this email directly or view it on GitHubhttps://github.com/znc/znc/issues/463#issuecomment-32216208 > .

adam commented

2026-10-05 04:10:18 +02:00

@teward: pkill -SIGSEGV znc works better at making znc crash anyway, no need to make it OOM for that. :-P

@teward: pkill -SIGSEGV znc works better at making znc crash anyway, no need to make it OOM for that. :-P

adam commented

2026-10-05 04:10:19 +02:00

We don't try to protect from admin users, as well as from root on the
system.
If admin is evil, they may do bad stuff even without shell module.

We don't try to protect from admin users, as well as from root on the system. If admin is evil, they may do bad stuff even without shell module.

adam commented

2026-10-05 04:10:20 +02:00

@psychon good point, perhaps it'd be better to just disable *shell building by default, and add it as a configurable option to ./configure? Since it seems like it could always be used for bad things, when used by malicious admins.

(this is typically why I disable it or remove its code before building)

@psychon good point, perhaps it'd be better to just disable `*shell` building by default, and add it as a configurable option to `./configure`? Since it seems like it could always be used for bad things, when used by malicious admins. (this is typically why I disable it or remove its code before building)

adam commented

2026-10-05 04:10:20 +02:00

"what happens if you have a disgruntled ZNC administrative user who decides to cause problems".

Rule one, never add someone you don't trust.
Rule two, if you start to suspect that are going to do stupid crap like that, revoke access.
Rule three, goto Rule one.

I think deleting all the users would be more destructive (assuming nobody does backups) and crashing the server at the same time. While we are at it, can we play with send_raw?

"perhaps it'd be better to just disable *shell building by default, and add it as a configurable option to ./configure"

No. Thankfully znc already ONLY allows admins run it unless you run a flag to let EVERYONE run it.

/paranoid..
rm <znc_dir>/modules/shell.*
./configure
make ...

"That's why I opened this issue, whether it's "works as advertised" or not."

Id call it a "works as advertised".. you got a nice module that can send shell commands. Don't want someone to send stupid commands through it, then don't give them access to the module.

"what happens if you have a disgruntled ZNC administrative user who decides to cause problems". Rule one, never add someone you don't trust. Rule two, if you start to suspect that are going to do stupid crap like that, revoke access. Rule three, goto Rule one. I think deleting all the users would be more destructive (assuming nobody does backups) and crashing the server at the same time. While we are at it, can we play with send_raw? ## "perhaps it'd be better to just disable *shell building by default, and add it as a configurable option to ./configure" No. Thankfully znc already ONLY allows admins run it unless you run a flag to let EVERYONE run it. /paranoid.. rm <znc_dir>/modules/shell.* ./configure make ... ## "That's why I opened this issue, whether it's "works as advertised" or not." Id call it a "works as advertised".. you got a nice module that can send shell commands. Don't want someone to send stupid commands through it, then don't give them access to the module.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#287