CVEs etc

[Tom Barber <to...@spicule.co.uk>]

Hi folks

This isn't supposed to be an alarmist email, but quite enlightening all the
same.

I saw a link to a plugin on the Drill mailing list called Dependency Check
Report so I wired it into  my OODT repo amongst others to see what was
flagged up since the Struts fallout.

Anyway, of course its unlikely but not out of the question to run OODT
fronting on to the interwebs so I think this is decent food for thought as
to why its useful to keep dependencies up to date as much as possible.

Here's a selection of the output:

https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0
https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0
https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0
https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0

Of course there is a bunch of repetition in there and plenty that aren't
over the top severe, some may also be false positives, but as we work
through to OODT 2.0 with the new stuff and chopping out the old stuff,
reducing these as much as possible I would posture.

Tom

Re: CVEs etc

[BW <we...@apache.org>]

Utilizing more than one,if feasible, would be a good avenue to pursue.


On Fri, Sep 15, 2017 at 2:22 AM, lewis john mcgibbney <le...@apache.org>
wrote:
> More on this Tom and folks...
> Some of you may have seen on the news lately security 101 e.g. patch (and
> version) upgrades, are critical...
> @Tom, can we possibly have the checks reflected on dev@?
> Another option which has been thrown out there is the following
> https://www.owasp.org/index.php/OWASP_Dependency_Check
> I am by no means stating that any one is more appropriate, I do however
> think that a notification mechanism would be very approbate.
> Lewis
>
>
> On Sat, Sep 9, 2017 at 6:03 AM, Tom Barber <to...@spicule.co.uk> wrote:
>
>> Hi folks
>>
>> This isn't supposed to be an alarmist email, but quite enlightening all
the
>> same.
>>
>> I saw a link to a plugin on the Drill mailing list called Dependency
Check
>> Report so I wired it into  my OODT repo amongst others to see what was
>> flagged up since the Struts fallout.
>>
>> Anyway, of course its unlikely but not out of the question to run OODT
>> fronting on to the interwebs so I think this is decent food for thought
as
>> to why its useful to keep dependencies up to date as much as possible.
>>
>> Here's a selection of the output:
>>
>> https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0
>> https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0
>> https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0
>> https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0
>>
>> Of course there is a bunch of repetition in there and plenty that aren't
>> over the top severe, some may also be false positives, but as we work
>> through to OODT 2.0 with the new stuff and chopping out the old stuff,
>> reducing these as much as possible I would posture.
>>
>> Tom
>>
>
>
>
> --
> http://home.apache.org/~lewismc/
> @hectorMcSpector
> http://www.linkedin.com/in/lmcgibbney

Re: CVEs etc

[lewis john mcgibbney <le...@apache.org>]

More on this Tom and folks...
Some of you may have seen on the news lately security 101 e.g. patch (and
version) upgrades, are critical...
@Tom, can we possibly have the checks reflected on dev@?
Another option which has been thrown out there is the following
https://www.owasp.org/index.php/OWASP_Dependency_Check
I am by no means stating that any one is more appropriate, I do however
think that a notification mechanism would be very approbate.
Lewis


On Sat, Sep 9, 2017 at 6:03 AM, Tom Barber <to...@spicule.co.uk> wrote:

> Hi folks
>
> This isn't supposed to be an alarmist email, but quite enlightening all the
> same.
>
> I saw a link to a plugin on the Drill mailing list called Dependency Check
> Report so I wired it into  my OODT repo amongst others to see what was
> flagged up since the Struts fallout.
>
> Anyway, of course its unlikely but not out of the question to run OODT
> fronting on to the interwebs so I think this is decent food for thought as
> to why its useful to keep dependencies up to date as much as possible.
>
> Here's a selection of the output:
>
> https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0
> https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0
> https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0
> https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0
>
> Of course there is a bunch of repetition in there and plenty that aren't
> over the top severe, some may also be false positives, but as we work
> through to OODT 2.0 with the new stuff and chopping out the old stuff,
> reducing these as much as possible I would posture.
>
> Tom
>



-- 
http://home.apache.org/~lewismc/
@hectorMcSpector
http://www.linkedin.com/in/lmcgibbney

Re: CVEs etc

[lewis john mcgibbney <le...@apache.org>]

Very good.
Are we opening tickets for all of the upgrades or...

On Wed, Sep 13, 2017 at 3:44 AM Tom Barber <to...@spicule.co.uk> wrote:

