Yeah, by not giving people a commandline worth anything in the first place. But you are right: MS realizes their customers are incompetent, immature whiners that would blame MS is they used MS products to shoot themselves in the foot. So the function to shoot anything was removed.
You have noting to contribute but could not keep your mouth shut?
If you do not do input sanitization, you are screwed anyways. If you do input sanitization, this is not a security problem anymore. Stop trying to fix problems in the wrong place.
You do not seem to understand what this discussion is about. It is about security, not safety. And when it is about security, the wildcards come from somewhere else and need to be sanitized in that path. A user doing this to himself is just stupid, but not a security issue. (And yes, as somebody that once had to recompile bash to get a longer commandline-buffer, I know exactly where the expansion happens.)
And not everybody has any business writing security-critical code. You are asking for the illiterate to be allowed and encouraged to write poetry. That cannot ever work.
It may be counter-intuitive for people that have very little experience with a UNIX commandline. All others did run in the issue at some time that they could create, but not easily delete a filename "-v" or the like. But people with very little UNIX commandline experience have zero business writing security critical software that uses the commandline tools!
This is a complete non-issue. Incompetent people will usually screw security up and this is just one of the countless ways to do it.
That is complete BS. Preventing users from doing things they legitimately want to do is not a valid approach to securing untrusted interfaces. The valid valid way is to sanitize the untrusted input before using it and only a complete moron will pass a wildcard from an untrusted source, unless it cannot do any harm where it is going.
Really, this is well-known, non-surprising and will not happen to anybody with a security mind-set. Of course it will happen in practice. But there are quite a few other variants of code injection (which this basically is) that the same people will get wrong. Complete input sanitisation is mandatory if you need security. I mean, even very early Perl-based CGI mechanisms added taint-checking specifically for things like this. If people cannot be bothered to find out how to pass parameters from an untrusted source securely, then they cannot be bothered to write secure software.
The fix is not to change the commands. The fix is to exchange people that mess things this elementary up against people that actually understand security. Sorry, you cannot have developers that are cheap and competent at the same time and even less so when security is important.
No. You cannot turn these things into CPUs of any meaningful power level.
Asynchronous design is not feasible complexity-wise. It is one of these "magic" things that crop up time and again but never work out.
The problem is that basically all software is connected to the Internet in some way these days and a lot of the makers of software do not qualify as part of the "security industry" and really have no clue and no interest in making things secure.
Indeed. All this is really just an elaborate intelligence test. Seems to me that most people fail and that includes the particle-physicists...
I don't think there is a risk. Unless all those black holes are what explains the Fermi-Paradox...
LHC live-cam: http://www.youtube.com/watch?v...
Function reject.