Yes, all is good. I had pulled libxls again yesterday after you merged your PR and readxl still passes checks on all platforms.
https://github.com/tidyverse/readxl/pull/543 -- Jenny On Tue, Jan 29, 2019 at 7:31 AM Evan Miller <emmil...@gmail.com> wrote: > 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 >
