So therefore we conclude what? Massive copryight infringement should be allowed because someone sold an extra 5 CDs? If someone wants more exposure, then they can grant permission. It should never be assumed a-priori that you have permission to take without asking.
More proof that you don't need to be smart or have common sense to be a CEO or CTO. Sending out emails to every employee demanding that they break the law? These are the sorts of boneheaded mistakes you expect to see on the "stupid criminals of the month" column.
Though I am worried about Anonymous Coward's mental health, as he's always publicly fighting with himself (or herself, that part seems seems to change over time as well).
How so? Deaths from the nuclear accident, even accounting for very long term results, will be very minor compared with the loss of life from the earthquake itself.
It's not just the US. Look around. Even in major "enlightened" nations you see all sorts of idiocy up at the top. Now the US may have its faults but having EU countries point at the US and laugh is just hypocrisy.
Even when they present both sides, it is much more interesting and informative if they're not on at the same time arguing with each other. A local radio call in show has both formats, and when a full hour is given to one candidate, then the next day is the other candidate, you learn a lot. But them both on debating and arguing then you learn nothing.
At least NPR's Science Friday never had the "now for the opposing argument" format.
Don't forget social media, with "seven foods that kill cancer". Wait, that stuff shows up on news broadcasts too.
Also the advertisements. Head-On: Apply Directly to Forehead. or the cold remedy promoted as "invented by a teacher" which is code for "no untrustworthy scientists were involved".
I like google+, but I hate having a useless youtube forced on me. Google+ is where friends are. Don't know about facebook, never tried it, probably never will.
We have a constitutional right to privacy now? I thought it was still a point of debate but had not been firmly decided by the courts (though there are good cases to be made for it on certain grounds, such as 9th amendment).
Depends upon where you are. When I was growing up in the hot central valley, a swimming pool absolutely added to the home's value (not the above ground type though).
Isn't the property tax most places based upon the value of the home? So adding a pool will increase the value of the home. Normally though there's a tax assessor that goes around and should be looking at every lot and assign a new assessed value, though in practice I think they just google if the prices in the neighborhood have gone up or down.
A lot of government in the US works by assuming most people are generally lawful, and they're not going to just start adding rooms onto the house without filing the paperwork first. For taxes they do some random audits on a small subset. This generally works, those breaking the rules aren't too many and don't get away with it for too long (often neighbors turn them in, they get very nosy when construction starts). But this all breaks down if you have wholesale cheating going on, such as Greeks with taxes awhile back, and perhaps these Argentinean neighborhoods.
It looks like a side effect of how it passes exported functions to sub shells. The only communication mechanism for talking to the subshell is the environment. So these are implemented by putting the function in an environment variable, then the subshell on startup looks at every variable to see if it looks like a function, and if so tries to turn them into a function. The snag then is that it does this by actually executing what's in the variable instead of fully parsing it first.
Mistake here, the problem I saw with SHELL screwing stuff up wasn't with system(), real unices use a hardcoded path there. I've been on too many embedded systems that try to be unix-like.
I take some of this back, I was thinking of a non-unix system that had problem. Most real unixes have a hard coded/bin/sh, and most do not arbitrarily execute code if in non-interactive mode (except for BASH_ENV).
On the other hand it's a very straight forward and not too large function to do exactly the same thing as system() for an absolute path name with fixed arguments.
Ya you're right for the most part. I was confused by the : const char *argp[] = {"sh", "-c", NULL, NULL}; Except that the first arg there is just the name being used, not the actual file to be executed, which was my mistake.
However I do recall some unixlike-but-not-unix systems that used other methods to find the shell because is wasn't always in a fixed location.
I don't think the early people did think it out, however even if they had some security expert thinking of all the ways it could go wrong I'm not sure it would stick out as a hole. After all nothing as far as they knew executed the contents of arbitrary environment variables especially not ones with names that they controlled. Even if they were really paranoid and decided not to use system(), or didn't use it for performance reasons, there were still perl scripts underneath that went and called system() behind the scenes...
I bet if you took a time machine to last week that many web security experts if asked if passing data in an environment variable is safe or not would think it was insecure, assuming the program that parsed the data took care.
You also need some form of data originating outside of the system that gets shoved into an environment variable. That's why CGI was the first obvious suspect for being exploited.
Most embedded systems aren't using bash though, not the small ones like routers anyway. If they're unix based they'll probably have ash or busybox. For ultrasound machines, which I've worked on, if they're linux they might have bash but I would think they'd use something else to save space. Even if bash they'd still need some other local program that uses system() or the like, plus an environment variable based on data from the outside world.
Is it just/bin/sh? A lot of systems use just "sh" and so will use PATH to find the correct shell to use, so you have to watch out for/usr/local/bin,/opt/local/bin, and other things that are often earlier in the PATH search.
This is not the whole thing. The bug is there even if you're passing known constant strings to system(), ie, there is no input to sanitize. I do agree though that the fault is not only with bash, but from using system() as well. I've seen problems with it before, though stuff any good CGI design would avoid.
(For example, what happens if you make sure/bin/sh is a good patched bash, or it's dash instead, but then/usr/local/bin shows up first in PATH and contains an old crusty version of bash and sh, which one does system() use? So a good system needs to make sure PATH is set to a known and valid value.)
However this does not mean that all other shells are perfectly safe or that there's not some other way to exploit them in the future. Basically using system("somestuff") is not the fastest or safest way to execute a command, though it is the most convenient way.
If a setuid program is dumb enough to use system() you can do a lot of nasty stuff if you're on the local machine. Setting SHELL to something other than the default, using BASH_ENV, stuff like that. In other words, people have known that system() is not necessarily safe for a long time.
I agree that it was unexpected that a static call to system() using a constant known string would have a vulnerability. However some people have also advised against using system() directly for a long time. Definitely I've seen bugs before that were traced back to someone having something unusual stuck in their.profile, or things work ok when the dev's shell was csh but then broke when run in production, etc.
Definitely for a very long time I have seen some people write simple functions to get a replacement for system() that's faster to start or more consistent in usage.
Slashdot Mirror
So therefore we conclude what? Massive copryight infringement should be allowed because someone sold an extra 5 CDs? If someone wants more exposure, then they can grant permission. It should never be assumed a-priori that you have permission to take without asking.
More proof that you don't need to be smart or have common sense to be a CEO or CTO. Sending out emails to every employee demanding that they break the law? These are the sorts of boneheaded mistakes you expect to see on the "stupid criminals of the month" column.
Though I am worried about Anonymous Coward's mental health, as he's always publicly fighting with himself (or herself, that part seems seems to change over time as well).
How so? Deaths from the nuclear accident, even accounting for very long term results, will be very minor compared with the loss of life from the earthquake itself.
It's not just the US. Look around. Even in major "enlightened" nations you see all sorts of idiocy up at the top. Now the US may have its faults but having EU countries point at the US and laugh is just hypocrisy.
Even when they present both sides, it is much more interesting and informative if they're not on at the same time arguing with each other. A local radio call in show has both formats, and when a full hour is given to one candidate, then the next day is the other candidate, you learn a lot. But them both on debating and arguing then you learn nothing.
At least NPR's Science Friday never had the "now for the opposing argument" format.
Don't forget social media, with "seven foods that kill cancer". Wait, that stuff shows up on news broadcasts too.
Also the advertisements. Head-On: Apply Directly to Forehead. or the cold remedy promoted as "invented by a teacher" which is code for "no untrustworthy scientists were involved".
I like google+, but I hate having a useless youtube forced on me. Google+ is where friends are. Don't know about facebook, never tried it, probably never will.
Hey India, can we get some extra quotas for visas for out of work American space scientists?
We have a constitutional right to privacy now? I thought it was still a point of debate but had not been firmly decided by the courts (though there are good cases to be made for it on certain grounds, such as 9th amendment).
Depends upon where you are. When I was growing up in the hot central valley, a swimming pool absolutely added to the home's value (not the above ground type though).
Isn't the property tax most places based upon the value of the home? So adding a pool will increase the value of the home. Normally though there's a tax assessor that goes around and should be looking at every lot and assign a new assessed value, though in practice I think they just google if the prices in the neighborhood have gone up or down.
A lot of government in the US works by assuming most people are generally lawful, and they're not going to just start adding rooms onto the house without filing the paperwork first. For taxes they do some random audits on a small subset. This generally works, those breaking the rules aren't too many and don't get away with it for too long (often neighbors turn them in, they get very nosy when construction starts). But this all breaks down if you have wholesale cheating going on, such as Greeks with taxes awhile back, and perhaps these Argentinean neighborhoods.
It looks like a side effect of how it passes exported functions to sub shells. The only communication mechanism for talking to the subshell is the environment. So these are implemented by putting the function in an environment variable, then the subshell on startup looks at every variable to see if it looks like a function, and if so tries to turn them into a function. The snag then is that it does this by actually executing what's in the variable instead of fully parsing it first.
Mistake here, the problem I saw with SHELL screwing stuff up wasn't with system(), real unices use a hardcoded path there. I've been on too many embedded systems that try to be unix-like.
I take some of this back, I was thinking of a non-unix system that had problem. Most real unixes have a hard coded /bin/sh, and most do not arbitrarily execute code if in non-interactive mode (except for BASH_ENV).
On the other hand it's a very straight forward and not too large function to do exactly the same thing as system() for an absolute path name with fixed arguments.
Ya you're right for the most part. I was confused by the : const char *argp[] = {"sh", "-c", NULL, NULL};
Except that the first arg there is just the name being used, not the actual file to be executed, which was my mistake.
However I do recall some unixlike-but-not-unix systems that used other methods to find the shell because is wasn't always in a fixed location.
I don't think the early people did think it out, however even if they had some security expert thinking of all the ways it could go wrong I'm not sure it would stick out as a hole. After all nothing as far as they knew executed the contents of arbitrary environment variables especially not ones with names that they controlled. Even if they were really paranoid and decided not to use system(), or didn't use it for performance reasons, there were still perl scripts underneath that went and called system() behind the scenes...
I bet if you took a time machine to last week that many web security experts if asked if passing data in an environment variable is safe or not would think it was insecure, assuming the program that parsed the data took care.
You also need some form of data originating outside of the system that gets shoved into an environment variable. That's why CGI was the first obvious suspect for being exploited.
Most embedded systems aren't using bash though, not the small ones like routers anyway. If they're unix based they'll probably have ash or busybox. For ultrasound machines, which I've worked on, if they're linux they might have bash but I would think they'd use something else to save space. Even if bash they'd still need some other local program that uses system() or the like, plus an environment variable based on data from the outside world.
Is it just /bin/sh? A lot of systems use just "sh" and so will use PATH to find the correct shell to use, so you have to watch out for /usr/local/bin, /opt/local/bin, and other things that are often earlier in the PATH search.
This is not the whole thing. The bug is there even if you're passing known constant strings to system(), ie, there is no input to sanitize.
I do agree though that the fault is not only with bash, but from using system() as well. I've seen problems with it before, though stuff any good CGI design would avoid.
(For example, what happens if you make sure /bin/sh is a good patched bash, or it's dash instead, but then /usr/local/bin shows up first in PATH and contains an old crusty version of bash and sh, which one does system() use? So a good system needs to make sure PATH is set to a known and valid value.)
Although this vulnerability has been there for two decades...
However this does not mean that all other shells are perfectly safe or that there's not some other way to exploit them in the future. Basically using system("somestuff") is not the fastest or safest way to execute a command, though it is the most convenient way.
If a setuid program is dumb enough to use system() you can do a lot of nasty stuff if you're on the local machine. Setting SHELL to something other than the default, using BASH_ENV, stuff like that. In other words, people have known that system() is not necessarily safe for a long time.
I agree that it was unexpected that a static call to system() using a constant known string would have a vulnerability. However some people have also advised against using system() directly for a long time. Definitely I've seen bugs before that were traced back to someone having something unusual stuck in their .profile, or things work ok when the dev's shell was csh but then broke when run in production, etc.
Definitely for a very long time I have seen some people write simple functions to get a replacement for system() that's faster to start or more consistent in usage.