CVE-2022-33140: Apache NiFi, Apache NiFi Registry: Improper Neutralization of Command Elements in Shell User Group Provider

[David Handermann]

Severity: high

Description:

The optional ShellUserGroupProvider in Apache NiFi 1.10.0 to 1.16.2 and Apache 
NiFi Registry 0.6.0 to 1.16.2 does not neutralize arguments for group 
resolution commands, allowing injection of operating system commands on Linux 
and macOS platforms.

The ShellUserGroupProvider is not included in the default configuration. 
Command injection requires ShellUserGroupProvider to be one of the enabled User 
Group Providers in the Authorizers configuration. Command injection also 
requires an authenticated user with elevated privileges.  Apache NiFi requires 
an authenticated user with authorization to modify access policies in order to 
execute the command. Apache NiFi Registry requires an authenticated user with 
authorization to read user groups in order to execute the command.

The resolution removes command formatting based on user-provided arguments.

This issue is being tracked as NIFI-10114

Mitigation:

Disabling the ShellUserGroupProvider mitigates the vulnerability.

Re: [DISCUSS] Strategy for Dropping Java 8 Support in NiFi 2.0

[David Handermann]

Thanks for the replies Kevin and Pierre!

Various JDK vendors have different timelines for Java 11 support, some
planning to end active support in September 2023 and others in October
2024.  Either way, I agree that moving to Java 11 as the minimum version
should be a shorter duration, with the goal of making Java 17 the minimum
before too much time elapses.

As far as a general timeline for removing Java 8 support in NiFi, a good
goal in my mind would be no later than the end of this calendar year, 2022.

Regards,
David Handermann

On Wed, Jun 15, 2022 at 11:55 AM Pierre Villard 
wrote:

> I'd even love to go straight to Java 17 since it's the new LTS version...
> but this may be quite a big jump for our community and users.
> I guess we can envision a "short" 2.x release line and consider Java 17 for
> 3.x.
> Definitely approve the proposal!
>
> Le mer. 15 juin 2022 à 18:50, Kevin Doran  a écrit :
>
> > Thanks for reviving this discussion David. In light of those core
> > dependencies dropping support for Java 8, this plan seems necessary for
> > NiFi. I support the proposal.
> >
> > Thanks,
> > Kevin
> >
> > On Jun 15, 2022 at 11:48:05, David Handermann <
> exceptionfact...@apache.org
> > >
> > wrote:
> >
> > > Team,
> > >
> > > With multiple major projects in the process of sunsetting support for
> > Java
> > > 8, we should also prepare a timeline for removing Java 8 support from
> > > Apache NiFi and subprojects.
> > >
> > > BACKGROUND
> > >
> > > The Jetty project announced the end of community support for version 9
> as
> > > of 2022-06-01 [1]. Although Jetty 9 is not end of life in terms of
> > security
> > > updates, this is an important milestone as both NiFi and NiFi Registry
> > > leverage Jetty for the web application container. Jetty 10 requires
> Java
> > 11
> > > as the minimum version.
> > >
> > > The next major release of the Spring Framework will drop support for
> both
> > > Java 8 and 11, requiring Java 17 as the minimum version [2]. Other
> > > supporting components, such as OpenSAML, which enables SAML 2
> > integration,
> > > dropped support for Java 8 in OpenSAML 4 [3].
> > >
> > > In order to continue maintaining a secure product, NiFi will also need
> to
> > > remove Java 8 support so that we can track dependency upgrades.
> > >
> > > NEXT STEPS
> > >
> > > In light of widespread deployment of Apache NiFi and subprojects, we
> need
> > > to prepare a timeline for transition. Although there have been various
> > > discussions on what should be included in the next major release,
> > narrowing
> > > the focus to simply removing support for Java 8 provides the simplest
> > path
> > > forward.
> > >
> > > Announcing removal of support for Java 8 should incorporate a
> reasonable
> > > amount of time for potential transition. NiFi has supported Java 11 for
> > > multiple releases, and NiFi 1.16.0 included basic support for Java 17.
> > >
> > > At minimum, it seems best to proceed with a release for NiFi 1.17.0,
> when
> > > ready, without making any changes. At that time, we should also have a
> > > timeline for removing Java 8 support. It may be worthwhile to plan on
> at
> > > least one more minor release that incorporates deprecation warnings
> where
> > > necessary.
> > >
> > > Following a selected minor release version, a support branch for major
> > > version 1 could be created, as a means of providing critical security
> and
> > > functional fixes. With a support branch created, main development could
> > be
> > > transitioned to 2.0.0-SNAPSHOT. I defer to Joe Witt as the release
> > manager
> > > for more thought around these particular details.
> > >
> > > Please provide your thoughts on the general process, and highlight
> > > particular areas of concern.
> > >
> > > Regards,
> > > David Handermann
> > >
> > > [1] https://github.com/eclipse/jetty.project/issues/7958
> > > [2]
> > >
> > >
> >
> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
> > > [3] https://shibboleth.atlassian.net/wiki/spaces/OSAML/overview
> > >
> >
>

