7 ms·

Not having worked with bash (et al) in ages I wonder whether allowing a function definition (even without trailing commands) is not still hole? What if you defi

by rbobby 12y ago

Not having worked with bash (et al) in ages I wonder whether allowing a function definition (even without trailing commands) is not still hole? What if you defined a function 'ls() { evil... }'... could a CGI script making a call to 'ls' actually end up with the function instead of the real 'ls'?

tokenizerrr 12y ago
Yes, but if you can control enviroment variable names then you can also set LD_PRELOAD and a whole load of other nasty enviroment variables.
- bodyfour 12y ago
  ...although some programs blacklist unsafe environment variable names. They all should be updated to also blacklist bash function values.
  - mh- 12y ago
    fortunately, sudoers(5) (et al.) whitelist certain variables.
ak217 12y ago
You can't control the name of the function - that's dictated by the name of the environment variable. The feature at fault is activated by the presence of "(){" at the start of the environment variable value.
stormbrew 12y ago
I think the cases where it's still a hole are probably obscure and/or unlikely in the wild, but I definitely think the response to this should have been to disable the feature altogether. It's a terrible idea and I'm really curious if anything actually uses it and should be using it.
- philh 12y ago
  It's used to export functions from one instance of bash to a child. Do you think that that's a terrible idea, or do you have a better idea of how to implement it? (The fix changes it so that exporting is done through specially named variables. Instead of exporting `x='() { :; };`, it now exports `BASH_FUNCTION_x()='() { :; };'`.)
  - stormbrew 12y ago
    Do any other shells do it? Afaik it's not part of the POSIX sh spec. So any script that does it is going to be extremely dependent on bash in particular. It would take actual use cases to convince me it's not a terrible idea. No matter what it's a mechanism to throw arbitrary code into a script that has no say in it. This is not the sort of thing you should do because it seems cool, it should be the sort of thing you do because of a really compelling use case that necessitates it. The fact that afaik no other shell has implemented this behaviour since bash did (a couple of decades ago if I understand correctly?) would rather suggest there is a lack of need for this.

by rbobby 12y ago

tokenizerrr 12y ago

Yes, but if you can control enviroment variable names then you can also set LD_PRELOAD and a whole load of other nasty enviroment variables.

bodyfour 12y ago
...although some programs blacklist unsafe environment variable names. They all should be updated to also blacklist bash function values.
- mh- 12y ago
  fortunately, sudoers(5) (et al.) whitelist certain variables.

ak217 12y ago

You can't control the name of the function - that's dictated by the name of the environment variable. The feature at fault is activated by the presence of "(){" at the start of the environment variable value.

stormbrew 12y ago

I think the cases where it's still a hole are probably obscure and/or unlikely in the wild, but I definitely think the response to this should have been to disable the feature altogether. It's a terrible idea and I'm really curious if anything actually uses it and should be using it.

philh 12y ago
It's used to export functions from one instance of bash to a child. Do you think that that's a terrible idea, or do you have a better idea of how to implement it? (The fix changes it so that exporting is done through specially named variables. Instead of exporting `x='() { :; };`, it now exports `BASH_FUNCTION_x()='() { :; };'`.)
- stormbrew 12y ago
  Do any other shells do it? Afaik it's not part of the POSIX sh spec. So any script that does it is going to be extremely dependent on bash in particular. It would take actual use cases to convince me it's not a terrible idea. No matter what it's a mechanism to throw arbitrary code into a script that has no say in it. This is not the sort of thing you should do because it seems cool, it should be the sort of thing you do because of a really compelling use case that necessitates it. The fact that afaik no other shell has implemented this behaviour since bash did (a couple of decades ago if I understand correctly?) would rather suggest there is a lack of need for this.