[
https://issues.apache.org/jira/browse/DERBY-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511221
]
Rick Hillegas commented on DERBY-2437:
--------------------------------------
I am trying to wrap my mind around how much incremental exposure is introduced
by the ability to import/export LOBs. In a properly secured system, this power
would be limited to the database owner. Currently, the database owner enjoys
godlike powers, including the ability to read and change everyone's passwords.
If I were a DBA bent on increasing my salary, I don't think I would use
import/export to do this. The following seems like a much more straightforward
approach:
1) Read the password of the schema which owns the salary table.
2) Log in as that user.
3) Change my salary.
4) Log out.
> SYSCS_EXPORT_TABLE can be used to overwrite derby files
> -------------------------------------------------------
>
> Key: DERBY-2437
> URL: https://issues.apache.org/jira/browse/DERBY-2437
> Project: Derby
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.0.0, 10.3.1.0, 10.3.1.1, 10.4.0.0
> Reporter: Daniel John Debrunner
> Priority: Critical
>
> here are no controls over which files SYSCS_EXPORT_TABLE can write, thus
> allowing any user that has permission to execute the procedure to try and
> modufy information that they have no permissions to do.
> In a similar fashion to the one described in DERBY-2436 I could overwrite
> derby.properties at least leaqding to a dnial of service attack on the next
> re-boot.
> With more time it might be possible to write out a valid properties file
> which would allow chaning the authentication, silentaly adding a new user etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
