5 ms·

So is it wrong to criticize bad code for being bad if it was written by Mother Theresa? I think that if code is bad, it should be pointed out. Some will take

by clarry 12y ago

So is it wrong to criticize bad code for being bad if it was written by Mother Theresa? I think that if code is bad, it should be pointed out. Some will take it as bashing. Doesn't matter. We all want to run well written, secure software. When you're getting exploited, it doesn't matter if the code was written by a saint.

woutervdb 12y ago
What you're missing here, is that bash wasn't the software with an error. It's like you use ice cubes for building a house, observing your house is melting and then blaming the developers of ice cubes for making such horible building blocks. Ice cubes were never meant to be used to build houses with.
- clarry 12y ago
  > What you're missing here, is that bash wasn't the software with an error. Is the FSF wrong for issuing a statement which says A major security vulnerability has been discovered in the free software shell GNU Bash. The most serious issues have already been fixed, and a complete fix is well underway? I think you missed the news that there's a bug in bash. And if you're making the argument that bash should've not been used in the first place because it's an ice cube or fragile or whatever, then you are with those who make the argument that bash is bad code.
  - woutervdb 12y ago
    I know about Shellshock and I know what it means. However, I think it's wrong to blame bash for the fact that almost everything seems to be vulnerable. Those developers were wrong by using untrusted user input in places where it didn't belong. It's the FSF's responsibility to release a fix simply because the whole world depends on their (the world's) own stupid mistakes when developing their programs.
    - vertex-four 12y ago
      > Those developers were wrong by using untrusted user input in places where it didn't belong. Environment variables are text. So long as you control the name of them, and the name doesn't conflict with any other name in the system, there should be absolutely no issue with putting user input into environment variables. Programs like bash should only be executing things that are explicitly marked as trusted code through a flag that is not contained in the value. Some distros have implemented a patch to this effect already in bash, disallowing bash from treating any environment variable whose name doesn't start with BASH_FUNC_ as anything but text. This resolves every single related vulnerability out there.
      - revelation 12y ago
        So you mean the fix is to add some magic constant that variables now have to start with? I mean, come on, the issue is screaming at you! This is the same basic mistake of using a bunch of string concatenation to build queries for your database. Bash is the shell I use to control my system with, it's made for convenience of the user. If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.
        clarry 12y ago
        > This is the same basic mistake of using a bunch of string concatenation to build queries for your database. Not at all. The string as a query is expected to execute. Environment variables in general are just data and not expected to be executed, even if some of them have special semantics and may indeed be executed.
        vertex-four 12y ago
        > So you mean the fix is to add some magic constant that variables now have to start with? That executable variables have to start with. This is a perfect fix, because attackers can never choose the names of environment variables, because we know that that's a poor idea (anyone who does it is already vulnerable to people setting LD_PRELOAD and similar things). This is simply marking certain variables as executable, while everything else is not. The default assumption, like it or not, is that if you set some random environment variable to some random text, nothing's going to happen. It's been like that since 1993, at the latest. > If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously. Some things end up managing the system - DHCP, for example. It turns out that the shell is really, really good at managing *nix systems. Everyone can understand it, and everyone can figure out how to manage their system with it. The only real alternative would be perl, which nobody wants to code in, and has a greater learning barrier. As for modern web frameworks - of course they shouldn't use CGI, although more because there's better/more performant alternatives than for security reasons. However, you find me a medium/large business which has absolutely no legacy code anywhere.
  - jiggy2011 12y ago
    Think of it this way. Say that a car manufacturer builds a car for city driving and doesn't warrant or recommend it's use for off roading. However it just so happens that the car is tough enough that it makes a good offroader anyway and soon people start to buy the car for the express purpose of offroading even though the manufacturer does not recommend this use. Some time later it becomes apparent that there is a weakness in the braking system that manifests itself after extensive offroad use but not with regular road use, and this becomes the cause of many accidents. The manufacturer then does a recall and refits the cars with an improved braking system more suitable for offroading even though they never intended (and still do not) for people to use it offroad they are just forced to accept this use case.
    - woutervdb 12y ago
      Great explenation. To add to your story: imagine being the car manufacturer, doing this all for free (as in beer) and still having people more or less wishing you dead for building a city car not suitable for offroad use. It simply doesn't add up and makes you feel pretty miserable, I guess.
    - zak_mc_kracken 12y ago
      Except the FSF never said anything like "Please don't use bash for CGI, it's not secure enough". If they had, then they would have to recognize that bash is not secure enough for other uses as well.
      - jiggy2011 12y ago
        Wouldn't that violate freedom 0?
        jeremyjh 12y ago
        How does it violate your freedom to warn you of a serious danger? The fact is they didn't know bash would execute code found in arbitrary application-defined variables. And that is why GNU calls it a bug.
- jameshart 12y ago
  Nobody knew BASH enumerated every environment variable and - depending on its content - maybe evaluated part of it for immediate execution. It wasn't documented and it wasn't expected. It's not part of the expectations people have for a POSIX shell. In your metaphor, it's more like the ice cube manufacturer has been making brick-shaped ice cubes and selling them through building suppliers, and they've been widely used as a building material for many years and the ice cube maker has never said anything about the slight risk of it melting at room temperature. What you're arguing is that bash is not and was never a solid POSIX shell.
spindritf 12y ago
He doesn't think the code is bad. Shellshock is not a critical failure in bash. It is a critical failure in thousands of people who knew a tool so useful that they decided to deploy it far beyond its scope. A tool so resilient that it it did not fall over when everyone deployed against best practices. Everyone knew in the nineties that when you execute a UNIX command with untrusted input, you clear away the environment variables first. Anyone that has untrusted input embedded within a shell script does not know what they are doing. The fact that there is a way to get bash to execute untrusted code is unsurprising. The thing that surprises me is the sheer number of developers who thought it would be otherwise in complete contrast to UNIX parables and common sense. FTFA.
- clarry 12y ago
  And I never said weev thinks the code is bad. I said what he calls "bashing bash" is other people criticizing bash for having bad code.
- vertex-four 12y ago
  > Everyone knew in the nineties that when you execute a UNIX command with untrusted input, you clear away the environment variables first. CGI was standardised in 1997 to use environment variables to pass information into the CGI program. I'm sure software existed before that that does the same - procmail, perhaps? No software that's been touched in the past two decades should assume that the environment variable is safe. Especially not a shell, which gets used for all sorts of network-processing-related things.
  - nailer 12y ago
    Postfix is of a similar age and does exactly as weev says.
jimktrains2 12y ago
No, it doesn't, but like Heartbleed, I've see a lot of backlash against GNU (sometimes via Stallman bashing). That, I believe, is what's being discussed here.
- scott_s 12y ago
  I'm not trying to be sarcastic, this is an honest question: where have you seen the blame against GNU and Stallman related to the bash bug? I ask because I haven't seen it here (thankfully) or anywhere else.
ClashTheBunny 12y ago
I think it's more of a point that if you are using something for free, you should think more in terms of "What did I do wrong to cause this? Who did I not support that put us in this situation?". People pointed out that OpenSSL had a miniscule budget and provided tons of value to the world. Once again, all you can say is mea culpa. Either that or they should be creating alternatives and moving away from poorly written software.
- jiggy2011 12y ago
  Isn't that then an argument against using free software? If the best way to have secure software without being a security expert is to use proprietary software, then that is what we should encourage. FOSS advocates make the opposite argument that FOSS is more secure because there are more eyes on the code.
  - XorNot 12y ago
    Proprietary software gets compromised all the time. In serious ways. A simple example is the sheer number of bank websites which get taken down, and then we all yell at the guy who discovered it to absolutely not disclose it for fear of prosecution. The point is, when FOSS software has a bug, there's no small set of developers who are responsible. It's, in some small way, collectively all our faults. Like in the case of Bash - apparently for 20 years, we never actually checked if environment variables were executable.
    - jiggy2011 12y ago
      Most people are incapable of taking any responsibility for issues in bash or openssl, in fact people who rely on them might not even know they exist , let alone be able to fix them. If you buy something from Microsoft you are paying them to take care of everything from the kernel upwards so that you don't need to worry about the details.
      - gggmaster 12y ago
        You can pay someone to improve open source tools, too.
simonpantzare 12y ago
The problem is not that people call out bad code but that they attack the person who wrote it. I bet that the voices criticizing Stallman now will not praise him for GNU next time they cash in on projects built on it.
- clarry 12y ago
  > The problem is not that people call out bad code but that they attack the person who wrote it If that's happening, I completely agree with you. I was mostly addressing the "bashing bash" part. Because the bashing of bash is what I've seen in the recent discussion. Not the bashing of RMS.
parennoob 12y ago
This is completely missing the point and intent of the article. The author is (IMO, rightly) getting pissed about "technology journalists" at places like Forbes, or bankers at JP Morgan, who will smugly say stuff like, "Oh, there was a really horrible vulnerability in this software, and there's nothing we can do until those incompetent programmers get out a patch" (even if this is not explicitly said, it is often implied in these articles). They completely overlook the fact that a) The source it right there. You think you can do a better job, please fix it and submit a patch upstream. Or post on the bugtracker. b) The reason this is a problem is usually because of lack of sanitization of user input before passing it to bash. So that is your problem, not really bash itself. Use one of the patches out there that disable the "feature" that leads to the bug. How many articles state stuff like "Thousands of organizations over the world use bash, yet no one has discovered this for 22 years. This means a lot of companies are not taking security seriously enough to audit the (open) source of the code they ride on."? Until we start seeing articles that address the complex social and economic aspects of the issue, I don't blame FSF supporters for being pissed at them.

