You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@helix.apache.org by Brent <br...@gmail.com> on 2021/12/10 18:32:50 UTC
Log4J
[Feel free to take this offline or out-of-band if this is an inappropriate
place to discuss this]
Is there any hotfixing planned as a result of the Log4J zero day going
around?
Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
From what I can tell, Helix seems to be building with
https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14 which in
turn maps to https://mvnrepository.com/artifact/log4j/log4j/1.2.17
The exploit is more prevalent in the 2.x versions of Log4J, but there are
scenarios where 1.x is exploitable and it's been pointed out that 1.x is
also end of life and has other vulnerabilities.
See:
https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
Thanks!
~Brent
Re: Log4J
Posted by Brent <br...@gmail.com>.
That's fair. I understand holding off on the v1.0.3 release. I'll just
need to custom build myself a Log4j-patched version to use in the meantime.
Let me know if I can help at all in getting the PR merge into master.
Thanks very much and I hope you all have a great holiday season!
~Brent
On Mon, Dec 20, 2021 at 12:12 PM Junkai Xue <ju...@gmail.com> wrote:
> Thanks Brent! Unfortunately, we cannot have 1.0.3, right now, since there
> are some changes between 1.0.2 and the current master not end-to-end
> verified. The thing is that even though we have the 1.0.3 version, Helix
> users are on 0.8 or 0.9 not able to use them because of the backward
> incompatibility in the major version. We may start the progress early next
> year.
>
> Thanks for your contribution!
>
> Best,
>
> Junkai
>
> On Mon, Dec 20, 2021 at 8:58 AM Brent <br...@gmail.com> wrote:
>
> > (I joined in the discussion on the ZK list, thanks Patrick, though I know
> > that comment is targeted more at the core Helix team than myself)
> >
> > I had a mis-step last week in determining which set of logging
> dependencies
> > to use, but I think the PR is up-to-date and correct now:
> > https://github.com/apache/helix/pull/1922
> >
> > All the tests ran successfully and all my spot testing of command line
> > tools like the agent and controller seem to be behaving properly.
> > Obviously any independent verification other folks are able to do would
> be
> > super helpful.
> >
> > Assuming this all looks good and gets merged, will it be feasible to cut
> a
> > new 1.0.3 release or at least make a new tag in GitHub? This is almost
> > more of a "hotfix" type situation, so I'm not sure how you all normally
> > handle that sort of thing. From my standpoint, I think it'd be really
> > useful if there were a way for Helix customers to easily get their hands
> on
> > a mitigated version. I know I personally am having to custom patch this
> in
> > my environment currently, so being able to use an "official" release
> would
> > make my life way easier.
> >
> > On a side note, a Log4j 2.17.0 was just released, so we may also want to
> > consider updating the PR from 2.16.0 too, which should be pretty easy.
> >
> > Thanks for your time and help!
> >
> > ~Brent
> >
> > On Thu, Dec 16, 2021 at 3:53 PM Patrick Hunt <ph...@apache.org> wrote:
> >
> > > The ZK community has been discussing where to go wrt log4j/... -- as a
> > > "customer" if you have any insights it would be good for you to weigh
> in.
> > > Perhaps help out with testing early rcs and any downstream impact.
> > >
> > > Regards,
> > >
> > > Patrick
> > >
> > > On Thu, Dec 16, 2021 at 2:24 PM Hunter Lee <na...@gmail.com> wrote:
> > >
> > > > Thanks Brent for a quick turnaround.
> > > >
> > > > With Helix we find that laptops aren't usually powerful enough to run
> > > > tests. But around last year we started looking at GitHub CI for
> testing
> > > > results for testing consistency.
> > > >
> > > > Seems that the test is still running, so let's wait this out and see
> > what
> > > > we get.
> > > >
> > > > Hunter
> > > >
> > > > On Thu, Dec 16, 2021 at 5:17 PM Junkai Xue <jx...@apache.org> wrote:
> > > >
> > > > > Thanks Brent! Right, I was commenting on your PR with that. Maybe
> we
> > > need
> > > > > to run the patch you provided to double verify it before merging.
> > > > > Anyway, thanks for contributing to this!
> > > > >
> > > > > Best,
> > > > >
> > > > > Junkai
> > > > >
> > > > > On Thu, Dec 16, 2021 at 2:11 PM Brent <br...@gmail.com>
> > > wrote:
> > > > >
> > > > > > I'm sure you all saw the notifications, but I pushed a PR for
> this
> > at
> > > > > > https://github.com/apache/helix/pull/1922
> > > > > >
> > > > > > I describe some of this in the PR, but the changes rippled out a
> > > little
> > > > > > further than I thought, partly due to the Zookeeper dependency
> > still
> > > > > > bringing in vulnerable versions and partly due to a few places in
> > > code
> > > > > > referencing Log4j 1.x APIs/packages/classes directly.
> > > > > >
> > > > > > My main concern, other than the magnitude of the change, is that
> I
> > > > > > successfully ran all of the tests except helix-core. All of the
> > > > > helix-core
> > > > > > tests succeeded up until the last 150 or so when I started
> getting
> > > out
> > > > of
> > > > > > memory errors, e.g.:
> > > > > > [ERROR] Failures:
> > > > > > [ERROR] TestConfigAccessor.testBasic:50 » OutOfMemory unable to
> > > > create
> > > > > > new native thre...
> > > > > > [ERROR] TestConfigAccessor.testDeleteCloudConfig:329 »
> > OutOfMemory
> > > > > unable
> > > > > > to create ne...
> > > > > > [ERROR] TestConfigAccessor.testSetRestConfig:219 » OutOfMemory
> > > unable
> > > > > to
> > > > > > create new na...
> > > > > >
> > > > > > I can't tell if that's just my laptop or if it's a legitimate
> > problem
> > > > > > introduced by this change, so any independent verification (maybe
> > the
> > > > PR
> > > > > > hooks already do this) would be greatly appreciated. I'm going
> to
> > > try
> > > > to
> > > > > > test this in one of our dev environments, but would it would be
> > great
> > > > if
> > > > > > someone else could independently verify too.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > ~Brent
> > > > > >
> > > > > > On Wed, Dec 15, 2021 at 11:01 AM Hunter Lee <na...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > Thanks Brent. We'll keep an eye out for it.
> > > > > > >
> > > > > > > Hunter
> > > > > > >
> > > > > > > On Wed, Dec 15, 2021 at 12:42 AM Brent <
> > brentwritescode@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > I filed this issue so we have something to track:
> > > > > > > > https://github.com/apache/helix/issues/1921
> > > > > > > >
> > > > > > > > I'm attempting to get Log4J 2.16.x building and running
> > properly
> > > > > > locally.
> > > > > > > > I will submit a PR if I can get it working.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > On Tue, Dec 14, 2021 at 8:40 AM Brent <
> > brentwritescode@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Thanks Hunter, much appreciated! I will try to put
> together
> > a
> > > > > patch
> > > > > > > with
> > > > > > > > > what I've done for remediation elsewhere (good news is it's
> > not
> > > > > much
> > > > > > > > since
> > > > > > > > > Helix still inherits Log4J 1.x). If you wouldn't mind, I
> > might
> > > > > also
> > > > > > > file
> > > > > > > > > an issue to consider upgrading to Log4J 2.16.x that was
> just
> > > > pushed
> > > > > > > out (
> > > > > > > > >
> > > https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4
> > > > ).
> > > > > > > That
> > > > > > > > > one will require some more thought to make sure things
> don't
> > > > break
> > > > > I
> > > > > > > > > suspect.
> > > > > > > > >
> > > > > > > > > ~Brent
> > > > > > > > >
> > > > > > > > > On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <
> > narendly@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> This is being discussed. Feel free to post a patch if
> you're
> > > > > > > interested
> > > > > > > > >> (but do let us know so there's no duplicate effort being
> > made
> > > > > here).
> > > > > > > > >>
> > > > > > > > >> On Fri, Dec 10, 2021 at 1:33 PM Brent <
> > > > brentwritescode@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >> > [Feel free to take this offline or out-of-band if this
> is
> > an
> > > > > > > > >> inappropriate
> > > > > > > > >> > place to discuss this]
> > > > > > > > >> >
> > > > > > > > >> > Is there any hotfixing planned as a result of the Log4J
> > zero
> > > > day
> > > > > > > going
> > > > > > > > >> > around?
> > > > > > > > >> >
> > > > > > > > >> > Reference:
> > https://www.lunasec.io/docs/blog/log4j-zero-day/
> > > > > > > > >> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> > > > > > > > >> >
> > > > > > > > >> > From what I can tell, Helix seems to be building with
> > > > > > > > >> >
> > > > > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14
> > > > > > > > >> which in
> > > > > > > > >> > turn maps to
> > > > > > https://mvnrepository.com/artifact/log4j/log4j/1.2.17
> > > > > > > > >> >
> > > > > > > > >> > The exploit is more prevalent in the 2.x versions of
> > Log4J,
> > > > but
> > > > > > > there
> > > > > > > > >> are
> > > > > > > > >> > scenarios where 1.x is exploitable and it's been pointed
> > out
> > > > > that
> > > > > > > 1.x
> > > > > > > > is
> > > > > > > > >> > also end of life and has other vulnerabilities.
> > > > > > > > >> >
> > > > > > > > >> > See:
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> > > > > > > > >> >
> > > > > > > > >> > Thanks!
> > > > > > > > >> >
> > > > > > > > >> > ~Brent
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Junkai Xue
>
Re: Log4J
Posted by Junkai Xue <ju...@gmail.com>.
Thanks Brent! Unfortunately, we cannot have 1.0.3, right now, since there
are some changes between 1.0.2 and the current master not end-to-end
verified. The thing is that even though we have the 1.0.3 version, Helix
users are on 0.8 or 0.9 not able to use them because of the backward
incompatibility in the major version. We may start the progress early next
year.
Thanks for your contribution!
Best,
Junkai
On Mon, Dec 20, 2021 at 8:58 AM Brent <br...@gmail.com> wrote:
> (I joined in the discussion on the ZK list, thanks Patrick, though I know
> that comment is targeted more at the core Helix team than myself)
>
> I had a mis-step last week in determining which set of logging dependencies
> to use, but I think the PR is up-to-date and correct now:
> https://github.com/apache/helix/pull/1922
>
> All the tests ran successfully and all my spot testing of command line
> tools like the agent and controller seem to be behaving properly.
> Obviously any independent verification other folks are able to do would be
> super helpful.
>
> Assuming this all looks good and gets merged, will it be feasible to cut a
> new 1.0.3 release or at least make a new tag in GitHub? This is almost
> more of a "hotfix" type situation, so I'm not sure how you all normally
> handle that sort of thing. From my standpoint, I think it'd be really
> useful if there were a way for Helix customers to easily get their hands on
> a mitigated version. I know I personally am having to custom patch this in
> my environment currently, so being able to use an "official" release would
> make my life way easier.
>
> On a side note, a Log4j 2.17.0 was just released, so we may also want to
> consider updating the PR from 2.16.0 too, which should be pretty easy.
>
> Thanks for your time and help!
>
> ~Brent
>
> On Thu, Dec 16, 2021 at 3:53 PM Patrick Hunt <ph...@apache.org> wrote:
>
> > The ZK community has been discussing where to go wrt log4j/... -- as a
> > "customer" if you have any insights it would be good for you to weigh in.
> > Perhaps help out with testing early rcs and any downstream impact.
> >
> > Regards,
> >
> > Patrick
> >
> > On Thu, Dec 16, 2021 at 2:24 PM Hunter Lee <na...@gmail.com> wrote:
> >
> > > Thanks Brent for a quick turnaround.
> > >
> > > With Helix we find that laptops aren't usually powerful enough to run
> > > tests. But around last year we started looking at GitHub CI for testing
> > > results for testing consistency.
> > >
> > > Seems that the test is still running, so let's wait this out and see
> what
> > > we get.
> > >
> > > Hunter
> > >
> > > On Thu, Dec 16, 2021 at 5:17 PM Junkai Xue <jx...@apache.org> wrote:
> > >
> > > > Thanks Brent! Right, I was commenting on your PR with that. Maybe we
> > need
> > > > to run the patch you provided to double verify it before merging.
> > > > Anyway, thanks for contributing to this!
> > > >
> > > > Best,
> > > >
> > > > Junkai
> > > >
> > > > On Thu, Dec 16, 2021 at 2:11 PM Brent <br...@gmail.com>
> > wrote:
> > > >
> > > > > I'm sure you all saw the notifications, but I pushed a PR for this
> at
> > > > > https://github.com/apache/helix/pull/1922
> > > > >
> > > > > I describe some of this in the PR, but the changes rippled out a
> > little
> > > > > further than I thought, partly due to the Zookeeper dependency
> still
> > > > > bringing in vulnerable versions and partly due to a few places in
> > code
> > > > > referencing Log4j 1.x APIs/packages/classes directly.
> > > > >
> > > > > My main concern, other than the magnitude of the change, is that I
> > > > > successfully ran all of the tests except helix-core. All of the
> > > > helix-core
> > > > > tests succeeded up until the last 150 or so when I started getting
> > out
> > > of
> > > > > memory errors, e.g.:
> > > > > [ERROR] Failures:
> > > > > [ERROR] TestConfigAccessor.testBasic:50 » OutOfMemory unable to
> > > create
> > > > > new native thre...
> > > > > [ERROR] TestConfigAccessor.testDeleteCloudConfig:329 »
> OutOfMemory
> > > > unable
> > > > > to create ne...
> > > > > [ERROR] TestConfigAccessor.testSetRestConfig:219 » OutOfMemory
> > unable
> > > > to
> > > > > create new na...
> > > > >
> > > > > I can't tell if that's just my laptop or if it's a legitimate
> problem
> > > > > introduced by this change, so any independent verification (maybe
> the
> > > PR
> > > > > hooks already do this) would be greatly appreciated. I'm going to
> > try
> > > to
> > > > > test this in one of our dev environments, but would it would be
> great
> > > if
> > > > > someone else could independently verify too.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > ~Brent
> > > > >
> > > > > On Wed, Dec 15, 2021 at 11:01 AM Hunter Lee <na...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Thanks Brent. We'll keep an eye out for it.
> > > > > >
> > > > > > Hunter
> > > > > >
> > > > > > On Wed, Dec 15, 2021 at 12:42 AM Brent <
> brentwritescode@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > I filed this issue so we have something to track:
> > > > > > > https://github.com/apache/helix/issues/1921
> > > > > > >
> > > > > > > I'm attempting to get Log4J 2.16.x building and running
> properly
> > > > > locally.
> > > > > > > I will submit a PR if I can get it working.
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > On Tue, Dec 14, 2021 at 8:40 AM Brent <
> brentwritescode@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Thanks Hunter, much appreciated! I will try to put together
> a
> > > > patch
> > > > > > with
> > > > > > > > what I've done for remediation elsewhere (good news is it's
> not
> > > > much
> > > > > > > since
> > > > > > > > Helix still inherits Log4J 1.x). If you wouldn't mind, I
> might
> > > > also
> > > > > > file
> > > > > > > > an issue to consider upgrading to Log4J 2.16.x that was just
> > > pushed
> > > > > > out (
> > > > > > > >
> > https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4
> > > ).
> > > > > > That
> > > > > > > > one will require some more thought to make sure things don't
> > > break
> > > > I
> > > > > > > > suspect.
> > > > > > > >
> > > > > > > > ~Brent
> > > > > > > >
> > > > > > > > On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <
> narendly@gmail.com
> > >
> > > > > wrote:
> > > > > > > >
> > > > > > > >> This is being discussed. Feel free to post a patch if you're
> > > > > > interested
> > > > > > > >> (but do let us know so there's no duplicate effort being
> made
> > > > here).
> > > > > > > >>
> > > > > > > >> On Fri, Dec 10, 2021 at 1:33 PM Brent <
> > > brentwritescode@gmail.com>
> > > > > > > wrote:
> > > > > > > >>
> > > > > > > >> > [Feel free to take this offline or out-of-band if this is
> an
> > > > > > > >> inappropriate
> > > > > > > >> > place to discuss this]
> > > > > > > >> >
> > > > > > > >> > Is there any hotfixing planned as a result of the Log4J
> zero
> > > day
> > > > > > going
> > > > > > > >> > around?
> > > > > > > >> >
> > > > > > > >> > Reference:
> https://www.lunasec.io/docs/blog/log4j-zero-day/
> > > > > > > >> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> > > > > > > >> >
> > > > > > > >> > From what I can tell, Helix seems to be building with
> > > > > > > >> >
> > > > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14
> > > > > > > >> which in
> > > > > > > >> > turn maps to
> > > > > https://mvnrepository.com/artifact/log4j/log4j/1.2.17
> > > > > > > >> >
> > > > > > > >> > The exploit is more prevalent in the 2.x versions of
> Log4J,
> > > but
> > > > > > there
> > > > > > > >> are
> > > > > > > >> > scenarios where 1.x is exploitable and it's been pointed
> out
> > > > that
> > > > > > 1.x
> > > > > > > is
> > > > > > > >> > also end of life and has other vulnerabilities.
> > > > > > > >> >
> > > > > > > >> > See:
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > >
> > >
> https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> > > > > > > >> >
> > > > > > > >> > Thanks!
> > > > > > > >> >
> > > > > > > >> > ~Brent
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
Junkai Xue
Re: Log4J
Posted by Brent <br...@gmail.com>.
(I joined in the discussion on the ZK list, thanks Patrick, though I know
that comment is targeted more at the core Helix team than myself)
I had a mis-step last week in determining which set of logging dependencies
to use, but I think the PR is up-to-date and correct now:
https://github.com/apache/helix/pull/1922
All the tests ran successfully and all my spot testing of command line
tools like the agent and controller seem to be behaving properly.
Obviously any independent verification other folks are able to do would be
super helpful.
Assuming this all looks good and gets merged, will it be feasible to cut a
new 1.0.3 release or at least make a new tag in GitHub? This is almost
more of a "hotfix" type situation, so I'm not sure how you all normally
handle that sort of thing. From my standpoint, I think it'd be really
useful if there were a way for Helix customers to easily get their hands on
a mitigated version. I know I personally am having to custom patch this in
my environment currently, so being able to use an "official" release would
make my life way easier.
On a side note, a Log4j 2.17.0 was just released, so we may also want to
consider updating the PR from 2.16.0 too, which should be pretty easy.
Thanks for your time and help!
~Brent
On Thu, Dec 16, 2021 at 3:53 PM Patrick Hunt <ph...@apache.org> wrote:
> The ZK community has been discussing where to go wrt log4j/... -- as a
> "customer" if you have any insights it would be good for you to weigh in.
> Perhaps help out with testing early rcs and any downstream impact.
>
> Regards,
>
> Patrick
>
> On Thu, Dec 16, 2021 at 2:24 PM Hunter Lee <na...@gmail.com> wrote:
>
> > Thanks Brent for a quick turnaround.
> >
> > With Helix we find that laptops aren't usually powerful enough to run
> > tests. But around last year we started looking at GitHub CI for testing
> > results for testing consistency.
> >
> > Seems that the test is still running, so let's wait this out and see what
> > we get.
> >
> > Hunter
> >
> > On Thu, Dec 16, 2021 at 5:17 PM Junkai Xue <jx...@apache.org> wrote:
> >
> > > Thanks Brent! Right, I was commenting on your PR with that. Maybe we
> need
> > > to run the patch you provided to double verify it before merging.
> > > Anyway, thanks for contributing to this!
> > >
> > > Best,
> > >
> > > Junkai
> > >
> > > On Thu, Dec 16, 2021 at 2:11 PM Brent <br...@gmail.com>
> wrote:
> > >
> > > > I'm sure you all saw the notifications, but I pushed a PR for this at
> > > > https://github.com/apache/helix/pull/1922
> > > >
> > > > I describe some of this in the PR, but the changes rippled out a
> little
> > > > further than I thought, partly due to the Zookeeper dependency still
> > > > bringing in vulnerable versions and partly due to a few places in
> code
> > > > referencing Log4j 1.x APIs/packages/classes directly.
> > > >
> > > > My main concern, other than the magnitude of the change, is that I
> > > > successfully ran all of the tests except helix-core. All of the
> > > helix-core
> > > > tests succeeded up until the last 150 or so when I started getting
> out
> > of
> > > > memory errors, e.g.:
> > > > [ERROR] Failures:
> > > > [ERROR] TestConfigAccessor.testBasic:50 » OutOfMemory unable to
> > create
> > > > new native thre...
> > > > [ERROR] TestConfigAccessor.testDeleteCloudConfig:329 » OutOfMemory
> > > unable
> > > > to create ne...
> > > > [ERROR] TestConfigAccessor.testSetRestConfig:219 » OutOfMemory
> unable
> > > to
> > > > create new na...
> > > >
> > > > I can't tell if that's just my laptop or if it's a legitimate problem
> > > > introduced by this change, so any independent verification (maybe the
> > PR
> > > > hooks already do this) would be greatly appreciated. I'm going to
> try
> > to
> > > > test this in one of our dev environments, but would it would be great
> > if
> > > > someone else could independently verify too.
> > > >
> > > > Thanks!
> > > >
> > > > ~Brent
> > > >
> > > > On Wed, Dec 15, 2021 at 11:01 AM Hunter Lee <na...@gmail.com>
> > wrote:
> > > >
> > > > > Thanks Brent. We'll keep an eye out for it.
> > > > >
> > > > > Hunter
> > > > >
> > > > > On Wed, Dec 15, 2021 at 12:42 AM Brent <br...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > I filed this issue so we have something to track:
> > > > > > https://github.com/apache/helix/issues/1921
> > > > > >
> > > > > > I'm attempting to get Log4J 2.16.x building and running properly
> > > > locally.
> > > > > > I will submit a PR if I can get it working.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > On Tue, Dec 14, 2021 at 8:40 AM Brent <brentwritescode@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > Thanks Hunter, much appreciated! I will try to put together a
> > > patch
> > > > > with
> > > > > > > what I've done for remediation elsewhere (good news is it's not
> > > much
> > > > > > since
> > > > > > > Helix still inherits Log4J 1.x). If you wouldn't mind, I might
> > > also
> > > > > file
> > > > > > > an issue to consider upgrading to Log4J 2.16.x that was just
> > pushed
> > > > > out (
> > > > > > >
> https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4
> > ).
> > > > > That
> > > > > > > one will require some more thought to make sure things don't
> > break
> > > I
> > > > > > > suspect.
> > > > > > >
> > > > > > > ~Brent
> > > > > > >
> > > > > > > On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <narendly@gmail.com
> >
> > > > wrote:
> > > > > > >
> > > > > > >> This is being discussed. Feel free to post a patch if you're
> > > > > interested
> > > > > > >> (but do let us know so there's no duplicate effort being made
> > > here).
> > > > > > >>
> > > > > > >> On Fri, Dec 10, 2021 at 1:33 PM Brent <
> > brentwritescode@gmail.com>
> > > > > > wrote:
> > > > > > >>
> > > > > > >> > [Feel free to take this offline or out-of-band if this is an
> > > > > > >> inappropriate
> > > > > > >> > place to discuss this]
> > > > > > >> >
> > > > > > >> > Is there any hotfixing planned as a result of the Log4J zero
> > day
> > > > > going
> > > > > > >> > around?
> > > > > > >> >
> > > > > > >> > Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
> > > > > > >> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> > > > > > >> >
> > > > > > >> > From what I can tell, Helix seems to be building with
> > > > > > >> >
> > > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14
> > > > > > >> which in
> > > > > > >> > turn maps to
> > > > https://mvnrepository.com/artifact/log4j/log4j/1.2.17
> > > > > > >> >
> > > > > > >> > The exploit is more prevalent in the 2.x versions of Log4J,
> > but
> > > > > there
> > > > > > >> are
> > > > > > >> > scenarios where 1.x is exploitable and it's been pointed out
> > > that
> > > > > 1.x
> > > > > > is
> > > > > > >> > also end of life and has other vulnerabilities.
> > > > > > >> >
> > > > > > >> > See:
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > >
> > https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> > > > > > >> >
> > > > > > >> > Thanks!
> > > > > > >> >
> > > > > > >> > ~Brent
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Log4J
Posted by Patrick Hunt <ph...@apache.org>.
The ZK community has been discussing where to go wrt log4j/... -- as a
"customer" if you have any insights it would be good for you to weigh in.
Perhaps help out with testing early rcs and any downstream impact.
Regards,
Patrick
On Thu, Dec 16, 2021 at 2:24 PM Hunter Lee <na...@gmail.com> wrote:
> Thanks Brent for a quick turnaround.
>
> With Helix we find that laptops aren't usually powerful enough to run
> tests. But around last year we started looking at GitHub CI for testing
> results for testing consistency.
>
> Seems that the test is still running, so let's wait this out and see what
> we get.
>
> Hunter
>
> On Thu, Dec 16, 2021 at 5:17 PM Junkai Xue <jx...@apache.org> wrote:
>
> > Thanks Brent! Right, I was commenting on your PR with that. Maybe we need
> > to run the patch you provided to double verify it before merging.
> > Anyway, thanks for contributing to this!
> >
> > Best,
> >
> > Junkai
> >
> > On Thu, Dec 16, 2021 at 2:11 PM Brent <br...@gmail.com> wrote:
> >
> > > I'm sure you all saw the notifications, but I pushed a PR for this at
> > > https://github.com/apache/helix/pull/1922
> > >
> > > I describe some of this in the PR, but the changes rippled out a little
> > > further than I thought, partly due to the Zookeeper dependency still
> > > bringing in vulnerable versions and partly due to a few places in code
> > > referencing Log4j 1.x APIs/packages/classes directly.
> > >
> > > My main concern, other than the magnitude of the change, is that I
> > > successfully ran all of the tests except helix-core. All of the
> > helix-core
> > > tests succeeded up until the last 150 or so when I started getting out
> of
> > > memory errors, e.g.:
> > > [ERROR] Failures:
> > > [ERROR] TestConfigAccessor.testBasic:50 » OutOfMemory unable to
> create
> > > new native thre...
> > > [ERROR] TestConfigAccessor.testDeleteCloudConfig:329 » OutOfMemory
> > unable
> > > to create ne...
> > > [ERROR] TestConfigAccessor.testSetRestConfig:219 » OutOfMemory unable
> > to
> > > create new na...
> > >
> > > I can't tell if that's just my laptop or if it's a legitimate problem
> > > introduced by this change, so any independent verification (maybe the
> PR
> > > hooks already do this) would be greatly appreciated. I'm going to try
> to
> > > test this in one of our dev environments, but would it would be great
> if
> > > someone else could independently verify too.
> > >
> > > Thanks!
> > >
> > > ~Brent
> > >
> > > On Wed, Dec 15, 2021 at 11:01 AM Hunter Lee <na...@gmail.com>
> wrote:
> > >
> > > > Thanks Brent. We'll keep an eye out for it.
> > > >
> > > > Hunter
> > > >
> > > > On Wed, Dec 15, 2021 at 12:42 AM Brent <br...@gmail.com>
> > > wrote:
> > > >
> > > > > I filed this issue so we have something to track:
> > > > > https://github.com/apache/helix/issues/1921
> > > > >
> > > > > I'm attempting to get Log4J 2.16.x building and running properly
> > > locally.
> > > > > I will submit a PR if I can get it working.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > On Tue, Dec 14, 2021 at 8:40 AM Brent <br...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Thanks Hunter, much appreciated! I will try to put together a
> > patch
> > > > with
> > > > > > what I've done for remediation elsewhere (good news is it's not
> > much
> > > > > since
> > > > > > Helix still inherits Log4J 1.x). If you wouldn't mind, I might
> > also
> > > > file
> > > > > > an issue to consider upgrading to Log4J 2.16.x that was just
> pushed
> > > > out (
> > > > > > https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4
> ).
> > > > That
> > > > > > one will require some more thought to make sure things don't
> break
> > I
> > > > > > suspect.
> > > > > >
> > > > > > ~Brent
> > > > > >
> > > > > > On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <na...@gmail.com>
> > > wrote:
> > > > > >
> > > > > >> This is being discussed. Feel free to post a patch if you're
> > > > interested
> > > > > >> (but do let us know so there's no duplicate effort being made
> > here).
> > > > > >>
> > > > > >> On Fri, Dec 10, 2021 at 1:33 PM Brent <
> brentwritescode@gmail.com>
> > > > > wrote:
> > > > > >>
> > > > > >> > [Feel free to take this offline or out-of-band if this is an
> > > > > >> inappropriate
> > > > > >> > place to discuss this]
> > > > > >> >
> > > > > >> > Is there any hotfixing planned as a result of the Log4J zero
> day
> > > > going
> > > > > >> > around?
> > > > > >> >
> > > > > >> > Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
> > > > > >> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> > > > > >> >
> > > > > >> > From what I can tell, Helix seems to be building with
> > > > > >> >
> > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14
> > > > > >> which in
> > > > > >> > turn maps to
> > > https://mvnrepository.com/artifact/log4j/log4j/1.2.17
> > > > > >> >
> > > > > >> > The exploit is more prevalent in the 2.x versions of Log4J,
> but
> > > > there
> > > > > >> are
> > > > > >> > scenarios where 1.x is exploitable and it's been pointed out
> > that
> > > > 1.x
> > > > > is
> > > > > >> > also end of life and has other vulnerabilities.
> > > > > >> >
> > > > > >> > See:
> > > > > >> >
> > > > > >>
> > > > >
> > >
> https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> > > > > >> >
> > > > > >> > Thanks!
> > > > > >> >
> > > > > >> > ~Brent
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Log4J
Posted by Hunter Lee <na...@gmail.com>.
Thanks Brent for a quick turnaround.
With Helix we find that laptops aren't usually powerful enough to run
tests. But around last year we started looking at GitHub CI for testing
results for testing consistency.
Seems that the test is still running, so let's wait this out and see what
we get.
Hunter
On Thu, Dec 16, 2021 at 5:17 PM Junkai Xue <jx...@apache.org> wrote:
> Thanks Brent! Right, I was commenting on your PR with that. Maybe we need
> to run the patch you provided to double verify it before merging.
> Anyway, thanks for contributing to this!
>
> Best,
>
> Junkai
>
> On Thu, Dec 16, 2021 at 2:11 PM Brent <br...@gmail.com> wrote:
>
> > I'm sure you all saw the notifications, but I pushed a PR for this at
> > https://github.com/apache/helix/pull/1922
> >
> > I describe some of this in the PR, but the changes rippled out a little
> > further than I thought, partly due to the Zookeeper dependency still
> > bringing in vulnerable versions and partly due to a few places in code
> > referencing Log4j 1.x APIs/packages/classes directly.
> >
> > My main concern, other than the magnitude of the change, is that I
> > successfully ran all of the tests except helix-core. All of the
> helix-core
> > tests succeeded up until the last 150 or so when I started getting out of
> > memory errors, e.g.:
> > [ERROR] Failures:
> > [ERROR] TestConfigAccessor.testBasic:50 » OutOfMemory unable to create
> > new native thre...
> > [ERROR] TestConfigAccessor.testDeleteCloudConfig:329 » OutOfMemory
> unable
> > to create ne...
> > [ERROR] TestConfigAccessor.testSetRestConfig:219 » OutOfMemory unable
> to
> > create new na...
> >
> > I can't tell if that's just my laptop or if it's a legitimate problem
> > introduced by this change, so any independent verification (maybe the PR
> > hooks already do this) would be greatly appreciated. I'm going to try to
> > test this in one of our dev environments, but would it would be great if
> > someone else could independently verify too.
> >
> > Thanks!
> >
> > ~Brent
> >
> > On Wed, Dec 15, 2021 at 11:01 AM Hunter Lee <na...@gmail.com> wrote:
> >
> > > Thanks Brent. We'll keep an eye out for it.
> > >
> > > Hunter
> > >
> > > On Wed, Dec 15, 2021 at 12:42 AM Brent <br...@gmail.com>
> > wrote:
> > >
> > > > I filed this issue so we have something to track:
> > > > https://github.com/apache/helix/issues/1921
> > > >
> > > > I'm attempting to get Log4J 2.16.x building and running properly
> > locally.
> > > > I will submit a PR if I can get it working.
> > > >
> > > > Thanks!
> > > >
> > > > On Tue, Dec 14, 2021 at 8:40 AM Brent <br...@gmail.com>
> > wrote:
> > > >
> > > > > Thanks Hunter, much appreciated! I will try to put together a
> patch
> > > with
> > > > > what I've done for remediation elsewhere (good news is it's not
> much
> > > > since
> > > > > Helix still inherits Log4J 1.x). If you wouldn't mind, I might
> also
> > > file
> > > > > an issue to consider upgrading to Log4J 2.16.x that was just pushed
> > > out (
> > > > > https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4).
> > > That
> > > > > one will require some more thought to make sure things don't break
> I
> > > > > suspect.
> > > > >
> > > > > ~Brent
> > > > >
> > > > > On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <na...@gmail.com>
> > wrote:
> > > > >
> > > > >> This is being discussed. Feel free to post a patch if you're
> > > interested
> > > > >> (but do let us know so there's no duplicate effort being made
> here).
> > > > >>
> > > > >> On Fri, Dec 10, 2021 at 1:33 PM Brent <br...@gmail.com>
> > > > wrote:
> > > > >>
> > > > >> > [Feel free to take this offline or out-of-band if this is an
> > > > >> inappropriate
> > > > >> > place to discuss this]
> > > > >> >
> > > > >> > Is there any hotfixing planned as a result of the Log4J zero day
> > > going
> > > > >> > around?
> > > > >> >
> > > > >> > Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
> > > > >> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> > > > >> >
> > > > >> > From what I can tell, Helix seems to be building with
> > > > >> >
> https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14
> > > > >> which in
> > > > >> > turn maps to
> > https://mvnrepository.com/artifact/log4j/log4j/1.2.17
> > > > >> >
> > > > >> > The exploit is more prevalent in the 2.x versions of Log4J, but
> > > there
> > > > >> are
> > > > >> > scenarios where 1.x is exploitable and it's been pointed out
> that
> > > 1.x
> > > > is
> > > > >> > also end of life and has other vulnerabilities.
> > > > >> >
> > > > >> > See:
> > > > >> >
> > > > >>
> > > >
> > https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> > > > >> >
> > > > >> > Thanks!
> > > > >> >
> > > > >> > ~Brent
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Log4J
Posted by Junkai Xue <jx...@apache.org>.
Thanks Brent! Right, I was commenting on your PR with that. Maybe we need
to run the patch you provided to double verify it before merging.
Anyway, thanks for contributing to this!
Best,
Junkai
On Thu, Dec 16, 2021 at 2:11 PM Brent <br...@gmail.com> wrote:
> I'm sure you all saw the notifications, but I pushed a PR for this at
> https://github.com/apache/helix/pull/1922
>
> I describe some of this in the PR, but the changes rippled out a little
> further than I thought, partly due to the Zookeeper dependency still
> bringing in vulnerable versions and partly due to a few places in code
> referencing Log4j 1.x APIs/packages/classes directly.
>
> My main concern, other than the magnitude of the change, is that I
> successfully ran all of the tests except helix-core. All of the helix-core
> tests succeeded up until the last 150 or so when I started getting out of
> memory errors, e.g.:
> [ERROR] Failures:
> [ERROR] TestConfigAccessor.testBasic:50 » OutOfMemory unable to create
> new native thre...
> [ERROR] TestConfigAccessor.testDeleteCloudConfig:329 » OutOfMemory unable
> to create ne...
> [ERROR] TestConfigAccessor.testSetRestConfig:219 » OutOfMemory unable to
> create new na...
>
> I can't tell if that's just my laptop or if it's a legitimate problem
> introduced by this change, so any independent verification (maybe the PR
> hooks already do this) would be greatly appreciated. I'm going to try to
> test this in one of our dev environments, but would it would be great if
> someone else could independently verify too.
>
> Thanks!
>
> ~Brent
>
> On Wed, Dec 15, 2021 at 11:01 AM Hunter Lee <na...@gmail.com> wrote:
>
> > Thanks Brent. We'll keep an eye out for it.
> >
> > Hunter
> >
> > On Wed, Dec 15, 2021 at 12:42 AM Brent <br...@gmail.com>
> wrote:
> >
> > > I filed this issue so we have something to track:
> > > https://github.com/apache/helix/issues/1921
> > >
> > > I'm attempting to get Log4J 2.16.x building and running properly
> locally.
> > > I will submit a PR if I can get it working.
> > >
> > > Thanks!
> > >
> > > On Tue, Dec 14, 2021 at 8:40 AM Brent <br...@gmail.com>
> wrote:
> > >
> > > > Thanks Hunter, much appreciated! I will try to put together a patch
> > with
> > > > what I've done for remediation elsewhere (good news is it's not much
> > > since
> > > > Helix still inherits Log4J 1.x). If you wouldn't mind, I might also
> > file
> > > > an issue to consider upgrading to Log4J 2.16.x that was just pushed
> > out (
> > > > https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4).
> > That
> > > > one will require some more thought to make sure things don't break I
> > > > suspect.
> > > >
> > > > ~Brent
> > > >
> > > > On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <na...@gmail.com>
> wrote:
> > > >
> > > >> This is being discussed. Feel free to post a patch if you're
> > interested
> > > >> (but do let us know so there's no duplicate effort being made here).
> > > >>
> > > >> On Fri, Dec 10, 2021 at 1:33 PM Brent <br...@gmail.com>
> > > wrote:
> > > >>
> > > >> > [Feel free to take this offline or out-of-band if this is an
> > > >> inappropriate
> > > >> > place to discuss this]
> > > >> >
> > > >> > Is there any hotfixing planned as a result of the Log4J zero day
> > going
> > > >> > around?
> > > >> >
> > > >> > Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
> > > >> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> > > >> >
> > > >> > From what I can tell, Helix seems to be building with
> > > >> > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14
> > > >> which in
> > > >> > turn maps to
> https://mvnrepository.com/artifact/log4j/log4j/1.2.17
> > > >> >
> > > >> > The exploit is more prevalent in the 2.x versions of Log4J, but
> > there
> > > >> are
> > > >> > scenarios where 1.x is exploitable and it's been pointed out that
> > 1.x
> > > is
> > > >> > also end of life and has other vulnerabilities.
> > > >> >
> > > >> > See:
> > > >> >
> > > >>
> > >
> https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> > > >> >
> > > >> > Thanks!
> > > >> >
> > > >> > ~Brent
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: Log4J
Posted by Brent <br...@gmail.com>.
I'm sure you all saw the notifications, but I pushed a PR for this at
https://github.com/apache/helix/pull/1922
I describe some of this in the PR, but the changes rippled out a little
further than I thought, partly due to the Zookeeper dependency still
bringing in vulnerable versions and partly due to a few places in code
referencing Log4j 1.x APIs/packages/classes directly.
My main concern, other than the magnitude of the change, is that I
successfully ran all of the tests except helix-core. All of the helix-core
tests succeeded up until the last 150 or so when I started getting out of
memory errors, e.g.:
[ERROR] Failures:
[ERROR] TestConfigAccessor.testBasic:50 » OutOfMemory unable to create
new native thre...
[ERROR] TestConfigAccessor.testDeleteCloudConfig:329 » OutOfMemory unable
to create ne...
[ERROR] TestConfigAccessor.testSetRestConfig:219 » OutOfMemory unable to
create new na...
I can't tell if that's just my laptop or if it's a legitimate problem
introduced by this change, so any independent verification (maybe the PR
hooks already do this) would be greatly appreciated. I'm going to try to
test this in one of our dev environments, but would it would be great if
someone else could independently verify too.
Thanks!
~Brent
On Wed, Dec 15, 2021 at 11:01 AM Hunter Lee <na...@gmail.com> wrote:
> Thanks Brent. We'll keep an eye out for it.
>
> Hunter
>
> On Wed, Dec 15, 2021 at 12:42 AM Brent <br...@gmail.com> wrote:
>
> > I filed this issue so we have something to track:
> > https://github.com/apache/helix/issues/1921
> >
> > I'm attempting to get Log4J 2.16.x building and running properly locally.
> > I will submit a PR if I can get it working.
> >
> > Thanks!
> >
> > On Tue, Dec 14, 2021 at 8:40 AM Brent <br...@gmail.com> wrote:
> >
> > > Thanks Hunter, much appreciated! I will try to put together a patch
> with
> > > what I've done for remediation elsewhere (good news is it's not much
> > since
> > > Helix still inherits Log4J 1.x). If you wouldn't mind, I might also
> file
> > > an issue to consider upgrading to Log4J 2.16.x that was just pushed
> out (
> > > https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4).
> That
> > > one will require some more thought to make sure things don't break I
> > > suspect.
> > >
> > > ~Brent
> > >
> > > On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <na...@gmail.com> wrote:
> > >
> > >> This is being discussed. Feel free to post a patch if you're
> interested
> > >> (but do let us know so there's no duplicate effort being made here).
> > >>
> > >> On Fri, Dec 10, 2021 at 1:33 PM Brent <br...@gmail.com>
> > wrote:
> > >>
> > >> > [Feel free to take this offline or out-of-band if this is an
> > >> inappropriate
> > >> > place to discuss this]
> > >> >
> > >> > Is there any hotfixing planned as a result of the Log4J zero day
> going
> > >> > around?
> > >> >
> > >> > Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
> > >> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> > >> >
> > >> > From what I can tell, Helix seems to be building with
> > >> > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14
> > >> which in
> > >> > turn maps to https://mvnrepository.com/artifact/log4j/log4j/1.2.17
> > >> >
> > >> > The exploit is more prevalent in the 2.x versions of Log4J, but
> there
> > >> are
> > >> > scenarios where 1.x is exploitable and it's been pointed out that
> 1.x
> > is
> > >> > also end of life and has other vulnerabilities.
> > >> >
> > >> > See:
> > >> >
> > >>
> > https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> > >> >
> > >> > Thanks!
> > >> >
> > >> > ~Brent
> > >> >
> > >>
> > >
> >
>
Re: Log4J
Posted by Hunter Lee <na...@gmail.com>.
Thanks Brent. We'll keep an eye out for it.
Hunter
On Wed, Dec 15, 2021 at 12:42 AM Brent <br...@gmail.com> wrote:
> I filed this issue so we have something to track:
> https://github.com/apache/helix/issues/1921
>
> I'm attempting to get Log4J 2.16.x building and running properly locally.
> I will submit a PR if I can get it working.
>
> Thanks!
>
> On Tue, Dec 14, 2021 at 8:40 AM Brent <br...@gmail.com> wrote:
>
> > Thanks Hunter, much appreciated! I will try to put together a patch with
> > what I've done for remediation elsewhere (good news is it's not much
> since
> > Helix still inherits Log4J 1.x). If you wouldn't mind, I might also file
> > an issue to consider upgrading to Log4J 2.16.x that was just pushed out (
> > https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4). That
> > one will require some more thought to make sure things don't break I
> > suspect.
> >
> > ~Brent
> >
> > On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <na...@gmail.com> wrote:
> >
> >> This is being discussed. Feel free to post a patch if you're interested
> >> (but do let us know so there's no duplicate effort being made here).
> >>
> >> On Fri, Dec 10, 2021 at 1:33 PM Brent <br...@gmail.com>
> wrote:
> >>
> >> > [Feel free to take this offline or out-of-band if this is an
> >> inappropriate
> >> > place to discuss this]
> >> >
> >> > Is there any hotfixing planned as a result of the Log4J zero day going
> >> > around?
> >> >
> >> > Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
> >> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> >> >
> >> > From what I can tell, Helix seems to be building with
> >> > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14
> >> which in
> >> > turn maps to https://mvnrepository.com/artifact/log4j/log4j/1.2.17
> >> >
> >> > The exploit is more prevalent in the 2.x versions of Log4J, but there
> >> are
> >> > scenarios where 1.x is exploitable and it's been pointed out that 1.x
> is
> >> > also end of life and has other vulnerabilities.
> >> >
> >> > See:
> >> >
> >>
> https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> >> >
> >> > Thanks!
> >> >
> >> > ~Brent
> >> >
> >>
> >
>
Re: Log4J
Posted by Brent <br...@gmail.com>.
I filed this issue so we have something to track:
https://github.com/apache/helix/issues/1921
I'm attempting to get Log4J 2.16.x building and running properly locally.
I will submit a PR if I can get it working.
Thanks!
On Tue, Dec 14, 2021 at 8:40 AM Brent <br...@gmail.com> wrote:
> Thanks Hunter, much appreciated! I will try to put together a patch with
> what I've done for remediation elsewhere (good news is it's not much since
> Helix still inherits Log4J 1.x). If you wouldn't mind, I might also file
> an issue to consider upgrading to Log4J 2.16.x that was just pushed out (
> https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4). That
> one will require some more thought to make sure things don't break I
> suspect.
>
> ~Brent
>
> On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <na...@gmail.com> wrote:
>
>> This is being discussed. Feel free to post a patch if you're interested
>> (but do let us know so there's no duplicate effort being made here).
>>
>> On Fri, Dec 10, 2021 at 1:33 PM Brent <br...@gmail.com> wrote:
>>
>> > [Feel free to take this offline or out-of-band if this is an
>> inappropriate
>> > place to discuss this]
>> >
>> > Is there any hotfixing planned as a result of the Log4J zero day going
>> > around?
>> >
>> > Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
>> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
>> >
>> > From what I can tell, Helix seems to be building with
>> > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14
>> which in
>> > turn maps to https://mvnrepository.com/artifact/log4j/log4j/1.2.17
>> >
>> > The exploit is more prevalent in the 2.x versions of Log4J, but there
>> are
>> > scenarios where 1.x is exploitable and it's been pointed out that 1.x is
>> > also end of life and has other vulnerabilities.
>> >
>> > See:
>> >
>> https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
>> >
>> > Thanks!
>> >
>> > ~Brent
>> >
>>
>
Re: Log4J
Posted by Brent <br...@gmail.com>.
Thanks Hunter, much appreciated! I will try to put together a patch with
what I've done for remediation elsewhere (good news is it's not much since
Helix still inherits Log4J 1.x). If you wouldn't mind, I might also file
an issue to consider upgrading to Log4J 2.16.x that was just pushed out (
https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4). That
one will require some more thought to make sure things don't break I
suspect.
~Brent
On Mon, Dec 13, 2021 at 1:42 PM Hunter Lee <na...@gmail.com> wrote:
> This is being discussed. Feel free to post a patch if you're interested
> (but do let us know so there's no duplicate effort being made here).
>
> On Fri, Dec 10, 2021 at 1:33 PM Brent <br...@gmail.com> wrote:
>
> > [Feel free to take this offline or out-of-band if this is an
> inappropriate
> > place to discuss this]
> >
> > Is there any hotfixing planned as a result of the Log4J zero day going
> > around?
> >
> > Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
> > CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> >
> > From what I can tell, Helix seems to be building with
> > https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14 which
> in
> > turn maps to https://mvnrepository.com/artifact/log4j/log4j/1.2.17
> >
> > The exploit is more prevalent in the 2.x versions of Log4J, but there are
> > scenarios where 1.x is exploitable and it's been pointed out that 1.x is
> > also end of life and has other vulnerabilities.
> >
> > See:
> > https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> >
> > Thanks!
> >
> > ~Brent
> >
>
Re: Log4J
Posted by Hunter Lee <na...@gmail.com>.
This is being discussed. Feel free to post a patch if you're interested
(but do let us know so there's no duplicate effort being made here).
On Fri, Dec 10, 2021 at 1:33 PM Brent <br...@gmail.com> wrote:
> [Feel free to take this offline or out-of-band if this is an inappropriate
> place to discuss this]
>
> Is there any hotfixing planned as a result of the Log4J zero day going
> around?
>
> Reference: https://www.lunasec.io/docs/blog/log4j-zero-day/
> CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
>
> From what I can tell, Helix seems to be building with
> https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12/1.7.14 which in
> turn maps to https://mvnrepository.com/artifact/log4j/log4j/1.2.17
>
> The exploit is more prevalent in the 2.x versions of Log4J, but there are
> scenarios where 1.x is exploitable and it's been pointed out that 1.x is
> also end of life and has other vulnerabilities.
>
> See:
> https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
>
> Thanks!
>
> ~Brent
>