4 ms·

Unfortunately this is not the case in debian. There is an open bug to replace bash with dash. There do not seem to be many bashisms in the actual script. Sadl

by dfc 12y ago

Unfortunately this is not the case in debian. There is an open bug to replace bash with dash. There do not seem to be many bashisms in the actual script. Sadly a member of the security team did not seem to be persuaded by the utility of the switch: > Given the many eyes now turning towards findings bugs in bash > and building exploits with them it might be safer to fix > those bashisms and switch dhclient-script over to #!/bin/sh. > > What do you think? Actually, if you go that road, you would need to drop anything ever calling python, perl, ruby or whatever language somehow remotely. Some scripts might have good reasons to uses bash and bashisms (I'm not saying that's the case here, but still). What I find more concerning is to pass unchecked environment variable directly from remote (or any input, actually). [1]: dhclient-script uses bash, allowing remote bash exploits / https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762923 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762923

emmelaich 12y ago
What I find more concerning is to pass unchecked environment variable directly from remote (or any input, actually). You can understand the opinion to an extent because it would require the every program to know in every case what variables are needed and what they're supposed to look like. sudo does this to a small extent; it wipes function env vars. In the rare system/popen my programs do I explicitly give the entire env - just PATH=/bin:/usr/bin; sometimes I give an empty env. For something like a dhcp client it is obviously bad. The responsibility there is to whatever invokes it.
- dfc 12y ago
  My complaint with the response was the "if you go down that road" response. The bug submitter was not suggesting dropping shell scripts, it was a request to remove the bashisms from dhclient so that it could work with dash. It is not like there is an alternative python/ruby implementation that is "more robust against software failures" and has DEB_HARDENING turned on. If there was I would totally support going down the road of "making small changes to programs that process data from anyone on the network" so they could run on HardPython. If there was something like HardPython alternative that was "more robust to software failures" with st

by dfc 12y ago

emmelaich 12y ago

What I find more concerning is to pass unchecked environment variable directly from remote (or any input, actually). You can understand the opinion to an extent because it would require the every program to know in every case what variables are needed and what they're supposed to look like. sudo does this to a small extent; it wipes function env vars. In the rare system/popen my programs do I explicitly give the entire env - just PATH=/bin:/usr/bin; sometimes I give an empty env. For something like a dhcp client it is obviously bad. The responsibility there is to whatever invokes it.

dfc 12y ago
My complaint with the response was the "if you go down that road" response. The bug submitter was not suggesting dropping shell scripts, it was a request to remove the bashisms from dhclient so that it could work with dash. It is not like there is an alternative python/ruby implementation that is "more robust against software failures" and has DEB_HARDENING turned on. If there was I would totally support going down the road of "making small changes to programs that process data from anyone on the network" so they could run on HardPython. If there was something like HardPython alternative that was "more robust to software failures" with st