> Yeah, so I pushed updated to commons and tika yesterday to the master
> branch,  I also added the plugin to the build chain but stuck it under the
> cve-check profile because it does slow the build down a bit whilst it
> crawls the web.
>
> Tom
>
> On Tue, Sep 12, 2017 at 1:42 PM, lewis john mcgibbney <le...@apache.org>
> wrote:
>
> > Ack
> > I think starting upgrades with the four modules you've highlighted would
> be
> > a big move in the right direction.
> > Is it possible to integrate this tool as part of the build and have
> reports
> > generated automatically? This way we would know from time to time when
> > newer more stable versions of a dependency are available for upgrade...
> >
> > On Tue, Sep 12, 2017 at 12:38 AM Tom Barber <to...@spicule.co.uk> wrote:
> >
> > > Thanks for the feedback chaps.
> > >
> > > Lewis, the report is broken down into CVEs and the tools likelyhood of
> > the
> > > stuff it detected being accurate.
> > >
> > > I think some stuff is pretty obvious, take for example Apache Commons
> > > Collections, that had a Java Serialization bug that allowed for remote
> > code
> > > execution in 3.2.1 but is fixed in 3.2.2 (
> > > https://commons.apache.org/proper/commons-collections/
> > security-reports.html
> > > )
> > > and the issue has been in the wild since 2015. We can tackle simple
> stuff
> > > like this just by shipping an updated version, I assume 3.2.1 to 3.2.2
> > > shouldn't prove too arduous and update.
> > >
> > > Others like CVE-2016-6809 need a bit more digging as their severity is
> > high
> > > but confidence low, but turns out Tika did have a matlab exploit that
> > > seemingly got addressed in 1.14.
> > >
> > > As I said,  I'm not looking to run out there and ship a big release to
> > fix
> > > all of these, but its worth addressing as we move forward.
> > >
> > > Tom
> > >
> > > On Mon, Sep 11, 2017 at 5:31 PM, Sean Kelly <ke...@apache.org> wrote:
> > >
> > > > Huh. That's a nifty tool.
> > > >
> > > > A little frightening.
> > > >
> > > > --k
> > > >
> > > >> Tom Barber <ma...@spicule.co.uk>
> > > >> 2017-09-9 at 8.03 a
> > > >>
> > > >> Hi folks
> > > >>
> > > >> This isn't supposed to be an alarmist email, but quite enlightening
> > all
> > > >> the
> > > >> same.
> > > >>
> > > >> I saw a link to a plugin on the Drill mailing list called Dependency
> > > Check
> > > >> Report so I wired it into my OODT repo amongst others to see what
> was
> > > >> flagged up since the Struts fallout.
> > > >>
> > > >> Anyway, of course its unlikely but not out of the question to run
> OODT
> > > >> fronting on to the interwebs so I think this is decent food for
> > thought
> > > as
> > > >> to why its useful to keep dependencies up to date as much as
> possible.
> > > >>
> > > >> Here's a selection of the output:
> > > >>
> > > >> https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0
> > > >> https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0
> > > >> https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0
> > > >> https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0
> > > >>
> > > >> Of course there is a bunch of repetition in there and plenty that
> > aren't
> > > >> over the top severe, some may also be false positives, but as we
> work
> > > >> through to OODT 2.0 with the new stuff and chopping out the old
> stuff,
> > > >> reducing these as much as possible I would posture.
> > > >>
> > > >> Tom
> > > >>
> > > >>
> > >
> > --
> > http://home.apache.org/~lewismc/
> > @hectorMcSpector
> > http://www.linkedin.com/in/lmcgibbney
> >
>
-- 
http://home.apache.org/~lewismc/
@hectorMcSpector
http://www.linkedin.com/in/lmcgibbney

Re: CVEs etc

[Tom Barber <to...@spicule.co.uk>]

Yeah, so I pushed updated to commons and tika yesterday to the master
branch,  I also added the plugin to the build chain but stuck it under the
cve-check profile because it does slow the build down a bit whilst it
crawls the web.

Tom

On Tue, Sep 12, 2017 at 1:42 PM, lewis john mcgibbney <le...@apache.org>
wrote:

