Slashdot Mirror
How Poor Punctuation Can Break Windows
An anonymous reader writes with a report at Ars Technica about how a small bug can lead to a security problem. In this case, the problem is that quotation marks — or the lack of them — can be significant. From the Ars article:
"The scenario... requires a 'standard' user with access rights to create a directory to a fileserver and an administrator executing a vulnerable script," Frank Lycops and Raf Cox, security researchers with The Security Factory, said in an e-mail interview. "This allows the attacker to gain the privileges of the user running the script, thus becoming an administrator." While the attack falls short of the severity of the Shellshock family of Linux shell vulnerabilities, the two researchers stressed that it's a good example of how untrusted input can be used to execute commands on a system. The researchers identified at least one popular script with the vulnerability. When the script attempts to set the starting directory for system administration work, it inadvertently runs the command appended to the malicious directory's name as well. ... The solution is to use proper coding practices—in this case, the judicious use of quotation marks. Quotation marks are used in the shell environment to make sure that the data inside the quotes is not interpreted by the program as a command.
We call him Little Billy Tables.
Yeah, if you trick an administrator into running a script or program you can do all kinds of things.
On the other hand you can do much worse on Linux using Bash to remotely gain control to a system with no administrator action required.
Linux wins again.
2015 will be the year of Linux on the desktop because nobody trusts Linux servers.
Vulnerable script written by incompetent administrator leads to privilege escalation exploit. News at 11.
So if you can get admin to run a script, you can own a machine.
News at 11.
Seriously, this is slashdot. We know that if you have admin to get to run a script, you can own the machine.
This is also the reason why I cringe when the backend of Linux distros is often woven together with shell scripts. You have to be super careful to write code with proper input validation, and all the related tools must retain their interfaces or you get weird "Invalid argument" type of breakage. Then there are things like Shellshock which immediately made the dhclient script vulnerable. It's all just too dangerous. And I didn't even begin to talk about the slow parsing of scripts and the forking overhead of every little process the script calls.
Except in the cases it triggers the exploit. IMHO, that's the newsworthy bit of this.
Not quoting causes issues is news along the same level as "water is wet". Trying to be secure and breaking things? That's big. At least it's not possible with filenames.
Running unsanitized input as shell commands as root may lead to compromised systems. News at 11.
... in filenames. They are and were fundamentally incompatible with DOS-based shells or anything derived from them.
Not for nothing a large percentage of coders out there are incapable of discerning when to use "its" or "it's".
.
I am shocked!! SHOCKED, I say!!!!!!
Have /. really sunk so low that hyped-up articles like the one quoted are now newsworthy?
Ditto. I heard it before, with relation to Win95/Me. Ha!
I like how they call the bash vulnerabilities``Linux shell vulnerabilities''. Like that was somehow Linux' fault, or any other shell was affected.
0/10 wouldn't read again.
Disclaimer: I run a BSD and my bash sure as hell was affected.
CLI paste? paste.pr0.tips!
We placed a vacancy in the U.K., on the DWP/work "programme" system which was running Linux Ubuntu, which was set up to be used by clients just like a Internet cafe. Anyway out of curiosity I pushed Ctrl + Alt + F12 and then F10 which drop me to a terminal. I did a ( ls ) and I could see there was a program available called "setup" I run the program setup it said it was running but nothing happened so I tried it again and pushed Ctrl + Alt + F1 to quickly popped back into the desktop "Unity" and the setup program suddenly started running with many options it asked me did I want to use a password or a key for SSH so I selected the option no password no key and opened it up to the Internet? It also had the option to put a password in for when the system is rebooted so I put in a password. Which means they will have to put in a password for network? I forgot to tell anybody the password. For placing a vacancy I had to pay for each word I typed! totally ridiculous. Anyway what is this setup program?
I've seen some stupid Windows-bashing shit on /. through the years, but this takes the cake. Congratulations timothy, you've proven beyond a doubt that you're a moron.
Misplaced punctuation can cause trouble. From: Eats, shoots and leaves:
A panda walks into a café. He orders a sandwich, eats it, then draws a gun and proceeds to fire it at the other patrons.
"Why?" asks the confused, surviving waiter amidst the carnage, as the panda makes towards the exit. The panda produces a badly punctuated wildlife manual and tosses it over his shoulder.
"Well, I'm a panda," he says. "Look it up."
The waiter turns to the relevant entry in the manual and, sure enough, finds an explanation. "Panda. Large black-and-white bear-like mammal, native to China. Eats, shoots and leaves."
It must have been something you assimilated. . . .
The solution is to use proper coding practices—in this case, the judicious use of quotation marks. Quotation marks are used in the shell environment to make sure that the data inside the quotes is not interpreted by the program as a command.
The solution is to never make assumptions about input that's being provided by an unknown user. It doesn't matter if we're talking about shellshock, or sql back ends, or powershell scripts - you simply can't assume your users are all good hearted and/or competent.
By the way, given they likely only went looking for similar Windows related bugs after shellshock became known - this vulnerability was a pretty good catch.
#DeleteChrome
This is slashdot.
BUT, my first thought went to that wkward moment last spring, saying to my neighbor
"Hey! Is our new psycho, the rapist, your daughter?"
I wanted to say psychotherapist, but my punctuation was poor.
So was the glass on my windows. We still have that granite-cube-paved walkway.
It is the exact same type of vulnerability that have existed in other weakly-typed shells since their inception. This is the reason why you should use -print0 with find before passing it to any other program: If you do not you risk that the filename is an injection attack.
The culprit is the idea that a shell is just some form of text interpreter that will interpret anything that is text. There is no semantic separation of "text" and "executable".
Unfortunately, this "code is just text" has become so entrenched in shell scripting that it is vulnerabilities waiting to happen. Process substitution, subshells etc all rely on this very property.
At least with PowerShell there is no such stupidity. In PowerShell you have to indicate specifically each time you want text interpreted and executed. PowerShell script block is a separate type (actually, a lambda) from text, integers, dates, decimals etc. The ease of how you pass executable content (script blocks) even over the network removes most reasons to interpret text as executable commands.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Cmd.exe is vulnerable, but command.com is not. Looks like a regression.
It all boils down to the simple fact that as long as there are users, it will be possible to gain unauthorized access to any system. They can keep trying to make changes that prevent this kind of thing from happening, but even duct tape can't fix stupid. If it weren't for users, I wouldn't have a job.
... and the reason why on other operating systems you have to escape spaces every time. This way you cannot have the ambiguity if you mean a path with a space, or a program and then a parameter.
The solution is to use proper coding practices
This approach is partly why breaches continue to happen. Imagining that somehow many thousands of coders will always do things right over many thousands of projects is the stuff dreams are made of. An actual effective solution would be to provide an environment where the application coder can't screw it up.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Yes, the problem is that shell scripts are just bad. Most compiled languages go out of their way to separate code and data, so as to avoid having data that is executed. The one exception to this is stack space which the CPU uses for code (namely the return address of function calls) and yet languages insist on also storing data there, which then leads to the common buffer overflow exploit. Aside from that, they're pretty good about putting code in code segments and data in non-executable segments. The only real failing there is that, despite non-executable stack segments, CPUs effective execute them anyway when they allow data in the stack segment to tell the CPU which code to execute next.
Shell scripts, on the other hand, try to mix up code and data as much as possible. Like in your example, obviously the "*" is meant to tell the shell to give the "rm" command some data (a bunch of file names), but that data will happily be interpreted as commands. Not only should it be quoting the file names and specifying them as pathnames (either beginning with "/" or "./") but the "rm" command and everything else should be complaining when it receives unquoted file names since file names are data yet they were input as if they were code. ...and of course, the individual commands never even see the quotation marks and so they couldn't complain about such things if they wanted to.
Shell scripts really are a good example of how not to design a safe programming language. Hell, even to this day, every time I type "mv this_file that_file some_folder" I'm nervous as fuck between typing "that_file" and "some_folder" that I might accidentally hit the enter key, especially if the folder name starts with a capital letter, as it'll erase "that_file" when it overwrites it with "this_file." The destination really should come first in order to prevent such accidents, but people can't seem to wrap their heads around "destination first" even though they do it that way every time they type "a = b + c."
I love the fact you try to equate Windows and Linux for this epic bug as if they're both as vulnerable. Really, it's hilarious. Technically you're right but we both know absolutely nobody except *NIX fans run bash on Windows. Ok maybe a bit more but still, your attempts to divert negative PR gave me quite the chuckle.
throw new NoSignatureException();
...except for shellshock.
that's a bug and got fixed.
prove me wrong.
and not with the classic file '-rf' as that's not executing but just plain parameter passing (which really should get fixed to be less likely to break stuff, i.e. fix GNU getopt)
Atari rules... ermm... ruled.