Re: [DISCUSS] Strategy for Dropping Java 8 Support in NiFi 2.0

[Kevin Doran]

Pierre and David, I agree with this project goals:


   - a 2.x release that drops support for Java 8 (requires at least Java
   11) by EOY
   - a 3.x release that drops support for Java 11 (requires at least Java
   17) in the not-to-distant future, perhaps 2023/24


This would also mean we could move some of the original goals of 2.x to
target the 3.x line instead, given the deadlines David identified.

Kevin

On Jun 15, 2022 at 13:20:41, David Handermann 
wrote:

> Thanks for the replies Kevin and Pierre!
>
> Various JDK vendors have different timelines for Java 11 support, some
> planning to end active support in September 2023 and others in October
> 2024.  Either way, I agree that moving to Java 11 as the minimum version
> should be a shorter duration, with the goal of making Java 17 the minimum
> before too much time elapses.
>
> As far as a general timeline for removing Java 8 support in NiFi, a good
> goal in my mind would be no later than the end of this calendar year, 2022.
>
> Regards,
> David Handermann
>
> On Wed, Jun 15, 2022 at 11:55 AM Pierre Villard <
> pierre.villard...@gmail.com>
> wrote:
>
> I'd even love to go straight to Java 17 since it's the new LTS version...
>
> but this may be quite a big jump for our community and users.
>
> I guess we can envision a "short" 2.x release line and consider Java 17 for
>
> 3.x.
>
> Definitely approve the proposal!
>
>
> Le mer. 15 juin 2022 à 18:50, Kevin Doran  a écrit :
>
>
> > Thanks for reviving this discussion David. In light of those core
>
> > dependencies dropping support for Java 8, this plan seems necessary for
>
> > NiFi. I support the proposal.
>
> >
>
> > Thanks,
>
> > Kevin
>
> >
>
> > On Jun 15, 2022 at 11:48:05, David Handermann <
>
> exceptionfact...@apache.org
>
> > >
>
> > wrote:
>
> >
>
> > > Team,
>
> > >
>
> > > With multiple major projects in the process of sunsetting support for
>
> > Java
>
> > > 8, we should also prepare a timeline for removing Java 8 support from
>
> > > Apache NiFi and subprojects.
>
> > >
>
> > > BACKGROUND
>
> > >
>
> > > The Jetty project announced the end of community support for version 9
>
> as
>
> > > of 2022-06-01 [1]. Although Jetty 9 is not end of life in terms of
>
> > security
>
> > > updates, this is an important milestone as both NiFi and NiFi Registry
>
> > > leverage Jetty for the web application container. Jetty 10 requires
>
> Java
>
> > 11
>
> > > as the minimum version.
>
> > >
>
> > > The next major release of the Spring Framework will drop support for
>
> both
>
> > > Java 8 and 11, requiring Java 17 as the minimum version [2]. Other
>
> > > supporting components, such as OpenSAML, which enables SAML 2
>
> > integration,
>
> > > dropped support for Java 8 in OpenSAML 4 [3].
>
> > >
>
> > > In order to continue maintaining a secure product, NiFi will also need
>
> to
>
> > > remove Java 8 support so that we can track dependency upgrades.
>
> > >
>
> > > NEXT STEPS
>
> > >
>
> > > In light of widespread deployment of Apache NiFi and subprojects, we
>
> need
>
> > > to prepare a timeline for transition. Although there have been various
>
> > > discussions on what should be included in the next major release,
>
> > narrowing
>
> > > the focus to simply removing support for Java 8 provides the simplest
>
> > path
>
> > > forward.
>
> > >
>
> > > Announcing removal of support for Java 8 should incorporate a
>
> reasonable
>
> > > amount of time for potential transition. NiFi has supported Java 11 for
>
> > > multiple releases, and NiFi 1.16.0 included basic support for Java 17.
>
> > >
>
> > > At minimum, it seems best to proceed with a release for NiFi 1.17.0,
>
> when
>
> > > ready, without making any changes. At that time, we should also have a
>
> > > timeline for removing Java 8 support. It may be worthwhile to plan on
>
> at
>
> > > least one more minor release that incorporates deprecation warnings
>
> where
>
> > > necessary.
>
> > >
>
> > > Following a selected minor release version, a support branch for major
>
> > > version 1 could be created, as a means of providing critical security
>
> and
>
> > > functional fixes. With a support branch created, main development could
>
> > be
>
> > > transitioned to 2.0.0-SNAPSHOT. I defer to Joe Witt as the release
>
> > manager
>
> > > for more thought around these particular details.
>
> > >
>
> > > Please provide your thoughts on the general process, and highlight
>
> > > particular areas of concern.
>
> > >
>
> > > Regards,
>
> > > David Handermann
>
> > >
>
> > > [1] https://github.com/eclipse/jetty.project/issues/7958
>
> > > [2]
>
> > >
>
> > >
>
> >
>
>
> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
>
> > > [3] https://shibboleth.atlassian.net/wiki/spaces/OSAML/overview
>
> > >
>
> >
>
>
>

