Derby
  1. Derby
  2. DERBY-2437

SYSCS_EXPORT_TABLE can be used to overwrite derby files

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 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.1.4, 10.4.1.3
    • Fix Version/s: 10.3.1.4, 10.4.1.3
    • Component/s: None
    • Labels:
      None
    • Bug behavior facts:
      Regression, Security

      Description

      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.

        Issue Links

          Activity

          Hide
          Daniel John Debrunner added a comment -

          Think this affects all releases. The ability to export BLOB types might make it more serious in 10.3

          Show
          Daniel John Debrunner added a comment - Think this affects all releases. The ability to export BLOB types might make it more serious in 10.3
          Hide
          Kathey Marsden added a comment -

          Mike asked me to check and see if this was a regression or not (Does export of BLOB make DERBY less secure). I was able to totally corrupt a 10.1 database with export by exporting a text file over a binary file, so I don't think this is a regression, but it is an extremely serious bug.

          Show
          Kathey Marsden added a comment - Mike asked me to check and see if this was a regression or not (Does export of BLOB make DERBY less secure). I was able to totally corrupt a 10.1 database with export by exporting a text file over a binary file, so I don't think this is a regression, but it is an extremely serious bug.
          Hide
          Daniel John Debrunner added a comment -

          Exporting BLOB data allows one to write a valid data page with modified data, e.g. increase one's salary.

          Show
          Daniel John Debrunner added a comment - Exporting BLOB data allows one to write a valid data page with modified data, e.g. increase one's salary.
          Hide
          Kathey Marsden added a comment -

          Based on Dan's comments on vulnerabilities which did not exist before I think this should be marked as a security regression.

          Show
          Kathey Marsden added a comment - Based on Dan's comments on vulnerabilities which did not exist before I think this should be marked as a security regression.
          Hide
          Mike Matrigali added a comment -

          I think that a creative hacker could use long varchar in pre-10.3 release to do almost all the kinds of things that dan describes being able to do with 10.3 for export. About the only hard thing is the delimiter which might present problems depending on the actual ddl of the table being attacked.

          Show
          Mike Matrigali added a comment - I think that a creative hacker could use long varchar in pre-10.3 release to do almost all the kinds of things that dan describes being able to do with 10.3 for export. About the only hard thing is the delimiter which might present problems depending on the actual ddl of the table being attacked.
          Hide
          Mike Matrigali added a comment -

          I would like to see a discussion of the right way to fix the import and export issue. The following is only a stop gap but may be better than nothing, but may be easy and at least plug some holes. What about changing export to not do the write if the file already exists. At least that stops over-writing exising database and property files. Adding new database files does not do much as the system has to find them in existing system catalogs.

          Does not solve creating a new property file where one did not exist.
          Does not solve creating new recovery log files with just the right name and crashing the system to get it to use those files.

          Also may create an upward incompatibility where we use to allow overwrite. We certainly don't document that we allow that. Seems like most would not complain if we gave a reasonable error message saying export failed because a file with that name already existed, and to delete the file and retry the export.

          Show
          Mike Matrigali added a comment - I would like to see a discussion of the right way to fix the import and export issue. The following is only a stop gap but may be better than nothing, but may be easy and at least plug some holes. What about changing export to not do the write if the file already exists. At least that stops over-writing exising database and property files. Adding new database files does not do much as the system has to find them in existing system catalogs. Does not solve creating a new property file where one did not exist. Does not solve creating new recovery log files with just the right name and crashing the system to get it to use those files. Also may create an upward incompatibility where we use to allow overwrite. We certainly don't document that we allow that. Seems like most would not complain if we gave a reasonable error message saying export failed because a file with that name already existed, and to delete the file and retry the export.
          Hide
          Rick Hillegas added a comment -

          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.

          Show
          Rick Hillegas added a comment - 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.
          Hide
          Daniel John Debrunner added a comment -

          Reading the password of a user in a secure system will most likely be impossible, e.g. an LDAP scheme, so that attack by the DBA might be harder, though it probably would be possible for the DBA to change the authentication to suite their attack.

          It's not the DBA that is the concern though, it's whoever the DBA has already granted import/export capability to. They might have granted those permissions (to execute those procedures) assuming they would not grant complete access to every database, thus bypassing grant/revoke and authentication.

          Show
          Daniel John Debrunner added a comment - Reading the password of a user in a secure system will most likely be impossible, e.g. an LDAP scheme, so that attack by the DBA might be harder, though it probably would be possible for the DBA to change the authentication to suite their attack. It's not the DBA that is the concern though, it's whoever the DBA has already granted import/export capability to. They might have granted those permissions (to execute those procedures) assuming they would not grant complete access to every database, thus bypassing grant/revoke and authentication.
          Hide
          Daniel John Debrunner added a comment -

          Good point on the LONG VARCHAR/VARBINARY, maybe it was possible before 10.3, though potentially harder.

          Show
          Daniel John Debrunner added a comment - Good point on the LONG VARCHAR/VARBINARY, maybe it was possible before 10.3, though potentially harder.
          Hide
          Daniel John Debrunner added a comment -

          The DBA is a concern for attacking a different database though, one they have no authorization or authentication for.

          Show
          Daniel John Debrunner added a comment - The DBA is a concern for attacking a different database though, one they have no authorization or authentication for.
          Hide
          Rick Hillegas added a comment -

          The attack seems to depend on the DBA's ethics and her judgment about delegating responsibility.

          Show
          Rick Hillegas added a comment - The attack seems to depend on the DBA's ethics and her judgment about delegating responsibility.
          Hide
          Ramin Moazeni added a comment -

          resolved in trunk (revision #561546) and 10.3 (revision #561638)

          Show
          Ramin Moazeni added a comment - resolved in trunk (revision #561546) and 10.3 (revision #561638)

            People

            • Assignee:
              Unassigned
              Reporter:
              Daniel John Debrunner
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development