Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

On 11 February 2019 at 15:12, Evan Miller wrote:
| An official release of libxls 1.5.0 is here:
| 
| https://github.com/libxls/libxls/releases/tag/v1.5.0 

| 
| It fixes all known vulnerabilities. Thanks for your patience everyone.

And Jenny did her thing with a new readxl, which is now on CRAN ... as
getting into Debian as r-cran-readxl as I type this.

Thanks everybody for the help with this -- especially Evan for the hard
schlepping of all those buckets of cold water.  Up the hill, both ways...

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

An official release of libxls 1.5.0 is here:

https://github.com/libxls/libxls/releases/tag/v1.5.0 


It fixes all known vulnerabilities. Thanks for your patience everyone.

Evan

> On Feb 4, 2019, at 17:15, Dirk Eddelbuettel  wrote:
> 
> 
> And as one more piece of closure, the backported fix is now going into an
> update of Debian stable as well.
> 
> Thanks everybody, and especially Evan. We're already in better shape now, and
> will be in even better shape with the upcoming libxls 1.5 release.
> 
> Dirk
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

And as one more piece of closure, the backported fix is now going into an
update of Debian stable as well.

Thanks everybody, and especially Evan. We're already in better shape now, and
will be in even better shape with the upcoming libxls 1.5 release.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

I will do an official release of libxls 1.5 this week or next.

Sent from my iPad

> On Jan 29, 2019, at 18:44, Jennifer Bryan  wrote:
> 
> 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:
 > | > | > > |
 > | > | > > | > 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 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Jennifer Bryan]

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:
>> > | > | > > |
>> > | > | > > | > 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 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

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:
>> > | > | > > |
>> > | > | > > | > 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
>> > | 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Jennifer Bryan]

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 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.
> > | > | >
> > | > | > 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

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  
> 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 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

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  
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,
| > | > > | > | >>>
| > | > > | > | >>> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> 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.

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  
> 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:
> | > > | > | >>> |
> | > > | > | >>> |
> | > 
> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

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.

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  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 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Jennifer Bryan]

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

[Evan Miller]

> 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  > 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
> | > | > 
> | > | 
> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

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.

Thanks for all your diligent work on this. It is great to see this move in
the right ("fuzzing") direction.

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 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 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 
 - 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
| > | > 
| > | 
| > 
| > -- 
| > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 24, 2019, at 17:01, Jennifer Bryan  wrote:
> 
> 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.

I’m aiming to have a release in the next two weeks. Down to the last 4-5 issues 
unearthed by OSS-Fuzz but I will have limited computer access next week.

Evan

> 
> -- 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
>>> 
>> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> 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.

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  > 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
> | > 
> | 
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

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.

| 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 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 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  
- 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
| > 
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Jennifer Bryan]

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
>
>
>
>

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> 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
> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

#34 and #35 have returned from the dead on GitHub. I’ll take a closer look 
later this week.

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

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Moritz Muehlenhoff]

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

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

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?

Dirk
 
| Evan
| 
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 15, 2019, at 11:18, Evan Miller  wrote:
> 
> 
>> On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  wrote:
>> 
>> 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.

Okay, email sent, I’ll let you all know if I hear from him.

> 
> 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.

My revised opinion is that these issues MAY be already fixed. The commit above 
fixed out of bounds writes - it’s possible that such writes were corrupting the 
pointer that was eventually passed to free(), potentially causing both #34 and 
#35. I did not find any obvious logical errors in the relevant malloc/free 
code, but I won’t know for sure without the POC.

One thing I will do in the meantime is to reach out to Google Autofuzz and try 
to get libxls hooked into their infrastructure. They’re pretty good at 
uncovering all kinds of memory issues.

Evan


> 
> I’ll look into them soon.
> 
> Evan
> 
> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> 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.

Evan

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Moritz Muehlenhoff]

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?

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

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

On 14 January 2019 at 20:45, 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.

That is ... weird.
 
| 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.

Understood.

Moritz: Any idea?  Will the CVE end of things have copies?

Dirk
 
