Bug 478235 - MIGRATED_FROM_JIRA: THIS IS REALLY SERIOUS: Bind erroneously fails for certain cases of non-existant bind-DNs
MIGRATED_FROM_JIRA: THIS IS REALLY SERIOUS: Bind erroneously fails for certai...
Status: MODIFIED
Product: penrose
Classification: Retired
Component: Unknown (Show other bugs)
2.0
All Linux
low Severity low
: ---
: ---
Assigned To: Endi Sukma Dewata
Ben Levenson
:
Depends On:
Blocks: 471500
  Show dependency treegraph
 
Reported: 2008-12-27 03:10 EST by Chandrasekar Kannan
Modified: 2015-01-04 19:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chandrasekar Kannan 2008-12-27 03:10:57 EST
Let there be a partition configuration with a statically defined admin-user, i.e. a partition structure like this:
* PARTITION: DEFAULT
** ENTRY: ou=admin
*** ENTRY: cn=administrator,ou=admin

If a bind is attempted using {{cn=DOESNTMATTER,ou=admin}} the bind will always _succeed_ regardless of the secret. In other words: all bind attempts against a non-existing DN below a statically defined entry will erroneously succeed. I guess this bug can be exploited to gain at least read-only access to just about any penrose-1.2.4 directory.

The cause is, IMHO, the code in HandlerManager.bind(): the partition's entries are searched, but if no entry matches, it will silently return, which is, of course, the wrong thing to do in a throw-exception-on-failure approach.

Attached patch will fix the problem.
Additional Comments From endisd dated Thu Jan 24 20:07:19 CST 2008 
This issue is fixed or no longer reproducible in Penrose 1.2.5 and 2.0.


=========================================================
Issue dump from jira
$VAR1 = {
          'priority' => '2',
          'customFieldValues' => [],
          'project' => 'PENROSE',
          'status' => '5',
          'components' => [
                            {}
                          ],
          'attachmentNames' => 'HandlerManager.patch',
          'reporter' => 'hennejg',
          'key' => 'PENROSE-266',
          'assignee' => 'endisd',
          'summary' => 'THIS IS REALLY SERIOUS: Bind erroneously fails for certain cases of non-existant bind-DNs',
          'id' => '10881',
          'updated' => '2008-01-24 20:07:35.0',
          'votes' => '0',
          'fixVersions' => [
                           {
                             'releaseDate' => '2008-04-14 00:00:00.0',
                             'sequence' => '27',
                             'name' => 'Penrose-1.2.5',
                             'released' => 'true',
                             'id' => '10124',
                             'archived' => 'false'
                           },
                           {
                             'releaseDate' => '2008-04-07 00:00:00.0',
                             'sequence' => '28',
                             'name' => 'Penrose-2.0RC1',
                             'released' => 'true',
                             'id' => '10093',
                             'archived' => 'false'
                           }
                         ],
          'description' => 'Let there be a partition configuration with a statically defined admin-user, i.e. a partition structure like this:
* PARTITION: DEFAULT
** ENTRY: ou=admin
*** ENTRY: cn=administrator,ou=admin

If a bind is attempted using {{cn=DOESNTMATTER,ou=admin}} the bind will always _succeed_ regardless of the secret. In other words: all bind attempts against a non-existing DN below a statically defined entry will erroneously succeed. I guess this bug can be exploited to gain at least read-only access to just about any penrose-1.2.4 directory.

The cause is, IMHO, the code in HandlerManager.bind(): the partition's entries are searched, but if no entry matches, it will silently return, which is, of course, the wrong thing to do in a throw-exception-on-failure approach.

Attached patch will fix the problem.',
          'affectsVersions' => [
                               {
                                 'releaseDate' => '2007-07-17 00:00:00.0',
                                 'sequence' => '26',
                                 'name' => 'Penrose-1.2.4',
                                 'released' => 'true',
                                 'id' => '10123',
                                 'archived' => 'false'
                               }
                             ],
          'created' => '2007-10-09 09:56:34.0',
          'resolution' => '1',
          'type' => '1'
        };


=========================================================
Comment 1 Chandrasekar Kannan 2008-12-27 03:11:00 EST
Marking bug as MODIFIED as it was already resolved in Jira - PENROSE-266

Note You need to log in before you can comment on or make changes to this bug.