How Poor Punctuation Can Break Windows 94
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.
oblg xkcd (Score:1, Funny)
We call him Little Billy Tables.
Re:oblg xkcd (Score:5, Informative)
Actually, it's Bobby Tables [xkcd.com]
Re: (Score:1)
+++NO CARRIER
Re: (Score:1)
Ideally you weren't running Apache or Nginx as root.
Re: (Score:1)
Re: (Score:2)
Reading's over rated if all OP wanted to do was rant and dump on Linux...
Re: (Score:2)
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.
Re:Shellshock is way worse (Score:5, Insightful)
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.
Re:Shellshock is way worse (Score:4, Interesting)
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.
Re:Shellshock is way worse (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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 w
Hilarious (Score:2)
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.
Re: Hilarious (Score:2)
I don't have a dog in this race, I use Windows, OSX, and Linux in roughly equal proportions. More people run POSIX layers on their Windows servers than you likely realize; in the hosting world, you give your users what they want, and users want to run that prewritten PHP script that relies on some UNIX userland element that Windows doesn't pro
Re: (Score:2)
I use Windows, OSX, and Linux in roughly equal proportions
Which probably means I use Windows where I need Windows and I use Linux where I need Linux; OSX is my desktop of choice at the moment, though that is subject to change, as it has changed a number of
Re: (Score:2)
CMD is a skin-deep DOS emulator used by approximately zero applications these days, unlike say Apache & bash. So again, you attempts to equate risks here really seem desperate and again, most amusing.
Also if I'm not mistaken POSIX in Windows has been depreciated for a while, albeit still possible to install. Welcome to the crazy world of PowerShell my friend!
Keep flogging that dead horse though - surely it's got some life it in yet! You're right; ShellShock really is as bad a ball-ache in Windows as *ni
Re: (Score:2)
Did I say both are equally vulnerable, or are you making shit up in an attempt to discredit me?
Of course, I'm repeating this in response to this bit of snark:
You're right; ShellShock really is as bad a ball-ache in Windows as *nix, no really!
It was originally said in response to this bullshit:
I love the fact you try to equate Windows and Linux for this epic bug as if they're both as vulnerable.
In case you missed the question the first two times, here it is again:
Did I say both are equally vulnerable, or are you making shit up in an attempt to discredit me?
And, in case you decide to say something along the lines of "Yes, you said both are equally vulnerable" I might ask that you quote me.
PROTIP: You won't be able to, because I never said it. If you want to win an argument with me, you have to attack what I'm a
Re: (Score:2)
Oh alright, here you go then:
...since Bash can run on *anything*, that makes it and "anything running Bash" issue, including your precious Windows...
So..."Did I say both are equally vulnerable" - why yes; yes you did!
Then there was the whole "look, cmd.exe can't parse stuff either correctly" - that's also kinda along the same "lol Windows is just as bad" lines.
And we both know ShellShock is a particularly epic *nix only issue, really, even if technicaly....possibly it could be bad on Windows too....well not really. Get over it; it happens. Just this time Windows comes out on top. Your defensiveness and keenness at mitigatin
Re: (Score:2)
...since Bash can run on *anything*, that makes it and "anything running Bash" issue, including your precious Windows...
Well, yes, I stated the fact that anything running Bash is vulnerable; I never denied that. Where, dear sir, did I state that they were equally vulnerable? We're back to "you can't quote it because I never said it", despite what you claim.
Shellshock is a fixed issue on 'nix systems, for anyone keeping their system up to date. Well, except for OSX Yosemite beta testers, for whom an incomplete patch was released on 9-30; still vulnerable to one of seven known exploits. Windows systems that are vulnerable,
Re: (Score:2)
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
Re: (Score:1)
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 [wikipedia.org], and another [wired.com], and, for good measure, one more [stackexchange.com], 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.
Re: (Score:2)
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 [wikipedia.org]. 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.
Re: (Score:1)
For the record, Yahoo, running FreeBSD, was compromised via Shellshock.
No, not really [ycombinator.com]:
Earlier today, we reported that we isolated a handful of servers that were detected to have been impacted by a security flaw. After investigating the situation fully, it turns out that the servers were in fact not affected by Shellshock.
Also, are you sure that Yahoo is running FreeBSD on every server? I can't find anything more recent than this piece from 2011, but it would appear that 75% of Yahoo’s Web sites and services run on Linux" [zdnet.com].
RT.
Re: (Score:2)
Re: Shellshock is way worse (Score:1)
it is GNU BASH Shellshock that is the common component. There, fixed it for Mr Stallman.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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 [apple.com].
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Fortunately, nobody in the industry listens to crackpots like you.
Re:Shellshock is way worse (Score:5, Informative)
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.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:3)
News at 11 (Score:1)
Vulnerable script written by incompetent administrator leads to privilege escalation exploit. News at 11.
Yawn (Score:1)
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.
Re: (Score:3, Funny)
Re:Yawn (Score:5, Insightful)
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.
Re: (Score:2)
$ 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.
Separation of Code and Data (Score:1)
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 o
Re: (Score:2)
Moreover, that missing quotation marks in scripted languages are a problem is basic knowledge.
Problematic for Linux too (Score:3)
Re:Problematic for Linux too (Score:4, Insightful)
At least you can diagnose and fix issues with shell scripts with vi and a bit of knowledge. Try that with a binary blob that stores its data in a binary store.
Re: (Score:2, Insightful)
At least you can diagnose and fix issues with shell scripts with vi and a bit of knowledge. Try that with a binary blob that stores its data in a binary store.
Well with the source code of the binary blob, you could diagnose and fix issues with vi and a bit of knowledge.
Re: (Score:2)
If you could point us to the source code of the Windows services manager engine, we'd appreciate it. :)
Re: (Score:3)
There are many interpreted languages for which this is also true. The problem is with the laxness of the shell scripting interpreters which have been stretched way beyond simple task automation. Though even the simple task automation has issues.
It's understandable, having to rm 'file.txt' seems like an imposition when it's clear you're talking about just file.txt but as soon as you start having ambiguities caused by things which have semantic meaning to the shell being allowed in file names, you open things
Re: (Score:2)
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.
Do you know how long it takes to fork a process? You clearly don't otherwise you wouldn't begin to mention it, let alone begin to talk about it.
Quotes (Score:5, Insightful)
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.
Re: (Score:1)
At least it's not possible with filenames.
Did someone actually verify that?
IIRC you could create filenames containing characters illegal in win32 through the POSIX subsystem (SFU/SUA/whateveritscalledthisyear) on a NTFS volume... wouldn't be all that surprised if that also included directories with "s in their name.
Re: (Score:2)
I wonder how many still have that subsystem, since it became optional. But then again, that's something that might reasonably be installed on a server. If I had it installed, I'd give it a try. .Net definitely fails on a normal system, I don't feel like fudging around enough to try NtCreateDirectory.
Windows should never have allowed spaces... (Score:1)
... in filenames. They are and were fundamentally incompatible with DOS-based shells or anything derived from them.
Re: (Score:2)
So? Same problem exists in bash and friends too. Heck, there's a version of iTunes on Mac that would wipe your drive if you had a space in the volume name.
Re: (Score:3)
That seems like something that would've been caught early on - given the default volume name of most Macs is "Macintosh HD".
And one reason you have "Program Files" in Windows is just that - to break scripts and other tools who can't handle spaces. Likewise "Documents and Settings" (renamed Users since Vista).
Re: (Score:2)
And one reason you have "Program Files" in Windows is just that - to break scripts and other tools who can't handle spaces. Likewise "Documents and Settings" (renamed Users since Vista).
Except that they appear as Progra~1 and Docume~1 to programs that don't support long filenames.
OMG, this is AWFUL!!! (Score:3)
.
I am shocked!! SHOCKED, I say!!!!!!
Have /. really sunk so low that hyped-up articles like the one quoted are now newsworthy?
Linux shell vulnerabilities (Score:2)
0/10 wouldn't read again.
Disclaimer: I run a BSD and my bash sure as hell was affected.
Eats, shoots and leaves. (Score:2)
Misplaced punctuation can cause trouble. From: Eats, shoots and leaves [wikipedia.org]:
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."
Assumptions (Score:2)
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.
Re: (Score:2)
Never trust any user or environment supplied stuff, always validate everything.
Signed,
Little Bobby Tables
print0 (Score:2)
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 entrench
That's actually very old... (Score:2)
... 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.
That's not a solution (Score:2)
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.
at least bash will never execute variables... (Score:2)
...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)