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.
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."
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.
Actually, it's Bobby Tables
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?
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
/)
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.
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.
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).
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*
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.