[
https://issues.apache.org/jira/browse/NIFI-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525803#comment-17525803
]
Joe Witt commented on NIFI-9855:
--------------------------------
Hello. It isn't that it wont gain traction but rather it is that we've
approached a solution for this in other ways. For instance, you can take
advantage of the restricted components concept to limit authority to a very
select set of users that can manipulate such dangerous/powerful components.
There are actually a range of complex scenarios beyond what is even laid out
here. That is the other edge of the double edge sword of power here.
Ultimately we have chosen to give fine grained authority for such components
that can interact with the local file system. Ruining data is just as
problematic as reading certain data.
The references to 'attacker' here are probably misleading. The real issue is
really 'any properly authorized user knowing/unknowingly could cause bad things
to happen'. We also have components which execute system commands, etc.. Thus
we have fine grained controls and auditing and provenance, etc..
We *could* literally offer a 'block list' of directories that components could
opt-in to checking and blocking. But at a framework level we cannot force/stop
such things. Ultimately we'd need those who built processors (even custom ones
or scripted ones) to opt in to such checks. This would really defeat the
intent. Thus..we're back to why we have focused on authorization as a key
answer here.
> NiFi Can Delete Its Own Configuration Files
> -------------------------------------------
>
> Key: NIFI-9855
> URL: https://issues.apache.org/jira/browse/NIFI-9855
> Project: Apache NiFi
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.16.0, 1.15.2, 1.15.3
> Environment: All Linux Distros
> Reporter: Mike R
> Priority: Major
>
> Using the GetFile and PutFile processors, an attacker could overwrite the
> configuration files to the /dev/null. Using a regex of (.*?), an attacker
> could point the GetFile Processor to the directory which the NiFi
> configuration files are located in. If the attacker is able to login, they
> can send the files to /dev/null on Linux, which although it will cause a
> warning in the PutFile processor, it will still process.
> This does not require that the attacker have access to the underlying system,
> but rather just NiFi itself.
> The ways to prevent this from happening would be to prevent the GetFile
> Processor and other NiFi processors from being able to directly read files
> from the configuration directories in a way that deletes the existing files
> and another option would be to have processors prevented from overwriting
> configuration directory files.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
