6 ms·

“Shellshock”

92 points by bronson 12y ago

aaron-lebo 12y ago
Mr. Wheeler is also the person behind the loved and hated sweet-expressions, which provide a way of writing lisp using Python-style indentation [1]. 1. http://www.dwheeler.com/readable/index.html http://www.dwheeler.com/readable/index.html
- moyix 12y ago
  I'm not sure that's the thing he's most known for. I know his work mainly from SLOCCount [1] and his clever solution for Ken Thompson's "Reflections on Trusting Trust" hack [2]. 1. http://www.dwheeler.com/sloccount/ http://www.dwheeler.com/sloccount/ 2. http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/
  - deleted 12y ago
    [deleted]
- anuragbiyani 12y ago
  To add to this: He is the co-inventor of "Burrows–Wheeler transform", which is a key component in any modern genomics analysis pipeline, used in bzip2 (the "b" stands for BWT), etc.
  - jamessb 12y ago
    The transform was produced by a different David Wheeler, who was a computer scientist at Cambridge and died in 2004: https://en.wikipedia.org/wiki/David_Wheeler_%28British_computer_scientist%29 https://en.wikipedia.org/wiki/David_Wheeler_%28British_compu...
    - anuragbiyani 12y ago
      Apologies for the confusion, and thanks for the correction @jamessb. I mixed the author of the post with David J Wheeler (http://en.wikipedia.org/wiki/David_Wheeler_(British_computer_scientist) http://en.wikipedia.org/wiki/David_Wheeler_(British_computer..., when the author is clearly David A. Wheeler (http://en.wikipedia.org/wiki/David_A._Wheeler http://en.wikipedia.org/wiki/David_A._Wheeler).
- narag 12y ago
  He has also written some good stuff. I had the pleasure of translating "Why OSS/FS..." for my LUG, some time ago: http://www.dwheeler.com/oss_fs_why.html http://www.dwheeler.com/oss_fs_why.html -> http://hispalinux.es/informes/wheeler/index.html http://hispalinux.es/informes/wheeler/index.html
danielweber 12y ago
On my Debian/Ubuntu systems (that weren't in production and that I was free to play with), I had a lot of luck pointing /bin/bash at /bin/dash and making a separate /bin/bash-really. The default scripts weren't using /bin/bash at all. Of the third-party scripts that did call /bin/bash, most of them were just lazily using /bin/bash when they could have used /bin/sh just as well. (A few that were actually using some bash-ism that it took me 5 minutes to fix, and only 1 was left that was using some very very weird bash syntax that I couldn't understand.) Redhat apparently uses /bin/bash almost universally. That would be a nightmare to try to fix under pressure. One lesson I've learned (and I didn't always follow it) is to write POSIX-compatible scripts whenever possible and point them at /bin/sh, which is allowed to point to any POSIX-compatible shell. If we get word that, say, a /bin/dash or /bin/ksh attack is coming, you can at least switch your default "runtime" to another shell.
- Zancarius 12y ago
  > One lesson I've learned (and I didn't always follow it) is to write POSIX-compatible scripts whenever possible and point them at /bin/sh, which is allowed to point to any POSIX-compatible shell. If we get word that, say, a /bin/dash or /bin/ksh attack is coming, you can at least switch your default "runtime" to another shell. I don't understand why more people did not accept this as a viable solution (with the exception of systems that are replete with bashisms). I had a curious discussion on the Arch general mailing list with someone who seemed to 1) have his head in the sand regarding the severity of this exploit, 2) believed bash's POSIX-compliant mode when invoked as /bin/sh was sufficient for nearly all use cases, and 3) was content with the first patch that came out as having resolved the problem even though it became obvious fairly early on that the patch wasn't sufficient but made unreasonable demands for more and more evidence to the contrary. (Admittedly: The other side of the coin is that Arch has several scripts that rely heavily on bashisms, so I guess I can at least partially understand where he was coming from--but they all correctly use /bin/bash. The other argument I observed, that adding a dependency on dash somehow inflates the default install too much, seems absurd when dash is about 1/7th the size of bash.) My solution so far has been to follow the advice you share (more or less) where possible: Replace the /bin/sh symlink to point to /bin/dash and fix those things that need fixing, patching bash in the process. It works well. For everything else, I really rather wish they'd stick as closely to bare POSIX-compatibility for system scripts (I'm guilty of using bash extensions, too, so it would seem hypocritical to point fingers).
jpwgarrison 12y ago
I read a few lines, and then for some reason right clicked into "View Source" intending to take a quick peek and read the rest. WOW. That is commenting your code done right.

92 points by bronson 12y ago

Mr. Wheeler is also the person behind the loved and hated sweet-expressions, which provide a way of writing lisp using Python-style indentation [1]. 1. http://www.dwheeler.com/readable/index.html http://www.dwheeler.com/readable/index.html

moyix 12y ago
I'm not sure that's the thing he's most known for. I know his work mainly from SLOCCount [1] and his clever solution for Ken Thompson's "Reflections on Trusting Trust" hack [2]. 1. http://www.dwheeler.com/sloccount/ http://www.dwheeler.com/sloccount/ 2. http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/
- deleted 12y ago
  [deleted]
anuragbiyani 12y ago
To add to this: He is the co-inventor of "Burrows–Wheeler transform", which is a key component in any modern genomics analysis pipeline, used in bzip2 (the "b" stands for BWT), etc.
- jamessb 12y ago
  The transform was produced by a different David Wheeler, who was a computer scientist at Cambridge and died in 2004: https://en.wikipedia.org/wiki/David_Wheeler_%28British_computer_scientist%29 https://en.wikipedia.org/wiki/David_Wheeler_%28British_compu...
  - anuragbiyani 12y ago
    Apologies for the confusion, and thanks for the correction @jamessb. I mixed the author of the post with David J Wheeler (http://en.wikipedia.org/wiki/David_Wheeler_(British_computer_scientist) http://en.wikipedia.org/wiki/David_Wheeler_(British_computer..., when the author is clearly David A. Wheeler (http://en.wikipedia.org/wiki/David_A._Wheeler http://en.wikipedia.org/wiki/David_A._Wheeler).
narag 12y ago
He has also written some good stuff. I had the pleasure of translating "Why OSS/FS..." for my LUG, some time ago: http://www.dwheeler.com/oss_fs_why.html http://www.dwheeler.com/oss_fs_why.html -> http://hispalinux.es/informes/wheeler/index.html http://hispalinux.es/informes/wheeler/index.html

danielweber 12y ago

On my Debian/Ubuntu systems (that weren't in production and that I was free to play with), I had a lot of luck pointing /bin/bash at /bin/dash and making a separate /bin/bash-really. The default scripts weren't using /bin/bash at all. Of the third-party scripts that did call /bin/bash, most of them were just lazily using /bin/bash when they could have used /bin/sh just as well. (A few that were actually using some bash-ism that it took me 5 minutes to fix, and only 1 was left that was using some very very weird bash syntax that I couldn't understand.) Redhat apparently uses /bin/bash almost universally. That would be a nightmare to try to fix under pressure. One lesson I've learned (and I didn't always follow it) is to write POSIX-compatible scripts whenever possible and point them at /bin/sh, which is allowed to point to any POSIX-compatible shell. If we get word that, say, a /bin/dash or /bin/ksh attack is coming, you can at least switch your default "runtime" to another shell.

Zancarius 12y ago
> One lesson I've learned (and I didn't always follow it) is to write POSIX-compatible scripts whenever possible and point them at /bin/sh, which is allowed to point to any POSIX-compatible shell. If we get word that, say, a /bin/dash or /bin/ksh attack is coming, you can at least switch your default "runtime" to another shell. I don't understand why more people did not accept this as a viable solution (with the exception of systems that are replete with bashisms). I had a curious discussion on the Arch general mailing list with someone who seemed to 1) have his head in the sand regarding the severity of this exploit, 2) believed bash's POSIX-compliant mode when invoked as /bin/sh was sufficient for nearly all use cases, and 3) was content with the first patch that came out as having resolved the problem even though it became obvious fairly early on that the patch wasn't sufficient but made unreasonable demands for more and more evidence to the contrary. (Admittedly: The other side of the coin is that Arch has several scripts that rely heavily on bashisms, so I guess I can at least partially understand where he was coming from--but they all correctly use /bin/bash. The other argument I observed, that adding a dependency on dash somehow inflates the default install too much, seems absurd when dash is about 1/7th the size of bash.) My solution so far has been to follow the advice you share (more or less) where possible: Replace the /bin/sh symlink to point to /bin/dash and fix those things that need fixing, patching bash in the process. It works well. For everything else, I really rather wish they'd stick as closely to bare POSIX-compatibility for system scripts (I'm guilty of using bash extensions, too, so it would seem hypocritical to point fingers).

jpwgarrison 12y ago

I read a few lines, and then for some reason right clicked into "View Source" intending to take a quick peek and read the rest. WOW. That is commenting your code done right.