> Ack
> I think starting upgrades with the four modules you've highlighted would be
> a big move in the right direction.
> Is it possible to integrate this tool as part of the build and have reports
> generated automatically? This way we would know from time to time when
> newer more stable versions of a dependency are available for upgrade...
>
> On Tue, Sep 12, 2017 at 12:38 AM Tom Barber <to...@spicule.co.uk> wrote:
>
> > Thanks for the feedback chaps.
> >
> > Lewis, the report is broken down into CVEs and the tools likelyhood of
> the
> > stuff it detected being accurate.
> >
> > I think some stuff is pretty obvious, take for example Apache Commons
> > Collections, that had a Java Serialization bug that allowed for remote
> code
> > execution in 3.2.1 but is fixed in 3.2.2 (
> > https://commons.apache.org/proper/commons-collections/
> security-reports.html
> > )
> > and the issue has been in the wild since 2015. We can tackle simple stuff
> > like this just by shipping an updated version, I assume 3.2.1 to 3.2.2
> > shouldn't prove too arduous and update.
> >
> > Others like CVE-2016-6809 need a bit more digging as their severity is
> high
> > but confidence low, but turns out Tika did have a matlab exploit that
> > seemingly got addressed in 1.14.
> >
> > As I said,  I'm not looking to run out there and ship a big release to
> fix
> > all of these, but its worth addressing as we move forward.
> >
> > Tom
> >
> > On Mon, Sep 11, 2017 at 5:31 PM, Sean Kelly <ke...@apache.org> wrote:
> >
> > > Huh. That's a nifty tool.
> > >
> > > A little frightening.
> > >
> > > --k
> > >
> > >> Tom Barber <ma...@spicule.co.uk>
> > >> 2017-09-9 at 8.03 a
> > >>
> > >> Hi folks
> > >>
> > >> This isn't supposed to be an alarmist email, but quite enlightening
> all
> > >> the
> > >> same.
> > >>
> > >> I saw a link to a plugin on the Drill mailing list called Dependency
> > Check
> > >> Report so I wired it into my OODT repo amongst others to see what was
> > >> flagged up since the Struts fallout.
> > >>
> > >> Anyway, of course its unlikely but not out of the question to run OODT
> > >> fronting on to the interwebs so I think this is decent food for
> thought
> > as
> > >> to why its useful to keep dependencies up to date as much as possible.
> > >>
> > >> Here's a selection of the output:
> > >>
> > >> https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0
> > >> https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0
> > >> https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0
> > >> https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0
> > >>
> > >> Of course there is a bunch of repetition in there and plenty that
> aren't
> > >> over the top severe, some may also be false positives, but as we work
> > >> through to OODT 2.0 with the new stuff and chopping out the old stuff,
> > >> reducing these as much as possible I would posture.
> > >>
> > >> Tom
> > >>
> > >>
> >
> --
> http://home.apache.org/~lewismc/
> @hectorMcSpector
> http://www.linkedin.com/in/lmcgibbney
>

Re: CVEs etc

[lewis john mcgibbney <le...@apache.org>]

Ack
I think starting upgrades with the four modules you've highlighted would be
a big move in the right direction.
Is it possible to integrate this tool as part of the build and have reports
generated automatically? This way we would know from time to time when
newer more stable versions of a dependency are available for upgrade...

On Tue, Sep 12, 2017 at 12:38 AM Tom Barber <to...@spicule.co.uk> wrote:

> Thanks for the feedback chaps.
>
> Lewis, the report is broken down into CVEs and the tools likelyhood of the
> stuff it detected being accurate.
>
> I think some stuff is pretty obvious, take for example Apache Commons
> Collections, that had a Java Serialization bug that allowed for remote code
> execution in 3.2.1 but is fixed in 3.2.2 (
> https://commons.apache.org/proper/commons-collections/security-reports.html
> )
> and the issue has been in the wild since 2015. We can tackle simple stuff
> like this just by shipping an updated version, I assume 3.2.1 to 3.2.2
> shouldn't prove too arduous and update.
>
> Others like CVE-2016-6809 need a bit more digging as their severity is high
> but confidence low, but turns out Tika did have a matlab exploit that
> seemingly got addressed in 1.14.
>
> As I said,  I'm not looking to run out there and ship a big release to fix
> all of these, but its worth addressing as we move forward.
>
> Tom
>
> On Mon, Sep 11, 2017 at 5:31 PM, Sean Kelly <ke...@apache.org> wrote:
>
> > Huh. That's a nifty tool.
> >
> > A little frightening.
> >
> > --k
> >
> >> Tom Barber <ma...@spicule.co.uk>
> >> 2017-09-9 at 8.03 a
> >>
> >> Hi folks
> >>
> >> This isn't supposed to be an alarmist email, but quite enlightening all
> >> the
> >> same.
> >>
> >> I saw a link to a plugin on the Drill mailing list called Dependency
> Check
> >> Report so I wired it into my OODT repo amongst others to see what was
> >> flagged up since the Struts fallout.
> >>
> >> Anyway, of course its unlikely but not out of the question to run OODT
> >> fronting on to the interwebs so I think this is decent food for thought
> as
> >> to why its useful to keep dependencies up to date as much as possible.
> >>
> >> Here's a selection of the output:
> >>
> >> https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0
> >> https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0
> >> https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0
> >> https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0
> >>
> >> Of course there is a bunch of repetition in there and plenty that aren't
> >> over the top severe, some may also be false positives, but as we work
> >> through to OODT 2.0 with the new stuff and chopping out the old stuff,
> >> reducing these as much as possible I would posture.
> >>
> >> Tom
> >>
> >>
>
-- 
http://home.apache.org/~lewismc/
@hectorMcSpector
http://www.linkedin.com/in/lmcgibbney

Re: CVEs etc

[Tom Barber <to...@spicule.co.uk>]

