Bug#919324: CVE-2018-20450 CVE-2018-20452
I will kick off my process then. Will you do something nice and official re: a release and I should keep my eyes open for it? Or am I rolling on my own schedule now, knowing that I am embedding a libxls release in the moral sense? -- Jenny On Tue, Jan 29, 2019 at 11:38 AM Evan Miller wrote: > 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 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 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 wrote: >> > >> > >> > On 27 January 2019 at 09:25, Evan Miller wrote: >> > | >> > | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel >> 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 >> wrote: >> > | > | >> > | > | > >> > | > | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel >> wrote: >> > | > | > > >> > | > | > > >> > | > | > > On 24 January 2019 at 19:54, Evan Miller wrote: >> > | > | > > | >&
Bug#919324: CVE-2018-20450 CVE-2018-20452
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 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 wrote: > > > > > > On 27 January 2019 at 09:25, Evan Miller wrote: > > | > > | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel 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 > wrote: > > | > | > > | > | > > > | > | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel > 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 fix
Bug#919324: CVE-2018-20450 CVE-2018-20452
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
-- Jenny
On Sat, Jan 26, 2019 at 7:23 AM Evan Miller wrote:
>
> > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel wrote:
> >
> >
> > On 24 January 2019 at 19:54, Evan Miller wrote:
> > |
> > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel wrote:
> > | >
> > | >
> > | > On 24 January 2019 at 16:36, Evan Miller wrote:
> > | > |
> > | > | > On Jan 23, 2019, at 01:16, Evan Miller
> 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 > 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 > 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 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+=1=en=clnk=us=safari
> <
> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+=1=en=clnk=us=safari
> >
> > | > | >>> |
> > | > | >>> |
> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+=1=en=clnk=us=safari
> <
> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+=1=en=clnk=us=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.
> >
Bug#919324: CVE-2018-20450 CVE-2018-20452
Thanks for the update and fixes, Evan! What sort of timeframe do you have in mind re: your official release? That affects how I think about timing a readxl release. I don't do them lightly but also want to get the fixes that address the CVEs into readxl sooner rather than later. -- Jenny On Thu, Jan 24, 2019 at 1:36 PM Evan Miller wrote: > > On Jan 23, 2019, at 01:16, Evan Miller 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. 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. > > Evan > > > On Jan 15, 2019, at 14:12, Moritz Muehlenhoff 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 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 - 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+=1=en=clnk=us=safari > | > | > https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+=1=en=clnk=us=safari > | > | The PoC links are dead. > | > | Looking at the backtraces and the commit fixing #36 and #37 ( > 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 > > > >
