Description of problem: On a customer's system, a large amount of processes were created by a local user. When the number of proceses reached the system limit, all NFS shares were unaccessible and anybody could not log in. Version-Release number of selected component (if applicable): RHEL 4, 5, and 6 How reproducible: Always Steps to Reproduce: 1. login with normal user 2. # tcsh 3. # touch grep # chmod +x grep 4. (Only case of RHEL6) # touch ~/.i18n 5. # setenv PATH ".:$PATH" 6. # tcsh Actual results: tcsh doesn't return and continue to create processes. A large amount of processes are created and the system becomes unusable. Expected results: A large amount of processes are not created. Additional info: ## CAUSE of this problem When tsch is executed, /etc/profile.d/lang.csh is executed as well. Some command (like grep and sed) executed in /etc/profile.d/lang.csh doesn't have absolute path. When there is the file which is not executable format in the directory specified in $PATH, after exec() for the file fails, a new tcsh process with the file is executed because it's possible the file is a script file. And, /etc/profile.d/lang.csh is executed again. So, any commands in /etc/profile.d/lang.csh should have absolute path. Please clone this bugzilla to RHEL6. If it's possible that this will be fixed on RHEL4, clone this bugizlla to RHEL4 as well.
any user could fork bomb the system... what's the point? nothing prevents anybody from doing this with any language..
better configure something like: /etc/security/limits.conf: * hard nproc 100 * hard rss 10000
It is tcsh issue. Here is another reproducer unrelated to initscripts: $ ls -l -rwxrwxr-x. 1 plautrba plautrba 0 Oct 26 15:00 fakecmd $ cat ~/.cshrc fakecmd $ setenv PATH ".:$PATH" $ tcsh
This is not something we would consider a security issue. This is no different than a traditional "fork bomb" attack scenario. While it could certainly be considered a bug in tcsh, there are so many other ways to fork bomb a system, and this just happens to be one of them. In recent Fedora and RHEL6, this is addressed by the default /etc/security/limits.d/90-nproc.conf (as a result of bug #432903) which contains: # Default limit for number of user's processes to prevent # accidental fork bombs. # See rhbz #432903 for reasoning. * soft nproc 1024 On older RHEL releases it can be set as noted in comment #2. Also adding the reporter to this bug (we have had discussion with him outside of the bug already so he is aware of our view on this issue).
I am the original reporter of this bug. Reasons I consider this is a bug: - you may think that reproducing steps are unlikely to happen on any system please consider that my users did it unintentionally thus caused serious production downtimes. - nproc setting is good to save the machine, but it still causes outage to the "malicious" user who is in this case absolutely not malicious. - The fix for this in /etc/profile.d/lang.csh looks easy I proposed a patch for it. The benefit of it is not high but eliminates this accidental fork bomb scenario. (This still leaves lot of other fork bomb possibilities tough) - Petr example is good how to shoot yourself on foot with a fork bomb, but the difference between that and the original reproducing steps are that original steps does not require any (tcsh) configuration change and using an original system configuration file to cause this behaviour. - You should not trust in PATH variable in any csh profile file. If you check all .csh under /etc/profile.d/ all other scripts use absolute path for executables.
Created attachment 455921 [details] Proposed patch for lang.csh Proposed patch from the requestor.
(In reply to comment #5) > - The fix for this in /etc/profile.d/lang.csh looks easy I proposed a patch for > it. The benefit of it is not high but eliminates this accidental fork bomb > scenario. (This still leaves lot of other fork bomb possibilities tough) > - Petr example is good how to shoot yourself on foot with a fork bomb, but the > difference between that and the original reproducing steps are that original > steps does not require any (tcsh) configuration change and using an original > system configuration file to cause this behaviour. In my case the problem script is not /etc/profile.d/lang.csh but /etc/profile.d/kde.csh which is executed before lang.csh. So this could be fixed in various scripts across whole distribution or fixed directly in tcsh since it doesn't affect other shells like bash. That's why I changed component.
It maybe not a tcsh bug, but a misuse of a tcsh feature :). I am not a tcsh expert, but both bash and ksh having login shell/normal shell concept while tcsh runs the profile for each subshell. This needs to be verified by a tcsh expert. Since it is a known behaviour of tchs I suggest chceking all .csh profile script for command not using absolute path.
I don't think there is anything wrong with those .csh scripts. Imho, it's completely fine for user to run his own versions of /usr/binaries (eg. his own optimized grep/sed). The only problem I see is in user who changed PATH variable and thus changed grep's functionality to something completely different that doesn't do the right job. I can't even say it's a bug in tcsh. It's just the default behaviour - trying to run non-binary executable files in a subshell as a script. We can try to optimize tcsh by running those scripts in current context without loading any configuration files. But we should propose this to upstream more likely as a "feature" than a "bugfix".
I still think it is bug in lang.csh and possibly in many other /etc/profile.d/*.csh scripts. If you check lang.csh closer you can see for example following code: if ( -x /bin/unicode_start ) then if { /sbin/consoletype fg } then if ( $?SYSFONT ) then if ( $?SYSFONTACM ) then unicode_start $SYSFONT $SYSFONTACM else unicode_start $SYSFONT endif endif endif endif If your idea is true why the code checks for /bin/unicode_start while it is invoke it from PATH? Possibly another unicode_start will run, or do a fork bomb :) (Do you think users want to use their own unicode_start implementation???) Let's see another example from lang.cs: if ( -x /bin/unicode_stop ) then if { /sbin/consoletype fg } then /bin/unicode_stop endif endif Let's see how the first code looks like in lang.sh [ -x /bin/unicode_start ] && /sbin/consoletype fg && /bin/unicode_start $SYSFONT $SYSFONTACM Here it is /bin/unicode_start and not unicode_start! This is correct IMHO and all should look like this. Please correct it. I upload the updated patch.
Created attachment 471917 [details] Proposed patch for lang.csh
Well, I was looking into many /etc/profile.d/*.[c]sh scripts and you are right that in most cases there are absolute paths used to point binaries. And it makes sense to me as well - but just in case we are sure the binaries are not relocatable. Several /etc/profile.d/*.[c]sh scripts (including lang.csh and kde.csh) are pointing to some binaries relatively. The thing is, that most of them are usually installed from different packages, so I can't track them all instantly. * NOTE: If we want to "fix" all these scripts, then we have to rely on their "absolute-paths". - sed - not relocatable (/bin/sed in sed.spec) - grep - not relocatable (/bin/grep in grep.spec) - cut - probably not relocatable (/usr/bin/cut in coreutils.spec ?) - tty - __probably relocatable__ (%_bindir/* in coreutils.spec) - udisks - __relocatable__ (%_bindir/* in udisks.spec) - ?others? Adding Ondrej Vasik to CC, as he is maintainer of coreutils. Ondrej, what do you think?
For reference - cut is now in /bin/cut (hardcoded in spec) as well - /usr/bin/cut is just compat symlink... such moves do happen from time to time - if some tool is considered to be required even with disconnected /usr (could be separate partition and disconnected at start up or shutdown). As you already said, these scripts are from various packages - and it will be quite long run to change them all to rely on absolute paths where possible. It's not only in .csh scripts, bash/ksh/... .sh profile.d scripts use in many cases basic tool names without absolute paths as well. However - absolute paths has one drawback - sometimes the absolute path changes - e.g. move from /usr/bin to /bin/ ... like the case of already mentioned /bin/cut - although this usually means symlink which stays in /usr/bin for quite a while, these scripts could get broken one day. So I think it's up to you - if you want to create a tracker and bugzillas with requests for .sh/.csh scripts changes in profile.d to use absolute paths - why not. But as was already said, this will not prevent user's from fork bomb ability and imho it brings very low benefit.
Single command execution in tcsh (eg. executing our fake "grep"): - fork to a subshell - find a command file (search for it's absolute path using PATH variable) - try to execute the file using execv() - if can't execute the file (ENOEXEC - not a binary executable), run it as a script using execv($SHELL, [$SHELL, command, arguments..]), where $SHELL is "/bin/tcsh", "/bin/csh" or other shell alias) The default behaviour of tcsh is to run executable files in forked subshell because of context issues - the program must not change the environment of the current shell. So I can't suggest any changes in tcsh source code, unless we want to change the above described fork-execv design (which would lead to massive patches).
There is another solution which should be clean and much more simple: Prevent user's paths while sourcing profile scripts in /etc/csh.cshrc. Changing component to setup.
Created attachment 472826 [details] Proposing patch for "git apply"
This can't be used, as some (e.g. qt.csh but I'm sure others as well) modify PATH envvar intentionally - and you will throw away this with this concept (and you will limit the user to use absolute paths in his own profile.d scripts - he can't rely on his intentionally set $PATH envvar). Maybe with some merge after the profile.d scripts... or with just filtering cwd from the PATH (and possibly restoring it later) ... anyway, nasty hacks :) ...
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Closing that WONTFIX (as in setup there is no good solution - and in Fedora/RHEL-6 it was solved in PAM as result of https://bugzilla.redhat.com/show_bug.cgi?id=432903 fix. Workaround mentioned in comment #2 ... If you believe that this has to be addressed in RHEL-5, please reopen it against pam.