10 ms·

Eep. Seems like patch should be running red, not ed! Amazing how an ancient vuln can still be found hidden in plain sight.

oblio 9y ago
Does anyone know if the GNU tools, the coreutils, have been through security audits and fuzzing? They’re the most used tools on the planet, I’d say, and relying on the 90’s “many eyes make all bugs shallow” doesn’t seem to cut it anymore...
- Ajedi32 9y ago
  Google has an ongoing project for fuzzing popular open source software: https://testing.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html https://testing.googleblog.com/2016/12/announcing-oss-fuzz-c... Looks like at least _some_ GNU tools are covered: https://github.com/google/oss-fuzz/tree/master/projects/gnutls https://github.com/google/oss-fuzz/tree/master/projects/gnut...
- jwilk 9y ago
  For the avoidance of doubt, GNU patch is not part of coreutils.
- teamhappy 9y ago
  Audits and fuzzing don't really make sense if it's a documented feature. Also the many eyeballs principle seems to hold given that the Debian folks found the bug. Having said that, a lot of the core command line tools (not just the GNU coreutils) that are run against untrusted input could certainly be improved. I'd prefer the OpenBSD method though - if it can't exec then I don't need to worry about the bugs the auditor/fuzzer didn't find.
  - oblio 9y ago
    The earliest GNU Patch I could find was 2.5.4, from 1999: https://ftp.gnu.org/pub/gnu/patch/ https://ftp.gnu.org/pub/gnu/patch/ And that’s 2.5.4, 1.0.0 could have been released in 1985 for all we know. I guess we have many eyeballs, yet not enough still :)
- mjw1007 9y ago
  The «Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services» paper in 1995 reported on exactly that. It made a bit of a splash at the time because the GNU command-line tools did noticeably better than the commercial ones. https://minds.wisconsin.edu/bitstream/handle/1793/59964/TR1268.pdf https://minds.wisconsin.edu/bitstream/handle/1793/59964/TR12...
  - oblio 9y ago
    Could be, but that was 23 years ago. That report would now be graduating from college :)
- pixelbeat__ 9y ago
  I'm the GNU coreutils maintainer and have fuzzed them extensively. For example a recent bad bug in TZ handling was found using AFL and fixed by: http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=94e01571 http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=94... We put a lot of effort into the test suite which makes it easy for others to test various experimental security checkers. This has been detailed in the "third party testing" section at: http://www.pixelbeat.org/docs/coreutils-testing.html http://www.pixelbeat.org/docs/coreutils-testing.html
  - oblio 9y ago
    My bad, another commenter pointed out that GNU Patch is not part of coreutils. The GNU umbrella is quite wide these days...
  - DyslexicAtheist 9y ago
    wow pretty awesome to see such a QA pipeline in Open Source projects. I'm used to this in expensive R&D pipelines in the Telco space[0]. Is there a reason you're not using oss-fuzz[1]? I recently did a lot of work using AFL-fast[2] (poking mostly Perl & Lua and crappy IoT products). My experience is that AFL-fast yielded far better results (in a fraction of the time) when compared to AFL. [0] http://www.syssec-project.eu/m/page-media/3/johansson_tfuzz_icst14.pdf http://www.syssec-project.eu/m/page-media/3/johansson_tfuzz_... [1] https://github.com/google/oss-fuzz https://github.com/google/oss-fuzz [2] https://github.com/mboehme/aflfast https://github.com/mboehme/aflfast
    - pixelbeat__ 9y ago
      aflfast is mentioned in my second link and was the most used fuzzing implementation to find bugs in coreutils. We've had a quick look at using oss-fuzz, which will need a bit of work since it's more suited to libraries rather than standalone utils.
emaste 9y ago
FreeBSD's patch runs red, a change we picked up from DragonFly BSD. That said OpenBSD's change to internally handle ed-style diffs is the best approach and I expect FreeBSD will migrate to that.

oblio 9y ago

Does anyone know if the GNU tools, the coreutils, have been through security audits and fuzzing? They’re the most used tools on the planet, I’d say, and relying on the 90’s “many eyes make all bugs shallow” doesn’t seem to cut it anymore...

Ajedi32 9y ago
Google has an ongoing project for fuzzing popular open source software: https://testing.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html https://testing.googleblog.com/2016/12/announcing-oss-fuzz-c... Looks like at least _some_ GNU tools are covered: https://github.com/google/oss-fuzz/tree/master/projects/gnutls https://github.com/google/oss-fuzz/tree/master/projects/gnut...
jwilk 9y ago
For the avoidance of doubt, GNU patch is not part of coreutils.
teamhappy 9y ago
Audits and fuzzing don't really make sense if it's a documented feature. Also the many eyeballs principle seems to hold given that the Debian folks found the bug. Having said that, a lot of the core command line tools (not just the GNU coreutils) that are run against untrusted input could certainly be improved. I'd prefer the OpenBSD method though - if it can't exec then I don't need to worry about the bugs the auditor/fuzzer didn't find.
- oblio 9y ago
  The earliest GNU Patch I could find was 2.5.4, from 1999: https://ftp.gnu.org/pub/gnu/patch/ https://ftp.gnu.org/pub/gnu/patch/ And that’s 2.5.4, 1.0.0 could have been released in 1985 for all we know. I guess we have many eyeballs, yet not enough still :)
mjw1007 9y ago
The «Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services» paper in 1995 reported on exactly that. It made a bit of a splash at the time because the GNU command-line tools did noticeably better than the commercial ones. https://minds.wisconsin.edu/bitstream/handle/1793/59964/TR1268.pdf https://minds.wisconsin.edu/bitstream/handle/1793/59964/TR12...
- oblio 9y ago
  Could be, but that was 23 years ago. That report would now be graduating from college :)
pixelbeat__ 9y ago
I'm the GNU coreutils maintainer and have fuzzed them extensively. For example a recent bad bug in TZ handling was found using AFL and fixed by: http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=94e01571 http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=94... We put a lot of effort into the test suite which makes it easy for others to test various experimental security checkers. This has been detailed in the "third party testing" section at: http://www.pixelbeat.org/docs/coreutils-testing.html http://www.pixelbeat.org/docs/coreutils-testing.html
- oblio 9y ago
  My bad, another commenter pointed out that GNU Patch is not part of coreutils. The GNU umbrella is quite wide these days...
- DyslexicAtheist 9y ago
  wow pretty awesome to see such a QA pipeline in Open Source projects. I'm used to this in expensive R&D pipelines in the Telco space[0]. Is there a reason you're not using oss-fuzz[1]? I recently did a lot of work using AFL-fast[2] (poking mostly Perl & Lua and crappy IoT products). My experience is that AFL-fast yielded far better results (in a fraction of the time) when compared to AFL. [0] http://www.syssec-project.eu/m/page-media/3/johansson_tfuzz_icst14.pdf http://www.syssec-project.eu/m/page-media/3/johansson_tfuzz_... [1] https://github.com/google/oss-fuzz https://github.com/google/oss-fuzz [2] https://github.com/mboehme/aflfast https://github.com/mboehme/aflfast
  - pixelbeat__ 9y ago
    aflfast is mentioned in my second link and was the most used fuzzing implementation to find bugs in coreutils. We've had a quick look at using oss-fuzz, which will need a bit of work since it's more suited to libraries rather than standalone utils.

emaste 9y ago

FreeBSD's patch runs red, a change we picked up from DragonFly BSD. That said OpenBSD's change to internally handle ed-style diffs is the best approach and I expect FreeBSD will migrate to that.