Decades-Old Bash Tricks Expose AI Coding Agents To Supply Chain Attacks (securityweek.com) 26
Slashdot reader wiredmikey writes: AI security researchers have uncovered a structural security flaw dubbed GuardFall that allows decades-old Bash shell tricks to bypass safeguards in most open source AI coding agents. By exploiting shell behaviors such as quote removal and variable expansion, attackers can hide malicious commands in repositories, README files, Makefiles, or other content consumed by AI agents. If executed — particularly in auto-approve or CI environments—the commands can steal credentials, compromise developer systems, or enable software supply chain attacks. According to researchers at Adversa AI, the 11 popular open source AI coding agents tested, only one successfully blocked all of the Bash trick techniques.
cat food (Score:2)
Re: (Score:3)
Re:cat food (Score:5, Informative)
What it does
When executed in a POSIX-compliant shell (like Bash), this command causes the system to rapidly consume all available resources by creating an exponential number of processes until the system crashes or becomes completely unresponsive.
Breakdown of the syntax
Here is how that cryptic string is interpreted by the shell:
{
&: This puts the function call into the background, so the parent process doesn't wait for it to finish.
Essentially, the function calls itself twice, and because it runs in the background, each call continues to spawn more copies of itself uncontrollably.
Important Warning
Do not run this command on your computer.
If you execute this, your system will likely become unresponsive, requiring a hard reboot to clear the process table and recover. On many modern Linux distributions, there are default security limits (ulimit) in place that prevent a single user from spawning enough processes to crash the entire system, but it is still highly inadvisable to test it."
Re: (Score:3)
Re: (Score:2)
Thats just an ASCII emoticon of a totem pole.
Re: (Score:2)
B+. You met the malicious code requirement perfectly; but you ignored the secondary requirement that it also be easily-identifiable ASCII art.
cat & food (Score:2)
Re: (Score:3)
I'm not following this FP branch too well, but bash.org is gone so I can't check (or read the jokes).
My favorite from that source was just recovered by the AI. I find it depressing to get it that way, but it's still funny after all the years.
You are thinking of Bash.org Quote #835030, which features a person named Judge-Mental trying to help a user named Khassaki.The absolute classic text of the IRC chat log reads exactly like this:
<Khassaki> HI EVERYBODY!!!!!!!!!!
<Judge-Mental> try pressing the the Caps Lock key.
<Khassaki> O THANKS!!! ITS SO MUCH EASIER TO WRITE NOW!!!!!!!
<Judge-Mental> fuck me.
If you want to dig deeper into internet history, let me know:Do you want to see other famous text-case mishaps from old message boards?Are you looking for more legendary Bash.org / IRC quotes?
Attitude (Score:5, Insightful)
Re: (Score:1, Offtopic)
In my exerience, the share of programmers that (a) understand that shell is a programming language and not some weird command prompt
It's a dessert topping and a floor wax. This was an unusual feature of UNIX, but since then it's become the norm, albeit with everyone else inheriting it from there. You can write MS-DOS scripts with complex independent logic, you just don't want to.
and (b) take the time and invest the effort required to learn it properly is surprisingly small.
I don't know that I've learned it "properly" to this day, but I can thank The UNIX Programming Environment [uohyd.ac.in] for making me basically capable. (I believe that my paper copy is a later edition than this...)
Re: (Score:1)
Re: (Score:2)
True. Look at the bash "if" keyword. Not only it does not have operators but executes a command, but the standard comparison command even does string comparison for numbers. And beware of empty variables, they can cause syntax errors that cannot be determined statically (even though one can determine the potential for them).
if $a == b; then do_something; fi?
Why is there a semicolon after the condition? Why are there no braces (or meaningful whitespace) but a keyword, are we writing pascal? And "fi"? At leas
Re: (Score:2)
I guess that's the smallest problem. esac (somehow I avoid case in shell scripts anyway) is a bit silly, but it's a keyword after all. But the semantics of shell scripts are sometimes really messed up. I guess some of the modern shells may be better.
Re: (Score:2)
Which is completely untrue. The problem is the people writing unreadable shell-scripts (or any unreadable code, it can be done in _all_ languages). It is a poor craftsperson that blames their tools...
Re: (Score:2)
Re: (Score:2)
The problem is not the learning, but the remembering.
I basically learn it every time again, when I have/want to use it.
The syntax is simply a little bit to archaic, and if I make a mistake instead of looking a certain bit up again, it might be pretty bad. So basically I code in Bash (etc.) with an open manual or browser and look up nearly everything in a new project.
Re:Attitude (Score:4)
The thing is, most coders and other IT people stay in their narrow area and do not look out. Hence you get coders with no clue about system administration, networking and security. You get "security experts" that cannot code or do system administration or anything really (and are hence basically worthless). You get sysadmins that cannot do shell scripting (or any coding), which is completely pathetic.
This is a result from the immaturity of the IT field: No qualification requirements, no liability, no long-term technological stability and hence no real standard approaches and anybody can claim to be an expert on anything. And hence a lot of things are brittle as fuck, hard to use, hard to maintain, insecure and unreliable.
Re: (Score:3)
Can you tell I retired almost 20 years ago?
Your fault (Score:2, Interesting)
> especially in CI pipelines where 'auto-yes' modes are default.
If you run your agent in homer's bird mode, then you get what you asked for. Any why does a LLM run in A CI pipeline? Sounds like a waste of resources. Precompute things instead of running them for each build. And running code from untrusted projects is bad anyway, no matter if a human does or an agent. If the readme of a project contains a bash line that does nasty things, you should avoid the fucking project.
What ???? (Score:5, Insightful)
1989 GNU rewrite of the original Linux Bourne Shell
After reading this line at the start of the article, I stopped reading. For people with their heads in the sand, Linux did not exist in 1989, inconceivable.
Re: (Score:3)
Then this is really going to blow your mind.
GNU is older than Linux. [wikipedia.org]
BASH is also older than Linux. [wikipedia.org]
GNU was started in 1983, well before Linux existed. The first beta release of BASH was indeed in 1989, also before Linux existed.
One of the main reasons Linus gave for making the Linux kernel GPL back in the day was to thank the FSF for their GNU utilities, which he was heavily using at the time.
Maybe running agents productively is a bad idea? (Score:2)
Or rather obviously, running AI agents productively is a _really_ bad idea at this time. But a quite large part of the human race has no active intelligence and needs to get hurt before they stop doing the stupid thing.
only one (Score:2)
Re: (Score:2)