OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/7495
Full headers

From: michael@stroeder.com
Subject: access filter not correctly validated if assertion attribute not requested
Compose comment
Download message
State:
2 replies: 1 2
3 followups: 1 2 3

Major security issue: yes  no

Notes:

Notification:


Date: Thu, 17 Jan 2013 09:00:13 +0000
From: michael@stroeder.com
To: openldap-its@OpenLDAP.org
Subject: access filter not correctly validated if assertion attribute not requested
Full_Name: Michael Str.der
Version: RE24 6f33e2c
OS: Debian Squeeze
URL: 
Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f)


This is tested with RE24 built for Debian Squeeze:
It seems that ACLs are not correctly evaluated when processing a search request
if the assertion type is not requested in the search request.

Example:

access to
  dn.subtree="o=example"
  attrs=sambaNTPassword
  filter="(organizationalStatus=0)"
    by group="uid=samba_dc,o=example" write
    by group="cn=slapd Admins,ou=groups,o=example" =sw
    by self =w
    by * none

The following search correctly returns attribute sambaNTPassword of the entry:

ldapsearch -LLL -X "dn:uid=samba_dc,o=example"
"(&(objectclass=sambaSamAccount)(uid=wtester))" organizationalStatus
sambaNTPassword

But this search does not return sambaNTPassword:

ldapsearch -LLL -X "dn:uid=samba_dc,o=example"
"(&(objectclass=sambaSamAccount)(uid=wtester))" sambaNTPassword

I cannot find any hint in slapd.access(5) that this is expected behaviour.

Followup 1

Download message
Date: Thu, 17 Jan 2013 11:51:47 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#7495) access filter not correctly validated if assertion
 attribute not requested
Sorry for the confusion caused by editing what I've copied from the real
system before which uses a group for several Samba DC instances.

In this example the ACL part should be more simple like this:

access to
  dn.subtree="o=example"
  attrs=sambaNTPassword
  filter="(organizationalStatus=0)"
    by dn.exact="uid=samba_dc,o=example" write
    by group="cn=slapd Admins,ou=groups,o=example" =sw
    by self =w
    by * none

Ciao, Michael.



Reply 1

Resend
From: Hallvard B Furuseth <openldap-its@OpenLDAP.org>
To: michael@stroeder.com
Subject: Re: (ITS#7495) access filter not correctly validated if assertion attribute not requested
Date: Thu Jan 17 23:44:58 2013
Cannot reproduce on RedHat Linux, x86_64.  But then, the info was
rather brief. (E.g. which backend? Was that a per-backend or global
ACL? Might some overlays or other access statements interefere?)

Anyway, please provide a complete config and preferably LDIF which
demonstrates the problem.


Followup 2

Download message
Date: Fri, 18 Jan 2013 10:50:10 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Hallvard B Furuseth <openldap-its@OpenLDAP.org>
Subject: Re: (ITS#7495) access filter not correctly validated if assertion
 attribute not requested
This is a cryptographically signed message in MIME format.

--------------ms090800020408080308010509
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hallvard B Furuseth wrote:
> Cannot reproduce on RedHat Linux, x86_64.  But then, the info was
> rather brief. (E.g. which backend? Was that a per-backend or global
> ACL? Might some overlays or other access statements interefere?)
>=20
> Anyway, please provide a complete config and preferably LDIF which
> demonstrates the problem.

Thanks for looking it this.

As usual this is a more complex customer setup with many ACLs and several=

overlays. I tried to provide a simple example but I also see that this do=
es
not show the issue on my local machine.

I will try to strip down the complex config. But this will take a while.

Ciao, Michael.



--------------ms090800020408080308010509
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC
BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG
EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD
ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM
MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF
MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M
VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K
b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/
kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB
1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC
EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0
Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw
QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1
c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/
BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3
LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2
KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj
Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M
MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK
KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B
AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR
GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4
B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ
FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx
QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw
ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF
MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl
ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ
MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV
BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz
IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt
5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z
5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH
hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1
3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst
smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB
BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv
dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p
dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ
dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB
MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E
gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k
ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu
dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy
MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/
Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE
m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV
0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz
UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9
ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X
iF4zKca1vAdAOgw9us90jEtOeiH6G

Message of length 6398 truncated


Reply 2

Resend
From: Hallvard B Furuseth <openldap-its@OpenLDAP.org>
To: michael@stroeder.com
Subject: Re: (ITS#7495) access filter not correctly validated if assertion attribute not requested
Date: Mon Jan 21 14:09:43 2013
Try to put organizationalStatus in olcExtraAttrs aka extra_attrs.
Though ITS#7422 says that does not always work either.

The doc should mention extra_attrs in places like 'filter' in
slapd.access(5), since people who don't read the entire config
manpage may not know to look for this option otherwise.


Followup 3

Download message
Date: Wed, 23 Jan 2013 20:13:12 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#7495) access filter not correctly validated if assertion
 attribute not requested
Using extra_attrs would be a possible work-around (tested).

Unfortunately it seems to trigger a seg fault in slapo-rwm in my setup which
is hard to track down to a certain cause. slapd starts ok but quite soon a seg
fault message is written to syslog. Just before the seg fault I see the usual
search requests of sssd in the logs...

Ciao, Michael.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org