Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Programming Windows

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.
This discussion has been archived. No new comments can be posted.

How Poor Punctuation Can Break Windows

Comments Filter:
  • oblg xkcd (Score:1, Funny)

    by Anonymous Coward

    We call him Little Billy Tables.

  • by Anonymous Coward

    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.

    • Re: (Score:3, Funny)

      by Munchr ( 786041 )
      This reminds me of Raymond Chen's oft-used Hitchhiker's quote: "It rather involved being on the other side of this airtight hatchway."
      • Re:Yawn (Score:5, Insightful)

        by nmb3000 ( 741169 ) on Saturday October 11, 2014 @01:36PM (#48120249) Journal

        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.

        • $ 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.

          • by Anonymous Coward

            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

    • by drolli ( 522659 )

      Moreover, that missing quotation marks in scripted languages are a problem is basic knowledge.

  • by jones_supa ( 887896 ) on Saturday October 11, 2014 @11:56AM (#48119905)
    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.
    • by bruce_the_loon ( 856617 ) on Saturday October 11, 2014 @12:04PM (#48119949) Homepage

      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.

      • by Richy_T ( 111409 )

        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

    • 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)

    by sqlrob ( 173498 ) on Saturday October 11, 2014 @12:09PM (#48119965)

    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.

    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.

    • by Anonymous Coward

      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.

      • by sqlrob ( 173498 )

        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.

  • ... in filenames. They are and were fundamentally incompatible with DOS-based shells or anything derived from them.

    • by sqlrob ( 173498 )

      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.

      • by tlhIngan ( 30335 )

        Heck, there's a version of iTunes on Mac that would wipe your drive if you had a space in the volume name.

        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).

        • 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.

  • by QuietLagoon ( 813062 ) on Saturday October 11, 2014 @01:30PM (#48120227)
    If the admin runs a buggy script on a system, it is possible to jeopardise the integrity of that system!!!

    .
    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.
  • 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."

  • 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.

    • Never trust any user or environment supplied stuff, always validate everything.

      Signed,

      Little Bobby Tables

  • 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

  • ... 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.

  • ...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)

A complex system that works is invariably found to have evolved from a simple system that works.

Working...