Derby
  1. Derby
  2. DERBY-2436

SYSCS_IMPORT_TABLE can be used to read derby files

    Details

    • Urgency:
      Normal
    • Bug behavior facts:
      Regression, Security

      Description

      There are no controls over which files SYSCS_IMPORT_TABLE can read, thus allowing any user that has permission to execute the procedure to try and access information that they have no permissions to do so. E.g. even with the secure-by-default network server I can execute three lines of SQL to view to contents of derby.properties, thus seeing passwords of other users, or the address of the ldap server.

      create table t (c varchar(32000));
      CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE(NULL, 'T', 'derby.properties', NULL, NULL, 'ISO8859_1', 0);

      ij> select * from T;
      C

      ----------------------------------------------
      derby.connection.requireAuthentication=true
      derby.authentication.provider=BUILTIN
      derby.user.SA=sapwd
      derby.user.MARY=marypwd

      Also a similar trick could be attempted against the actual data files, allowing a user to attempt to bypass grant/revoke security, especially no that binary data can be exported/imported.

        Issue Links

          Activity

          Hide
          Kathey Marsden added a comment -

          Taking off the High Value Fix list. A good way to fix this without compatibility issues has not presented itself.

          Show
          Kathey Marsden added a comment - Taking off the High Value Fix list. A good way to fix this without compatibility issues has not presented itself.
          Hide
          Kathey Marsden added a comment -

          Marking normal urgency and HVF. This won't make it for 10.5.2.

          Show
          Kathey Marsden added a comment - Marking normal urgency and HVF. This won't make it for 10.5.2.
          Hide
          Kathey Marsden added a comment -

          Based on Dan's comments, this is a security regression. Marking the regression flag.

          Show
          Kathey Marsden added a comment - Based on Dan's comments, this is a security regression. Marking the regression flag.
          Hide
          Daniel John Debrunner added a comment -

          One also has to consider files/databases from other Derby systems.

          E.g. derby.properties/derby.log should not be readable/writeable through the import/export routines regardless of if its in $

          {derby.system.home}

          or $

          {user.dir}
          Show
          Daniel John Debrunner added a comment - One also has to consider files/databases from other Derby systems. E.g. derby.properties/derby.log should not be readable/writeable through the import/export routines regardless of if its in $ {derby.system.home} or $ {user.dir}
          Hide
          Kathey Marsden added a comment -

          Mike asked:
          >I am not sure how this maps to specific security policies. What do we do with user java functions/procedures? How do we >handle
          >security for those procedures reading/writing database files.

          I think that it is controlled by the permissions for whatever jar contains the procedure. I am not sure about jars in the database though.

          >it seems like import should read files using no policy that has been granted to derby for database processing, and >similarly export should write files using no policy that has been granted to derby for database processing.

          We grant
          permission java.io.FilePermission "$

          {derby.system.home}

          ","read"; to derby.jar in order to grant read permission to derby.properties and the directory contents. Using the anti-policy philosophy, we would need to disallow completely access to derby.system.home and perhaps user.home if derby.system.home is not set. I think that may be too restrictive and cause regression if users put files user.dir or derby.system.home. As long as we restrict read/write of derby.properties, derby.log and database directories I think we should be covered. How to do this, I do not yet know.

          Show
          Kathey Marsden added a comment - Mike asked: >I am not sure how this maps to specific security policies. What do we do with user java functions/procedures? How do we >handle >security for those procedures reading/writing database files. I think that it is controlled by the permissions for whatever jar contains the procedure. I am not sure about jars in the database though. >it seems like import should read files using no policy that has been granted to derby for database processing, and >similarly export should write files using no policy that has been granted to derby for database processing. We grant permission java.io.FilePermission "$ {derby.system.home} ","read"; to derby.jar in order to grant read permission to derby.properties and the directory contents. Using the anti-policy philosophy, we would need to disallow completely access to derby.system.home and perhaps user.home if derby.system.home is not set. I think that may be too restrictive and cause regression if users put files user.dir or derby.system.home. As long as we restrict read/write of derby.properties, derby.log and database directories I think we should be covered. How to do this, I do not yet know.
          Hide
          Mike Matrigali added a comment -

          I am not sure how this maps to specific security policies. What do we do with user java functions/procedures? How do we handle
          security for those procedures reading/writing database files.

          It seems like import should read files using no policy that has been granted to derby for database processing, and similarly
          export should write files using no policy that has been granted to derby for database processing.

          Show
          Mike Matrigali added a comment - I am not sure how this maps to specific security policies. What do we do with user java functions/procedures? How do we handle security for those procedures reading/writing database files. It seems like import should read files using no policy that has been granted to derby for database processing, and similarly export should write files using no policy that has been granted to derby for database processing.
          Hide
          Kathey Marsden added a comment -

          So I think the restrictions for import/export should be for derby.system.home/derby.properties derby.system.home/derby.log (or user.dir/derby.properties, user.dir/derby.log if derby.system.home is not set) and anything under a database directory Does that sound correct?

          Show
          Kathey Marsden added a comment - So I think the restrictions for import/export should be for derby.system.home/derby.properties derby.system.home/derby.log (or user.dir/derby.properties, user.dir/derby.log if derby.system.home is not set) and anything under a database directory Does that sound correct?
          Hide
          Daniel John Debrunner added a comment -

          It may be that 10.3 is less secure than previous versions since the ability to export/import CLOB/BLOB data was added.
          This may provide the additional ability to read/write raw database pages, thus bypassing any grant/revoke security
          but as Rick says in a G/R environment this ability can be limited (to the dbo and other trusted users).

          Show
          Daniel John Debrunner added a comment - It may be that 10.3 is less secure than previous versions since the ability to export/import CLOB/BLOB data was added. This may provide the additional ability to read/write raw database pages, thus bypassing any grant/revoke security but as Rick says in a G/R environment this ability can be limited (to the dbo and other trusted users).
          Hide
          Rick Hillegas added a comment -

          I think that this is a serious security hole. It is paired with the related problem that you can use EXPORT and BACKUP to trash derby.properties and data files--and even non-Derby files depending on the privileges granted to the account which boots the server. It may be comforting that these attacks can be limited to database owners.

          I think we still have a long way to go in shoring up Derby's security mechanisms. For instance, even allowing customers to store passwords in plaintext in derby.properties seems to me to be a bit goofy. I would not single out this jira as the blocker which makes Derby intolerably unsafe.

          Show
          Rick Hillegas added a comment - I think that this is a serious security hole. It is paired with the related problem that you can use EXPORT and BACKUP to trash derby.properties and data files--and even non-Derby files depending on the privileges granted to the account which boots the server. It may be comforting that these attacks can be limited to database owners. I think we still have a long way to go in shoring up Derby's security mechanisms. For instance, even allowing customers to store passwords in plaintext in derby.properties seems to me to be a bit goofy. I would not single out this jira as the blocker which makes Derby intolerably unsafe.
          Hide
          Kathey Marsden added a comment -

          Changing affects version to 10.1 as I was able to reproduce the issue there. This seems like quite a big hole. Should it be a blocker for 10.3 since we are billing security improvements? Does anyone have plans to fix? As soon as we get a fix I would be willing to backport to 10.1/10.2 and notify the user community.

          Show
          Kathey Marsden added a comment - Changing affects version to 10.1 as I was able to reproduce the issue there. This seems like quite a big hole. Should it be a blocker for 10.3 since we are billing security improvements? Does anyone have plans to fix? As soon as we get a fix I would be willing to backport to 10.1/10.2 and notify the user community.
          Hide
          Daniel John Debrunner added a comment -

          Is a new bug for 10.3 since that's the release that introduced being able to import CLOB/BLOB data

          Show
          Daniel John Debrunner added a comment - Is a new bug for 10.3 since that's the release that introduced being able to import CLOB/BLOB data

            People

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

              Dates

              • Created:
                Updated:

                Development