Thanks Jenny. In that case I am not planning any additional code changes, just documentation and maybe tweaks to the build scripts.
Sent from my iPad > On Jan 29, 2019, at 11:47, Jennifer Bryan <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> wrote: >> > >> > >> > On 27 January 2019 at 09:25, Evan Miller wrote: >> > | >> > | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel <[email protected]> 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 [email protected]. 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 <[email protected]> >> > wrote: >> > | > | >> > | > | > >> > | > | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel <[email protected]> >> > wrote: >> > | > | > > >> > | > | > > >> > | > | > > On 24 January 2019 at 19:54, Evan Miller wrote: >> > | > | > > | >> > | > | > > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel >> > <[email protected]> wrote: >> > | > | > > | > >> > | > | > > | > >> > | > | > > | > On 24 January 2019 at 16:36, Evan Miller wrote: >> > | > | > > | > | >> > | > | > > | > | > On Jan 23, 2019, at 01:16, Evan Miller >> > <[email protected]> >> > | > | > 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 >> > <[email protected] >> > | > | > <mailto:[email protected]>> 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 < >> > | > | > [email protected] <mailto:[email protected]>> 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 [email protected] <mailto: >> > | > | > [email protected]> - 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 | >> > [email protected] >> > | > | > > >> > | > | > > -- >> > | > | > > http://dirk.eddelbuettel.com | @eddelbuettel | [email protected] >> > | > | > >> > | > >> > | > -- >> > | > http://dirk.eddelbuettel.com | @eddelbuettel | [email protected] >> > >> > -- >> > http://dirk.eddelbuettel.com | @eddelbuettel | [email protected]
