Bug 478235

Summary: MIGRATED_FROM_JIRA: THIS IS REALLY SERIOUS: Bind erroneously fails for certain cases of non-existant bind-DNs
Product: [Retired] penrose Reporter: Chandrasekar Kannan <ckannan>
Component: UnknownAssignee: Endi Sukma Dewata <edewata>
Status: CLOSED EOL QA Contact: Ben Levenson <benl>
Severity: low Docs Contact:
Priority: low    
Version: 2.0CC: benl
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 18:39:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 471500    

Description Chandrasekar Kannan 2008-12-27 08:10:57 UTC
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 08:11:00 UTC
Marking bug as MODIFIED as it was already resolved in Jira - PENROSE-266