[DISCUSS] Strategy for Dropping Java 8 Support in NiFi 2.0

[David Handermann]

Team,

With multiple major projects in the process of sunsetting support for Java
8, we should also prepare a timeline for removing Java 8 support from
Apache NiFi and subprojects.

BACKGROUND

The Jetty project announced the end of community support for version 9 as
of 2022-06-01 [1]. Although Jetty 9 is not end of life in terms of security
updates, this is an important milestone as both NiFi and NiFi Registry
leverage Jetty for the web application container. Jetty 10 requires Java 11
as the minimum version.

The next major release of the Spring Framework will drop support for both
Java 8 and 11, requiring Java 17 as the minimum version [2]. Other
supporting components, such as OpenSAML, which enables SAML 2 integration,
dropped support for Java 8 in OpenSAML 4 [3].

In order to continue maintaining a secure product, NiFi will also need to
remove Java 8 support so that we can track dependency upgrades.

NEXT STEPS

In light of widespread deployment of Apache NiFi and subprojects, we need
to prepare a timeline for transition. Although there have been various
discussions on what should be included in the next major release, narrowing
the focus to simply removing support for Java 8 provides the simplest path
forward.

Announcing removal of support for Java 8 should incorporate a reasonable
amount of time for potential transition. NiFi has supported Java 11 for
multiple releases, and NiFi 1.16.0 included basic support for Java 17.

At minimum, it seems best to proceed with a release for NiFi 1.17.0, when
ready, without making any changes. At that time, we should also have a
timeline for removing Java 8 support. It may be worthwhile to plan on at
least one more minor release that incorporates deprecation warnings where
necessary.

Following a selected minor release version, a support branch for major
version 1 could be created, as a means of providing critical security and
functional fixes. With a support branch created, main development could be
transitioned to 2.0.0-SNAPSHOT. I defer to Joe Witt as the release manager
for more thought around these particular details.

Please provide your thoughts on the general process, and highlight
particular areas of concern.

Regards,
David Handermann

[1] https://github.com/eclipse/jetty.project/issues/7958
[2]
https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
[3] https://shibboleth.atlassian.net/wiki/spaces/OSAML/overview

Re: [DISCUSS] Strategy for Dropping Java 8 Support in NiFi 2.0

[Kevin Doran]

Thanks for reviving this discussion David. In light of those core
dependencies dropping support for Java 8, this plan seems necessary for
NiFi. I support the proposal.

Thanks,
Kevin

On Jun 15, 2022 at 11:48:05, David Handermann 
wrote:

