For some reason, there was a brief spike in security vulnerability reports related to a developer tool which has a specific file type for defining startup macros. When you ran the developer tool and installed a startup macro, the reports said that you could trigger a hang or a crash in the tool, which is a denial of service or potential arbitrary code execution.
Startup macros are already known to be dangerous because they are basically a miniature scripting language, and one of the commands in the miniature scripting language is capable of launching external processes with arbitrary command lines. It’s so dangerous that if you try to open it, the program first makes you acknowledge the danger.
In other words, this file is equivalent to code.
If you want to attack somebody with this file, you don’t have to play fuzzing games and prime the target address space with just the right kind of heap spray or sequence of allocations, so that you can deliver your crafted file that triggers an exploitable crash. There’s no need to go to all that effort. All you have to do is put your exploit directly in the macro file as a command line!
It’s like saying that you found a bug in the batch file parser that, with effort, could lead to arbitrary code execution. You already have arbitrary code execution because you’re a batch file. Instead of playing sneaky games with the batch file parser, just put the command you want to run in the batch file.
The people filing security reports against the developer tool had to click “OK” to get past the warning dialog that said, “Clicking OK may lead to arbitrary code execution.” And then they were upset that there was the potential for arbitrary code execution.
My thought about this: Some people might try to review the macro file before installing it. And in that case, using a sneaky way would be more likely to get past the review.
Maybe so. But it’d probably be a good idea to fix the reported vulnerability anyway since someday the startup macro format might be changed to no longer allow for arbitrary code execution, and then you’d have a serious vulnerability on your hands.
It’s worth treating the report as a bug report – presumably the startup macro runtime is not meant to hang or crash, but to execute the startup macro.
But it’s not a security vulnerability, because it relies on you already having permission to do anything you want to do with the privileges of the runtime. There’s no security boundary being crossed, so it’s merely a serious bug, and not a security flaw.
How do you protect against an in-process hang or crash? Isn’t that solving the Halting Problem? (And even if you detect an in-process hang or crash, how do you recover?) (If your answer is “Run the macro in another process”, then you missed the point of the macro in the first place, which is to preconfigure the current process.)
It depends on the form the hang or crash takes. If it's "when I execute the equivalent of the C code `for(;;) {}`", it hangs", then the only reasonable resolution is "don't do that then".
If it's "if I concatenate two large strings together, I overflow a statically allocated buffer in the runtime and cause a crash", then it's a bug that needs fixing - input to the runtime shouldn't cause a crash.
In both cases, though, because you're not moving across a security barrier as you do this, you're not finding a security vulnerability - it's a bug.
And I didn't suggest...
The issue in this specific case is that the startup macro can set a “run this external program when X occurs” option. (Think “set EDITOR=”.) Naturally, this means that when X occurs, the startup macro can run an arbitrary program. But that’s the whole point of the startup macro: So it can configure your environment to suit your preferences.
Correction: it would probably be a good idea to fix the reported vulnerability when and if you also remove arbitrary code execution. Not before.