Can we go straight to the part where this is disabled behind a --insecure flag and everyone can spend a release cycle migrating untrusted input handling to languages which were designed for it?
languages which were designed for [untrusted input handling ]
Which languages would those be? There are a few languages with a concept of "taint" (Perl, Ruby), but I've never actually seen a language where everywhere untrusted input could come from actually starts tainted, and every secure function actually disallows tainted input. Especially where third-party-native-FFI library calls are involved.
There's an argument that we should be making an effort to add something like Perl's taint mode (which predates the web by half a decade!) or the stronger variants in some academic languages everywhere but even that's overkill for this class of bugs.
The problem here, as anon1385 pointed out is that shells in general, and Bash in particular, were designed to execute things and maintained at best weak separation between code and data – in no small part because the concept originated 40 years ago when computing was a much more trusted place and network connections were rare and not seen as a conduit for never-ending attacks. As a class, makes shells a bad idea for anything which crosses a privilege boundary; almost any normal language would avoid this particular exploit.
Well it's pretty unusual to write a Java program that accidentally parses, compiles and runs a given string as Java code instead of just treating it as data.
Shells are designed primarily as human interfaces. They try quite hard to execute data they receive, because when used interactively that is what you want. Passing around data that you don't want to be executed involves a lot of careful escaping because everything is done in-band. That's why the history of shell scripting contains countless examples of people accidentally executing file names, abuse of control characters and things like that.
Comments
Can we go straight to the part where this is disabled behind a --insecure flag and everyone can spend a release cycle migrating untrusted input handling to languages which were designed for it?
Which languages would those be? There are a few languages with a concept of "taint" (Perl, Ruby), but I've never actually seen a language where everywhere untrusted input could come from actually starts tainted, and every secure function actually disallows tainted input. Especially where third-party-native-FFI library calls are involved.
There's an argument that we should be making an effort to add something like Perl's taint mode (which predates the web by half a decade!) or the stronger variants in some academic languages everywhere but even that's overkill for this class of bugs.
The problem here, as anon1385 pointed out is that shells in general, and Bash in particular, were designed to execute things and maintained at best weak separation between code and data – in no small part because the concept originated 40 years ago when computing was a much more trusted place and network connections were rare and not seen as a conduit for never-ending attacks. As a class, makes shells a bad idea for anything which crosses a privilege boundary; almost any normal language would avoid this particular exploit.
Well it's pretty unusual to write a Java program that accidentally parses, compiles and runs a given string as Java code instead of just treating it as data.
Shells are designed primarily as human interfaces. They try quite hard to execute data they receive, because when used interactively that is what you want. Passing around data that you don't want to be executed involves a lot of careful escaping because everything is done in-band. That's why the history of shell scripting contains countless examples of people accidentally executing file names, abuse of control characters and things like that.