> Team,
>
> With multiple major projects in the process of sunsetting support for Java
> 8, we should also prepare a timeline for removing Java 8 support from
> Apache NiFi and subprojects.
>
> BACKGROUND
>
> The Jetty project announced the end of community support for version 9 as
> of 2022-06-01 [1]. Although Jetty 9 is not end of life in terms of security
> updates, this is an important milestone as both NiFi and NiFi Registry
> leverage Jetty for the web application container. Jetty 10 requires Java 11
> as the minimum version.
>
> The next major release of the Spring Framework will drop support for both
> Java 8 and 11, requiring Java 17 as the minimum version [2]. Other
> supporting components, such as OpenSAML, which enables SAML 2 integration,
> dropped support for Java 8 in OpenSAML 4 [3].
>
> In order to continue maintaining a secure product, NiFi will also need to
> remove Java 8 support so that we can track dependency upgrades.
>
> NEXT STEPS
>
> In light of widespread deployment of Apache NiFi and subprojects, we need
> to prepare a timeline for transition. Although there have been various
> discussions on what should be included in the next major release, narrowing
> the focus to simply removing support for Java 8 provides the simplest path
> forward.
>
> Announcing removal of support for Java 8 should incorporate a reasonable
> amount of time for potential transition. NiFi has supported Java 11 for
> multiple releases, and NiFi 1.16.0 included basic support for Java 17.
>
> At minimum, it seems best to proceed with a release for NiFi 1.17.0, when
> ready, without making any changes. At that time, we should also have a
> timeline for removing Java 8 support. It may be worthwhile to plan on at
> least one more minor release that incorporates deprecation warnings where
> necessary.
>
> Following a selected minor release version, a support branch for major
> version 1 could be created, as a means of providing critical security and
> functional fixes. With a support branch created, main development could be
> transitioned to 2.0.0-SNAPSHOT. I defer to Joe Witt as the release manager
> for more thought around these particular details.
>
> Please provide your thoughts on the general process, and highlight
> particular areas of concern.
>
> Regards,
> David Handermann
>
> [1] https://github.com/eclipse/jetty.project/issues/7958
> [2]
>
> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
> [3] https://shibboleth.atlassian.net/wiki/spaces/OSAML/overview
>

[DISCUSS] Release for NAR Maven Plugin

[Kevin Doran]

All,

If there are no objections, I would like to put out a maintenance release
(1.3.4) of the NAR Maven plugin, which has had some recent bug fixes and
improvements:


   1. https://issues.apache.org/jira/browse/NIFI-10011
   2. https://issues.apache.org/jira/browse/NIFI-9856
   3. https://issues.apache.org/jira/browse/NIFI-9857


I would be glad to take the role of RM for this release.

Thanks,
Kevin

Re: [DISCUSS] Release for NAR Maven Plugin

[Joe Witt]

+1

On Wed, Jun 15, 2022 at 9:41 AM Kevin Doran  wrote:

> All,
>
> If there are no objections, I would like to put out a maintenance release
> (1.3.4) of the NAR Maven plugin, which has had some recent bug fixes and
> improvements:
>
>
>1. https://issues.apache.org/jira/browse/NIFI-10011
>2. https://issues.apache.org/jira/browse/NIFI-9856
>3. https://issues.apache.org/jira/browse/NIFI-9857
>
>
> I would be glad to take the role of RM for this release.
>
> Thanks,
> Kevin
>

Re: [DISCUSS] Release for NAR Maven Plugin

[David Handermann]

Thanks Kevin, +1 for preparing a release of the NAR Maven plugin.

Regards,
David Handermann

On Wed, Jun 15, 2022 at 11:58 AM Joe Witt  wrote:

> +1
>
> On Wed, Jun 15, 2022 at 9:41 AM Kevin Doran  wrote:
>
> > All,
> >
> > If there are no objections, I would like to put out a maintenance release
> > (1.3.4) of the NAR Maven plugin, which has had some recent bug fixes and
> > improvements:
> >
> >
> >1. https://issues.apache.org/jira/browse/NIFI-10011
> >2. https://issues.apache.org/jira/browse/NIFI-9856
> >3. https://issues.apache.org/jira/browse/NIFI-9857
> >
> >
> > I would be glad to take the role of RM for this release.
> >
> > Thanks,
> > Kevin
> >
>

Re: [DISCUSS] Strategy for Dropping Java 8 Support in NiFi 2.0

[Pierre Villard]

I'd even love to go straight to Java 17 since it's the new LTS version...
but this may be quite a big jump for our community and users.
I guess we can envision a "short" 2.x release line and consider Java 17 for
3.x.
Definitely approve the proposal!

Le mer. 15 juin 2022 à 18:50, Kevin Doran  a écrit :

