All issues identified by OSS-Fuzz are now fixed in libxls master. @Jenny if the code passes your readxl tests I will begin preparing a 1.5 release candidate.
In other news, I heard back from the researcher who initially reported the issues. His GitHub account was marked as spam, which explains why the issues he filed disappeared without warning. Sent from my iPad > On Jan 27, 2019, at 10:27, Dirk Eddelbuettel <e...@debian.org> wrote: > > > On 27 January 2019 at 09:25, Evan Miller wrote: > | > | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel <e...@debian.org> wrote: > | > > | > > | > On 26 January 2019 at 15:59, Jennifer Bryan wrote: > | > | I'll still wait a bit to see if libxls can get to an official release > soon. > | > | > | > | But readxl builds and passes tests everywhere with the current libxls, > so > | > | that's good news: > | > | > | > | https://github.com/tidyverse/readxl/pull/543 > | > > | > Nice -- should I fold that into an interim release to address the CVE? > | > I can then follow-up with real release whenever you push to CRAN. > | > | This would be fine from my end. I am hunting down one last hang identified > by OSS-Fuzz (I.e. potential denial of service), but the CVEs, buffer > overruns, and memory leaks are all fixed in Jenny’s pull request. > > Ok I did the easy part: updating our current package (based on Jenny's readxl > 1.2.0 from December 2018) to her current dev branch with your updates. The > delta is small and clean so that was no work. In Debian unstable now. > > And I then bravely/foolishly attempted the harder part of backporting to the > (old !!) version in stable. Turns out it was not so bad and similar to the > fix in April -- I updated the relevant files 'en block': > > edd@rob:~/temp-sec$ diff -rq r-cran-readxl-0.1.1.orig/ r-cran-readxl-0.1.1 > Files r-cran-readxl-0.1.1.orig/src/libxls/ole.h and > r-cran-readxl-0.1.1/src/libxls/ole.h differ > Files r-cran-readxl-0.1.1.orig/src/libxls/xlstool.h and > r-cran-readxl-0.1.1/src/libxls/xlstool.h differ > Files r-cran-readxl-0.1.1.orig/src/ole.c and r-cran-readxl-0.1.1/src/ole.c > differ > Files r-cran-readxl-0.1.1.orig/src/xls.c and r-cran-readxl-0.1.1/src/xls.c > differ > Files r-cran-readxl-0.1.1.orig/src/xlstool.c and > r-cran-readxl-0.1.1/src/xlstool.c differ > edd@rob:~/temp-sec$ > > I do get a segfault on the .xls example but _vaguely_ recall that we had > issue in April too. The "example(read_excel)" using the xlsx file works fine. > > Moritz: I'll proceed and send the required debdiff to security@d.o. I may > need to lean on you once again for 'process' as I don't do this all that > often. > > Thanks everybody for the help, particularly Evan of course for the upstream > work, and also Jenny for the clean new branch. > > Dirk > > | Evan > | > | > > | > Dirk > | > > | > | -- Jenny > | > | > | > | On Sat, Jan 26, 2019 at 7:23 AM Evan Miller <emmil...@gmail.com> wrote: > | > | > | > | > > | > | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel <e...@debian.org> > wrote: > | > | > > > | > | > > > | > | > > On 24 January 2019 at 19:54, Evan Miller wrote: > | > | > > | > | > | > > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel <e...@debian.org> > wrote: > | > | > > | > > | > | > > | > > | > | > > | > On 24 January 2019 at 16:36, Evan Miller wrote: > | > | > > | > | > | > | > > | > | > On Jan 23, 2019, at 01:16, Evan Miller <emmil...@gmail.com> > | > | > wrote: > | > | > > | > | > > | > | > > | > | > #34 and #35 have returned from the dead on GitHub. I’ll > take a > | > | > closer look later this week. > | > | > > | > | > > | > | > > | > | > Evan > | > | > > | > | > | > | > > | > | > | > | > > | > | OK — I can confirm that all of the reported libxls bugs are > fixed. > | > | > > | > > | > | > > | > As in: in the current libxls GH version? I can make a patched > Debian > | > | > > | > release of that. > | > | > > | > | > | > > | Yes, they are fixed in master on GitHub. Note that there are > quite a > | > | > few changes since 1.4 – I can’t promise that master has ABI > compatibility > | > | > with the last official 1.4 release. But if you compile the new sources > | > | > using the old headers (or diff and merge manually) I don’t think > there will > | > | > be an issue on that front. > | > | > > > | > | > > Maybe Jenny could take a look? > | > | > > > | > | > > It is her use of your library in her package that I stand behind for > | > | > Debian. > | > | > > | > | > Ah, okay, then the ABI doesn’t matter. I had assumed you were > packaging > | > | > libxls as a runtime library + development headers. > | > | > > | > | > > > | > | > > Thanks for all your diligent work on this. It is great to see this > move > | > | > in > | > | > > the right ("fuzzing") direction. > | > | > > | > | > Long overdue! :-) > | > | > > | > | > Evan > | > | > > | > | > > > | > | > > Dirk > | > | > > > | > | > > | Evan > | > | > > | > | > | > > | > > | > | > > | > | I have successfully integrated libxls into OSS-Fuzz, and have > | > | > added the researcher’s test files to the fuzzing corpus, so that this > and > | > | > related issues should be caught by the address sanitizer in the > future. > | > | > > | > | > | > | > > | > | OSS-Fuzz has turned up a number of other issues. I will plan > to do > | > | > a release when they are all addressed. > | > | > > | > > | > | > > | > That is awesome. > | > | > > | > > | > | > > | > Thank you, Dirk > | > | > > | > > | > | > > | > | Evan > | > | > > | > | > | > | > > | > | > > | > | > > | > | >> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff > <j...@inutil.org > | > | > <mailto:j...@inutil.org>> wrote: > | > | > > | > | >> > | > | > > | > | >> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel > | > | > wrote: > | > | > > | > | >>> > | > | > > | > | >>> Hi Evan, > | > | > > | > | >>> > | > | > > | > | >>> On 15 January 2019 at 11:18, Evan Miller wrote: > | > | > > | > | >>> | > | > | > > | > | >>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff < > | > | > j...@inutil.org <mailto:j...@inutil.org>> wrote: > | > | > > | > | >>> | > > | > | > > | > | >>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller > | > | > wrote: > | > | > > | > | >>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to > have > | > | > disappeared from GitHub. I don’t know if the original reporter > intended to > | > | > close them, or what. > | > | > > | > | >>> | >> > | > | > > | > | >>> | >> I have an email copy of #34 but do not have access > to the > | > | > PoC files. So without the cooperation of the reporter (Zhao Liang, > Huawei > | > | > Weiran Labs) my ability to research will be limited. > | > | > > | > | >>> | > > | > | > > | > | >>> | > That's really strange, do you have the mail address of > | > | > Zhao, could you ask him what happened? > | > | > > | > | >>> | > | > | > > | > | >>> | His address may be leon.zha...@gmail.com <mailto: > | > | > leon.zha...@gmail.com> - I’ll try it. His GitHub profile is now a 404. > | > | > > | > | >>> | > | > | > > | > | >>> | > > | > | > > | > | >>> | > MITRE doesn't archive security content per se, they > only > | > | > deal with the organisation and assignment > | > | > > | > | >>> | > of numbers. The Internet Archive's Wayback machine > also > | > | > hasn't archived the Github pages. > | > | > > | > | >>> | > > | > | > > | > | >>> | > Cheers, > | > | > > | > | >>> | > Moritz > | > | > > | > | >>> | > | > | > > | > | >>> | > | > | > > | > | >>> | Here are the Google caches of #34 and #35: > | > | > > | > | >>> | > | > | > > | > | >>> | > | > | > > https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari > | > | > < > | > | > > https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari > | > | > > > | > | > > | > | >>> | > | > | > > | > | >>> | > | > | > > https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari > | > | > < > | > | > > https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari > | > | > > > | > | > > | > | >>> | > | > | > > | > | >>> | The PoC links are dead. > | > | > > | > | >>> | > | > | > > | > | >>> | Looking at the backtraces and the commit fixing #36 and > #37 ( > | > | > > https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e > | > | > < > | > | > > https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e>) > | > | > it is my belief that issues #34 and #35 are NOT fixed. > | > | > > | > | >>> | > | > | > > | > | >>> | I’ll look into them soon. > | > | > > | > | >>> > | > | > > | > | >>> You're awesome! Much appreciated. > | > | > > | > | >>> > | > | > > | > | >>> Moritz: Do you expect the CVE to puliverize too, or will > it > | > | > remain active and > | > | > > | > | >>> open, but "simply" without any hard (public) evidence > backing > | > | > it? > | > | > > | > | >> > | > | > > | > | >> No, they stick around, it sometimes happens that references > | > | > vanish, e.g. then hosting sites > | > | > > | > | >> go down (think of berlios or similar) > | > | > > | > | >> > | > | > > | > | >> Cheers, > | > | > > | > | >> Moritz > | > | > > | > | > > | > | > > | > | > | > | > > | > > | > | > > | > -- > | > | > > | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > | > | > > > | > | > > -- > | > | > > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > | > | > > | > > | > -- > | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
