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 reminds me of Raymond Chen's oft-used Hitchhiker's quote: "It rather involved being on the other side of this airtight hatchway."
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.
Trying to become famous by taking photos. Visit my homepage please.
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();
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."