Thanks for the feedback chaps.

Lewis, the report is broken down into CVEs and the tools likelyhood of the
stuff it detected being accurate.

I think some stuff is pretty obvious, take for example Apache Commons
Collections, that had a Java Serialization bug that allowed for remote code
execution in 3.2.1 but is fixed in 3.2.2 (
https://commons.apache.org/proper/commons-collections/security-reports.html)
and the issue has been in the wild since 2015. We can tackle simple stuff
like this just by shipping an updated version, I assume 3.2.1 to 3.2.2
shouldn't prove too arduous and update.

Others like CVE-2016-6809 need a bit more digging as their severity is high
but confidence low, but turns out Tika did have a matlab exploit that
seemingly got addressed in 1.14.

As I said,  I'm not looking to run out there and ship a big release to fix
all of these, but its worth addressing as we move forward.

Tom

On Mon, Sep 11, 2017 at 5:31 PM, Sean Kelly <ke...@apache.org> wrote:

> Huh. That's a nifty tool.
>
> A little frightening.
>
> --k
>
>> Tom Barber <ma...@spicule.co.uk>
>> 2017-09-9 at 8.03 a
>>
>> Hi folks
>>
>> This isn't supposed to be an alarmist email, but quite enlightening all
>> the
>> same.
>>
>> I saw a link to a plugin on the Drill mailing list called Dependency Check
>> Report so I wired it into my OODT repo amongst others to see what was
>> flagged up since the Struts fallout.
>>
>> Anyway, of course its unlikely but not out of the question to run OODT
>> fronting on to the interwebs so I think this is decent food for thought as
>> to why its useful to keep dependencies up to date as much as possible.
>>
>> Here's a selection of the output:
>>
>> https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0
>> https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0
>> https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0
>> https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0
>>
>> Of course there is a bunch of repetition in there and plenty that aren't
>> over the top severe, some may also be false positives, but as we work
>> through to OODT 2.0 with the new stuff and chopping out the old stuff,
>> reducing these as much as possible I would posture.
>>
>> Tom
>>
>>

Re: CVEs etc

[Sean Kelly <ke...@apache.org>]

Huh. That's a nifty tool.

A little frightening.

--k
> Tom Barber <ma...@spicule.co.uk>
> 2017-09-9 at 8.03 a
> Hi folks
>
> This isn't supposed to be an alarmist email, but quite enlightening 
> all the
> same.
>
> I saw a link to a plugin on the Drill mailing list called Dependency Check
> Report so I wired it into my OODT repo amongst others to see what was
> flagged up since the Struts fallout.
>
> Anyway, of course its unlikely but not out of the question to run OODT
> fronting on to the interwebs so I think this is decent food for thought as
> to why its useful to keep dependencies up to date as much as possible.
>
> Here's a selection of the output:
>
> https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0
> https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0
> https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0
> https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0
>
> Of course there is a bunch of repetition in there and plenty that aren't
> over the top severe, some may also be false positives, but as we work
> through to OODT 2.0 with the new stuff and chopping out the old stuff,
> reducing these as much as possible I would posture.
>
> Tom
>

Re: CVEs etc

[lewis john mcgibbney <le...@apache.org>]

Hi Tom,
I was reading the Struts PMC Experian response this morning and it made me
come back t this thread.
A very good topic and worthy of some action IMHO.
OODT is jam packed with dependencies and we should be prudent about making
upgrades when they become available.
Why do you propose are action items here?

On Sat, Sep 9, 2017 at 6:03 AM, Tom Barber <to...@spicule.co.uk> wrote:

> Hi folks
>
> This isn't supposed to be an alarmist email, but quite enlightening all the
> same.
>
> I saw a link to a plugin on the Drill mailing list called Dependency Check
> Report so I wired it into  my OODT repo amongst others to see what was
> flagged up since the Struts fallout.
>
> Anyway, of course its unlikely but not out of the question to run OODT
> fronting on to the interwebs so I think this is decent food for thought as
> to why its useful to keep dependencies up to date as much as possible.
>
> Here's a selection of the output:
>
> https://www.dropbox.com/s/2ida8dk54yleedo/curator-webapp.html?dl=0
> https://www.dropbox.com/s/wgt1facgjhqiqkq/fmbrowser.html?dl=0
> https://www.dropbox.com/s/o8kqcaktplzjy4y/metadata.html?dl=0
> https://www.dropbox.com/s/cli4pj4jc564f16/pge.html?dl=0
>
> Of course there is a bunch of repetition in there and plenty that aren't
> over the top severe, some may also be false positives, but as we work
> through to OODT 2.0 with the new stuff and chopping out the old stuff,
> reducing these as much as possible I would posture.
>
> Tom
>



-- 
http://home.apache.org/~lewismc/
@hectorMcSpector
http://www.linkedin.com/in/lmcgibbney