| Evan
| 
| > On Jan 14, 2019, at 19:22, Dirk Eddelbuettel  wrote:
| > 
| > 
| > Hi Evan,
| > 
| > On 14 January 2019 at 19:03, Evan Miller wrote:
| > | Hi Dirk,
| > | 
| > | You are correct - these are issues with the underlying C library, the 
GitHub issues you referenced. I have not researched them specifically, but I 
recently fixed two issues (#36 and #37) that are possibly related:
| > | 
| > | https://github.com/evanmiller/libxls/issues/36 

| > | https://github.com/evanmiller/libxls/issues/37 

| > | 
| > | I will look into #34 and #35 when I get a chance.
| > 
| > Thanks for the prompt follow-up.  Please keep us posted and abreast of any 
progress.
| > 
| > Dirk
| > 
| > | Evan
| > | 
| > | > On Jan 14, 2019, at 17:56, Dirk Eddelbuettel  wrote:
| > | > 
| > | > 
| > | > Hi Evan,
| > | > 
| > | > On 14 January 2019 at 23:32, Moritz Muehlenhoff wrote:
| > | > | Package: r-cran-readxl
| > | > | Severity: important
| > | > | Tags: security
| > | > | 
| > | > | These two libxls issues should affect r-cran-readxl:
| > | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20450
| > | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20452
| > | > 
| > | > These are both file as #34 and #35 at your GitHub repo, but I did not 
see any
| > 
| > s/file/filed/  -- sorry
| > 
| > | > follow-up.  I presume this is similar to the last time that the issue 
really
| > | > stems from the underlying C parser library?  Any idea how long it may 
take
| > | > until we have a fix?
| > | > 
| > | > Courtesy to Jenny who via readxl 'upstream' is the real maintainer for
| > | > the
| > 
| > s/Courtesy/Courtesy CC/ -- sorry
| > 
| > | > CRAN package I mostly just wrap up for Debian.
| > | > 
| > | > Best,  Dirk
| > | > 
| > | > | 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

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

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.

Evan

> On Jan 14, 2019, at 19:22, Dirk Eddelbuettel  wrote:
> 
> 
> Hi Evan,
> 
> On 14 January 2019 at 19:03, Evan Miller wrote:
> | Hi Dirk,
> | 
> | You are correct - these are issues with the underlying C library, the 
> GitHub issues you referenced. I have not researched them specifically, but I 
> recently fixed two issues (#36 and #37) that are possibly related:
> | 
> | https://github.com/evanmiller/libxls/issues/36 
> 
> | https://github.com/evanmiller/libxls/issues/37 
> 
> | 
> | I will look into #34 and #35 when I get a chance.
> 
> Thanks for the prompt follow-up.  Please keep us posted and abreast of any 
> progress.
> 
> Dirk
> 
> | Evan
> | 
> | > On Jan 14, 2019, at 17:56, Dirk Eddelbuettel  wrote:
> | > 
> | > 
> | > Hi Evan,
> | > 
> | > On 14 January 2019 at 23:32, Moritz Muehlenhoff wrote:
> | > | Package: r-cran-readxl
> | > | Severity: important
> | > | Tags: security
> | > | 
> | > | These two libxls issues should affect r-cran-readxl:
> | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20450
> | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20452
> | > 
> | > These are both file as #34 and #35 at your GitHub repo, but I did not see 
> any
> 
> s/file/filed/  -- sorry
> 
> | > follow-up.  I presume this is similar to the last time that the issue 
> really
> | > stems from the underlying C parser library?  Any idea how long it may take
> | > until we have a fix?
> | > 
> | > Courtesy to Jenny who via readxl 'upstream' is the real maintainer for
> | > the
> 
> s/Courtesy/Courtesy CC/ -- sorry
> 
> | > CRAN package I mostly just wrap up for Debian.
> | > 
> | > Best,  Dirk
> | > 
> | > | Cheers,
> | > | Moritz
> | > 
> | > -- 
> | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> | 
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

Hi Evan,

On 14 January 2019 at 19:03, Evan Miller wrote:
| Hi Dirk,
| 
| You are correct - these are issues with the underlying C library, the GitHub 
issues you referenced. I have not researched them specifically, but I recently 
fixed two issues (#36 and #37) that are possibly related:
| 
| https://github.com/evanmiller/libxls/issues/36 

| https://github.com/evanmiller/libxls/issues/37 

| 
| I will look into #34 and #35 when I get a chance.

Thanks for the prompt follow-up.  Please keep us posted and abreast of any 
progress.

Dirk

| Evan
| 
| > On Jan 14, 2019, at 17:56, Dirk Eddelbuettel  wrote:
| > 
| > 
| > Hi Evan,
| > 
| > On 14 January 2019 at 23:32, Moritz Muehlenhoff wrote:
| > | Package: r-cran-readxl
| > | Severity: important
| > | Tags: security
| > | 
| > | These two libxls issues should affect r-cran-readxl:
| > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20450
| > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20452
| > 
| > These are both file as #34 and #35 at your GitHub repo, but I did not see 
any

s/file/filed/  -- sorry

| > follow-up.  I presume this is similar to the last time that the issue really
| > stems from the underlying C parser library?  Any idea how long it may take
| > until we have a fix?
| > 
| > Courtesy to Jenny who via readxl 'upstream' is the real maintainer for
| > the

s/Courtesy/Courtesy CC/ -- sorry

| > CRAN package I mostly just wrap up for Debian.
| > 
| > Best,  Dirk
| > 
| > | Cheers,
| > | Moritz
| > 
| > -- 
| > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Moritz Muehlenhoff]

Package: r-cran-readxl
Severity: important
Tags: security

These two libxls issues should affect r-cran-readxl:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20450
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20452

Cheers,
Moritz