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.
Vulnerable script written by incompetent administrator leads to privilege escalation exploit. News at 11.
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.
This reminds me of Raymond Chen's oft-used Hitchhiker's quote: "It rather involved being on the other side of this airtight hatchway."
If you read the article (even the summary) you can see this isn't about tricking an admin into running a script. This is about a script already set to say, list a set of directories and do something per directory, but if a user names a directory FOO&BAR the script will interpret BAR as a command instead of input.
On the other hand you could do much worse on Linux using Bash to remotely gain control to a system with no administrator action required.
... but it was patched in under a week. The sysadmins who haven't applied the patches (which didn't require a reboot, or even so much as reloading the shell after installation) are the same ones who run Windows boxes so far behind on patches they're still remotely exploitable, too. Hell, they probably run Apache on Cygwin on Windows and never patched that, making their Windows box vulnerable to Shellshock. That's possible because, guess what, Bash isn't Linux and, in fact, predates Linux; Bash runs on *every* OS. Yes, even the iPhone can run Bash if you jailbreak it.
For the record, Yahoo, running FreeBSD, was compromised via Shellshock. Apple's Darwin kernel, which both OSX and iOS run on top of, was forked from the very same kernel Yahoo's servers run, and yes, OSX Yosemite is still waiting for a patch for Heartbleed, which means I have to keep a large number of services I'd like to be running disabled for the time being. My Linux servers, though, were all patched within hours; when an alternate exploit was found, they were once again patched in hours. I'm not even sure the Windows POSIX layers have released patched builds yet, so at this point Windows systems are more vulnerable to this than anything other production system (Yodsemite is still in beta, remember); fortunately, I don't run a POSIX layer on my Windows dev box.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
Reading's over rated if all OP wanted to do was rant and dump on Linux...
Moreover, that missing quotation marks in scripted languages are a problem is basic knowledge.
... in filenames. They are and were fundamentally incompatible with DOS-based shells or anything derived from them.
This "patched within hours" is a bit of a false economy if you need to test your apps aren't going to be negatively impacted. If you don't care or just want to live the dream then yeah, otherwise the real world is a bit more complicated than that. The fact the patch needed patching in itself suggest some testing will be needed if you care about top-to-bottom stability.
throw new NoSignatureException();
.
I am shocked!! SHOCKED, I say!!!!!!
Have /. really sunk so low that hyped-up articles like the one quoted are now newsworthy?
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!
While this article did kinda make me roll my eyes, it's not quite as simple as that.
The basic idea they're saying is that if a user can create a directory with an arbitrary name (which is normal for a file-server), and that later on an Admin runs a maintenance script which doesn't quote input correctly, arbitrary user commands can be executed with administrative permissions.
So user does:
D:\Users\b\bob123> md "Foo&evil_command"
Days, weeks, months later, an admin decides to run a cleanup/repoting batch file that was written in 1996:
D:\Users> C:\Scripts\cleanup.bat
If the script descends into the filesystem and somewhere in that script is the line: SET CurDir=%CD%, then the effective command SET CurDir=Foo&evil_command is executed.
The end result is that evil_command is invoked by the admin. If the admin is a domain admin and that command happened to be net localgroup "Domain Admins" domain\bob123 /domain, then bob has just been added to the Domain Admins group.
It's an absurdly tiny problem compared to the Bash shell exploit, but it is in fact a violation of security boundaries. Raymond's airtight hatchway stories are when no boundary has been crossed.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
it is GNU BASH Shellshock that is the common component. There, fixed it for Mr Stallman.
The patch didn't need patching, there were two separate exploits, one discovered during a decode review prompted by the other. There were actually 6 CVEs published about this, all of which can be found here. Might want to get your facts straight before you spout off.
If your applications are passing executable code as user-specifiable data that then gets passed as environment variables to a forked process that then spawns a system call eventually involving Bash, then you should be glad the patch broke it, as it just revealed a massive security vulnerability within your application. If you need that application to remain functional while you patch the issue, roll back to the previous version of Bash and work under the assumption that the gaping security hole that you're calling an application has already been compromised, because what it's doing is so much worse than Shellshock. More to the point, if your application were passing executable code or commands in this manner, the likely scenario is that you have some sort of command processor on the other end parsing and executing them; if you're exploiting Shellshock to accomplish this, you deserve prison time for gross negligence for A) incorporating the vulnerability into your application and B) not disclosing it so it could be patched.
At any rate, it's not a Linux issue, it's a Bash issue. Again, since Bash can run on *anything*, that makes it and "anything running Bash" issue, including your precious Windows in the majority of server environments, where a POSIX layer like Cygwin or MinGW (both of which include Bash) is likely to be in use.
Furthermore, simply having Bash installed does not make a system vulnerable; there has to be some service listening that passes unsanitized user-specified data as environment variables to a system call eventually handled by Bash. So surprisingly few competently written applications do this; GNU dhcpd was one, I'll give you that if you can give me another.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Wow, did I really type "decode review". Shit. Well, you all know what I meant, anyway.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Thanks for the correction, I've been busy with product launches for the past 2 weeks so I haven't kept up.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Before they can ship a patch, Apple would first have to ship an affected version of OpenSSL. For binary compatibility reasons, Apple never moved its OpenSSL libraries off of the 0.9.x branch. Currently, Yosemite ships with version 0.9.8za. The first version of OpenSSL affected by Heartbleed was 1.0.1.
In other words, unless you installed an affected version of OpenSSL (in which case you will have to install an update yourself), it is safe to turn those services back on, and it always has been.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I meant Shellshock, which you probably could have guessed from context. My bad.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Yahoo's systems were _not_ compromised via the bash bug
This is what was being reported before I entered into two weeks of product launches that have kept me from following up. I'd thank you for the correction but you're a bit late with it, another poster already corrected me, and with much less snark.
FreeBSD does not use bash for /bin/sh
But that doesn't stop a sysadmin from changing that behavior, just as Unbuntu defaulting to Bash didn't stop me from swapping it our in favor of Dash. Just a matter of deleting the old binary and symlinking to the new one.
Apple's Darwin kernel was not forked from FreeBSD.
Oh, but it was! In fact, Darwin 7.0 (OSX 10.3) brought Darwin's BSD layer back in sync with FreeBSD 5. There was, indeed, a lot of reimplementation at the kernel level, and most of the userland tools had many parts rewritten as well, but your own source confirms what I have said. It confirmed it before I posted it originally, as well. In case that's not enough, here's another, and another, and, for good measure, one more, though that last one only mentions the use of BSD's userland components.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Ah. They do have an update for that one. Apple didn't release the update through their normal Software Update mechanism because users aren't likely to be affected by it unless they're fairly advanced server users, but they did release a software update for it about two weeks ago. You can download it here.
Check out my sci-fi/humor trilogy at PatriotsBooks.
If you read the article (even the summary) you can see this isn't about tricking an admin into running a script. This is about a script already set to say, list a set of directories and do something per directory, but if a user names a directory FOO&BAR the script will interpret BAR as a command instead of input.
If a normal user has read access to a maintenance script to know that this is possible, you've already failed.
If your maintenance script doesn't enclose paths and variables containing them with quotation marks, you've already failed.
There's a reason MS isn't going to patch it - the problem is in your scripts.
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. . . .
Fortunately, nobody in the industry listens to crackpots like you.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5, OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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
Heh, looks like they did push an update for Yosemite on the 30th, too bad it's incomplete: Still vulnerable to exploit 7 on this page.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
So surprisingly few competently written applications do this; GNU dhcpd was one, I'll give you that if you can give me another.
A Leopard (Mac OS X v.10.5.8) web server (Apache) I admin was defaced a few days after the exploit was announced.
Totally my fault for not immediately securing BASH, but yeah, I'm pretty sure the cgi scripts authored by MovableType (3.x) make calls to /bin/sh.
I do consider MovableType to be competently written. The reality is that the Shellshock vulnerability was something no one was really thinking about and it took many admins and even highly technical groups of people by surprise.*
* Whatever you think of Yahoo! their engineers and admins are highly technical. Shellshock is just a very nasty bug.
blog
You would have had to build a patched Bash from scratch on that system to secure it, as Apple only released patches for 10.7-10.9. Even if you were running a more recent version of OSX, you'd still have had to build it yourself to patch it *in time*. I'm really disappointed in Apple's response to this.
I never said no competently written code was affected, just that examples are exceedingly rare. Moreso, Toreo asesino's example was an application breaking as a result of patching this vulnerability, which would seem to indicate that said application was exploiting the vulnerability in the first place; zero competently written applications do that.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Oh, but it was! In fact, Darwin 7.0 (OSX 10.3) brought Darwin's BSD layer back in sync with FreeBSD 5. There was, indeed, a lot of reimplementation at the kernel level, and most of the userland tools had many parts rewritten as well, but your own source confirms what I have said. It confirmed it before I posted it originally, as well. In case that's not enough, here's another, and another, and, for good measure, one more, though that last one only mentions the use of BSD's userland components.
None of those sources say that Darwin was forked off of FreeBSD kernel. You must realize that a fork implies a shared root source tree, copying subsystems does not qualify as a fork. They do qualify as forks of the specific subsystems, but not the kernel.
That said, I've never been bothered to look at either FreeBSD or Darwin kernel sources, so for all I know FreeBSD might be based on AmigaOS.
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*
Darwin, the core of Apple OS X, includes a virtual file system and network stack derived from the FreeBSD virtual file system and network stack
The network stack and VFS are kernel components. Other than that, though, you are correct, Darwin's kernel is XNU. But, wait a minute...
Originally developed by NeXT for the NeXTSTEP operating system, XNU was a hybrid kernel combining version 2.5 of the Mach kernel developed at Carnegie Mellon University with components from 4.3BSD and an Objective-C API for writing drivers called Driver Kit.
It seems that XNU is derived from BSD, alongside components from two other kernels.
After Apple acquired NeXT, the Mach component was upgraded to 3.0, the BSD components were upgraded with code from the FreeBSD project and the Driver Kit was replaced with a C++ API for writing drivers called I/O Kit.
Specifically, FreeBSD, after Apple took it over.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Windows has its own version of shellshock in CMD.EXE C:\Usersl>set foo=bar^&ping -n 1 google.com
C:\Usersl>echo %foo%
bar
Pinging google.com [74.125.228.105] with 32 bytes of data:
Reply from 74.125.228.105: bytes=32 time=8ms TTL=250
Ping statistics for 74.125.228.105:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 8ms, Average = 8ms
C:\Users>
Unlike Linux, I don't think this has been patched.
"Be grateful for what you have. You may never know when you may lose it."
Holy shit if that's legit it's fucking amazing... booting my Win dev box now
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Hahahahahaha that's awesome! Now, does IIS pass headers along to CGI scripts the same way Apache does?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
$ echo "" > "-rf"
$ rm *
It doesn't help that the default way the shell processes filenames through glob patterns and command line tab-completion can leave you vulnerable to these kinds of issues.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
... 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.
does IIS pass headers along to CGI scripts the same way Apache does?
Are you fucking kidding? You get them out of a collection that's a property on the request object. They aren't shat into arbitrary fucking shell environment variables, like someone's freshman year CompSci project. Grow up!
I believe that it is the CGI specification that requires parameters to be passed as environment variables. So if you use CGI on IIS it should work the same way.
That would not trigger this issue, however, as it requires some script to expand the environment variable and it is not an automatic braindead expansion like in bash. The most common environment variables to be expanded %WINDIR%, %USERNAME% and the like. Not ever have I seen someone write %HTTP_USER_AGENT% or any other %HTTP_*% expansion. There's no systemic failure as with bash Shellshock.
But to be fair, it *does* look like an injection vector. Yes, GGP blatantly ignored that the claim I made was about PowerShell - not cmd.exe - but there seems to be an issue, and it just reinforces my point that shells (i.e. Windows shells included) that conflate text and instructions are error prone by default.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
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();
I'm not seeing another post from you in this thread... What claim did you make? I think we're in agreement, though; by necessity, shells give you all kinds of ways to hang yourself, most of which are in o way obvious to an unseasoned user. That's just the price of the added power and control, and it comes with a responsibility to learn your tools and lear and afollow best practices when developing on or for an environment that makes use of a shell, whether you're using that shell directly or not. Best practices, like sanitizing your inputs, mitigate this on all platforms.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
...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.