> Thanks for reviving this discussion David. In light of those core
> dependencies dropping support for Java 8, this plan seems necessary for
> NiFi. I support the proposal.
>
> Thanks,
> Kevin
>
> On Jun 15, 2022 at 11:48:05, David Handermann  >
> wrote:
>
> > Team,
> >
> > With multiple major projects in the process of sunsetting support for
> Java
> > 8, we should also prepare a timeline for removing Java 8 support from
> > Apache NiFi and subprojects.
> >
> > BACKGROUND
> >
> > The Jetty project announced the end of community support for version 9 as
> > of 2022-06-01 [1]. Although Jetty 9 is not end of life in terms of
> security
> > updates, this is an important milestone as both NiFi and NiFi Registry
> > leverage Jetty for the web application container. Jetty 10 requires Java
> 11
> > as the minimum version.
> >
> > The next major release of the Spring Framework will drop support for both
> > Java 8 and 11, requiring Java 17 as the minimum version [2]. Other
> > supporting components, such as OpenSAML, which enables SAML 2
> integration,
> > dropped support for Java 8 in OpenSAML 4 [3].
> >
> > In order to continue maintaining a secure product, NiFi will also need to
> > remove Java 8 support so that we can track dependency upgrades.
> >
> > NEXT STEPS
> >
> > In light of widespread deployment of Apache NiFi and subprojects, we need
> > to prepare a timeline for transition. Although there have been various
> > discussions on what should be included in the next major release,
> narrowing
> > the focus to simply removing support for Java 8 provides the simplest
> path
> > forward.
> >
> > Announcing removal of support for Java 8 should incorporate a reasonable
> > amount of time for potential transition. NiFi has supported Java 11 for
> > multiple releases, and NiFi 1.16.0 included basic support for Java 17.
> >
> > At minimum, it seems best to proceed with a release for NiFi 1.17.0, when
> > ready, without making any changes. At that time, we should also have a
> > timeline for removing Java 8 support. It may be worthwhile to plan on at
> > least one more minor release that incorporates deprecation warnings where
> > necessary.
> >
> > Following a selected minor release version, a support branch for major
> > version 1 could be created, as a means of providing critical security and
> > functional fixes. With a support branch created, main development could
> be
> > transitioned to 2.0.0-SNAPSHOT. I defer to Joe Witt as the release
> manager
> > for more thought around these particular details.
> >
> > Please provide your thoughts on the general process, and highlight
> > particular areas of concern.
> >
> > Regards,
> > David Handermann
> >
> > [1] https://github.com/eclipse/jetty.project/issues/7958
> > [2]
> >
> >
> https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
> > [3] https://shibboleth.atlassian.net/wiki/spaces/OSAML/overview
> >
>

[DISCUSS] Distributed tracing using OpenTelemetry

[Brian Putt]

Hello Apache NiFi,

I'd like to discuss implementing NIFI-10110 which adds OpenTelemetry
integration into NiFi. Tracing will provide a way to identify
bottlenecks within various flows and propagate trace information to
downstream systems (whether they're another NiFi cluster or otherwise).

I wanted to get the community's feedback to see if this makes sense and if
it's something that you'd find valuable. If so, would anyone be interested
in discussing implementation details? We'd certainly be willing to
implement this feature, but feel it will need feedback from the community
as we add the integration.

Some key areas around implementation will involve where it makes sense to
add the OpenTelemetry wrapper because ideally, processors get tracing 'for
free' and this then leads to other questions as to sampling and how to
expose flowfile attributes into span tags that get emitted.

OpenTelemetry offers a Java library that's licensed under Apache 2.

DATA Pill - knowledge-sharing project

[Sylwia Kołpuć]

Hi,

As we are a community focused around Apache NiFi I thought I would send you
some information about the new DATA Pill project.

I hope you will be interested because it covers our area and the project is
focused on highly selected content for specialists.

It is also a community-driven project.

DATA Pill is a weekly newsletter with an overview of the best Big Data,
Cloud and AI/ML content.


   -

   filtered content from over 200 sources
   -

   extracts from articles, tutorials, podcasts, youtube, etc


   -

   a simple mail with a condensed form that you can skim through in just 10
   minutes
   -

   reminders of upcoming meetups and events


*Here you can see examples of previous mails: DATA PiIl*
, so you can decide if it's something for you.

It started from the internal slack channel where we shared interesting
links.

Over time, the idea arose to organize this content more and gather it in
one place

so that it would not get lost amongst hundreds of notifications.

Since we started doing this, browsing through even more sources of
information,

someone threw in a thought: why not share it and allow everyone to
subscribe?

We also want to involve everyone who is interested in creating this
newsletter.

We are in ongoing communication by mail and we are looking for a place
where we could interact more.

Any ideas are welcomed.


[image: DATA Pill fb.jpg]



Cheers!
Sylwia from GetInData