by clarry 12y ago

woutervdb 12y ago

What you're missing here, is that bash wasn't the software with an error. It's like you use ice cubes for building a house, observing your house is melting and then blaming the developers of ice cubes for making such horible building blocks. Ice cubes were never meant to be used to build houses with.

clarry 12y ago
> What you're missing here, is that bash wasn't the software with an error. Is the FSF wrong for issuing a statement which says A major security vulnerability has been discovered in the free software shell GNU Bash. The most serious issues have already been fixed, and a complete fix is well underway? I think you missed the news that there's a bug in bash. And if you're making the argument that bash should've not been used in the first place because it's an ice cube or fragile or whatever, then you are with those who make the argument that bash is bad code.
- woutervdb 12y ago
  I know about Shellshock and I know what it means. However, I think it's wrong to blame bash for the fact that almost everything seems to be vulnerable. Those developers were wrong by using untrusted user input in places where it didn't belong. It's the FSF's responsibility to release a fix simply because the whole world depends on their (the world's) own stupid mistakes when developing their programs.
  - vertex-four 12y ago
    > Those developers were wrong by using untrusted user input in places where it didn't belong. Environment variables are text. So long as you control the name of them, and the name doesn't conflict with any other name in the system, there should be absolutely no issue with putting user input into environment variables. Programs like bash should only be executing things that are explicitly marked as trusted code through a flag that is not contained in the value. Some distros have implemented a patch to this effect already in bash, disallowing bash from treating any environment variable whose name doesn't start with BASH_FUNC_ as anything but text. This resolves every single related vulnerability out there.
    - revelation 12y ago
      So you mean the fix is to add some magic constant that variables now have to start with? I mean, come on, the issue is screaming at you! This is the same basic mistake of using a bunch of string concatenation to build queries for your database. Bash is the shell I use to control my system with, it's made for convenience of the user. If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.
      - clarry 12y ago
        > This is the same basic mistake of using a bunch of string concatenation to build queries for your database. Not at all. The string as a query is expected to execute. Environment variables in general are just data and not expected to be executed, even if some of them have special semantics and may indeed be executed.
      - vertex-four 12y ago
        > So you mean the fix is to add some magic constant that variables now have to start with? That executable variables have to start with. This is a perfect fix, because attackers can never choose the names of environment variables, because we know that that's a poor idea (anyone who does it is already vulnerable to people setting LD_PRELOAD and similar things). This is simply marking certain variables as executable, while everything else is not. The default assumption, like it or not, is that if you set some random environment variable to some random text, nothing's going to happen. It's been like that since 1993, at the latest. > If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously. Some things end up managing the system - DHCP, for example. It turns out that the shell is really, really good at managing *nix systems. Everyone can understand it, and everyone can figure out how to manage their system with it. The only real alternative would be perl, which nobody wants to code in, and has a greater learning barrier. As for modern web frameworks - of course they shouldn't use CGI, although more because there's better/more performant alternatives than for security reasons. However, you find me a medium/large business which has absolutely no legacy code anywhere.
- jiggy2011 12y ago
  Think of it this way. Say that a car manufacturer builds a car for city driving and doesn't warrant or recommend it's use for off roading. However it just so happens that the car is tough enough that it makes a good offroader anyway and soon people start to buy the car for the express purpose of offroading even though the manufacturer does not recommend this use. Some time later it becomes apparent that there is a weakness in the braking system that manifests itself after extensive offroad use but not with regular road use, and this becomes the cause of many accidents. The manufacturer then does a recall and refits the cars with an improved braking system more suitable for offroading even though they never intended (and still do not) for people to use it offroad they are just forced to accept this use case.
  - woutervdb 12y ago
    Great explenation. To add to your story: imagine being the car manufacturer, doing this all for free (as in beer) and still having people more or less wishing you dead for building a city car not suitable for offroad use. It simply doesn't add up and makes you feel pretty miserable, I guess.
  - zak_mc_kracken 12y ago
    Except the FSF never said anything like "Please don't use bash for CGI, it's not secure enough". If they had, then they would have to recognize that bash is not secure enough for other uses as well.
    - jiggy2011 12y ago
      Wouldn't that violate freedom 0?
      - jeremyjh 12y ago
        How does it violate your freedom to warn you of a serious danger? The fact is they didn't know bash would execute code found in arbitrary application-defined variables. And that is why GNU calls it a bug.
jameshart 12y ago
Nobody knew BASH enumerated every environment variable and - depending on its content - maybe evaluated part of it for immediate execution. It wasn't documented and it wasn't expected. It's not part of the expectations people have for a POSIX shell. In your metaphor, it's more like the ice cube manufacturer has been making brick-shaped ice cubes and selling them through building suppliers, and they've been widely used as a building material for many years and the ice cube maker has never said anything about the slight risk of it melting at room temperature. What you're arguing is that bash is not and was never a solid POSIX shell.

spindritf 12y ago

He doesn't think the code is bad. Shellshock is not a critical failure in bash. It is a critical failure in thousands of people who knew a tool so useful that they decided to deploy it far beyond its scope. A tool so resilient that it it did not fall over when everyone deployed against best practices. Everyone knew in the nineties that when you execute a UNIX command with untrusted input, you clear away the environment variables first. Anyone that has untrusted input embedded within a shell script does not know what they are doing. The fact that there is a way to get bash to execute untrusted code is unsurprising. The thing that surprises me is the sheer number of developers who thought it would be otherwise in complete contrast to UNIX parables and common sense. FTFA.

clarry 12y ago
And I never said weev thinks the code is bad. I said what he calls "bashing bash" is other people criticizing bash for having bad code.
vertex-four 12y ago
> Everyone knew in the nineties that when you execute a UNIX command with untrusted input, you clear away the environment variables first. CGI was standardised in 1997 to use environment variables to pass information into the CGI program. I'm sure software existed before that that does the same - procmail, perhaps? No software that's been touched in the past two decades should assume that the environment variable is safe. Especially not a shell, which gets used for all sorts of network-processing-related things.
- nailer 12y ago
  Postfix is of a similar age and does exactly as weev says.

jimktrains2 12y ago

No, it doesn't, but like Heartbleed, I've see a lot of backlash against GNU (sometimes via Stallman bashing). That, I believe, is what's being discussed here.

scott_s 12y ago
I'm not trying to be sarcastic, this is an honest question: where have you seen the blame against GNU and Stallman related to the bash bug? I ask because I haven't seen it here (thankfully) or anywhere else.

ClashTheBunny 12y ago

I think it's more of a point that if you are using something for free, you should think more in terms of "What did I do wrong to cause this? Who did I not support that put us in this situation?". People pointed out that OpenSSL had a miniscule budget and provided tons of value to the world. Once again, all you can say is mea culpa. Either that or they should be creating alternatives and moving away from poorly written software.

jiggy2011 12y ago
Isn't that then an argument against using free software? If the best way to have secure software without being a security expert is to use proprietary software, then that is what we should encourage. FOSS advocates make the opposite argument that FOSS is more secure because there are more eyes on the code.
- XorNot 12y ago
  Proprietary software gets compromised all the time. In serious ways. A simple example is the sheer number of bank websites which get taken down, and then we all yell at the guy who discovered it to absolutely not disclose it for fear of prosecution. The point is, when FOSS software has a bug, there's no small set of developers who are responsible. It's, in some small way, collectively all our faults. Like in the case of Bash - apparently for 20 years, we never actually checked if environment variables were executable.
  - jiggy2011 12y ago
    Most people are incapable of taking any responsibility for issues in bash or openssl, in fact people who rely on them might not even know they exist , let alone be able to fix them. If you buy something from Microsoft you are paying them to take care of everything from the kernel upwards so that you don't need to worry about the details.
    - gggmaster 12y ago
      You can pay someone to improve open source tools, too.

simonpantzare 12y ago

The problem is not that people call out bad code but that they attack the person who wrote it. I bet that the voices criticizing Stallman now will not praise him for GNU next time they cash in on projects built on it.

clarry 12y ago
> The problem is not that people call out bad code but that they attack the person who wrote it If that's happening, I completely agree with you. I was mostly addressing the "bashing bash" part. Because the bashing of bash is what I've seen in the recent discussion. Not the bashing of RMS.

parennoob 12y ago

This is completely missing the point and intent of the article. The author is (IMO, rightly) getting pissed about "technology journalists" at places like Forbes, or bankers at JP Morgan, who will smugly say stuff like, "Oh, there was a really horrible vulnerability in this software, and there's nothing we can do until those incompetent programmers get out a patch" (even if this is not explicitly said, it is often implied in these articles). They completely overlook the fact that a) The source it right there. You think you can do a better job, please fix it and submit a patch upstream. Or post on the bugtracker. b) The reason this is a problem is usually because of lack of sanitization of user input before passing it to bash. So that is your problem, not really bash itself. Use one of the patches out there that disable the "feature" that leads to the bug. How many articles state stuff like "Thousands of organizations over the world use bash, yet no one has discovered this for 22 years. This means a lot of companies are not taking security seriously enough to audit the (open) source of the code they ride on."? Until we start seeing articles that address the complex social and economic aspects of the issue, I don't blame FSF supporters for being pissed at them.