SAA has removed a number of attributes from an authenticated user's view 
of their own record in LDAP.  After some discussion, we agree with you 
that users may not be aware they are disclosing this information to any 
system to which they supply their password.

Thanks again for pursuing this issue.


On 9/15/10 12:06 PM, Benjamin Coddington wrote:
> You make a great point about a zoo login, or allowing developers to do
> SASL auth to LDAP from PHP. It's not obvious to the user that they may
> be exposing this information on those systems.
> I think it is possible to remove that information from view. We're going
> to talk about this internally and figure out the best approach. Thanks
> for pointing this out.
> Ben
> On 9/15/10 10:27 AM, Jacob Beauregard wrote:
>> Benjamin Coddington wrote:
>>> Hi Jacob,
>>> You are absolutely correct that any user-submitted data used for logic
>>> should always be sanitized; if not for security, than at least for
>>> expected behavior.
>> I honestly believe this would be less likely to happen than for
>> someone's personal data to be compromised by leaving a shell open. I
>> would still advocate it as a good practice though.
>>> However, I do not think that LDAP filter injection presents a security
>>> risk here at UVM since we do not expose password attributes, nor do we
>>> store keys in LDAP.
>> Particularly what I was thinking of is if a query is naively bound to an
>> account, perhaps for a multi-user interface, then personal information
>> related to that specific, bound account can be compromised using
>> injection.
>> SSN via PeopleSoft and SI data
>> Personal contact info (home address, phone)
>> Class schedule
>> Also, for my entry, there's a hash in a field called userPassword.
>>> Also, if the query is bound to a particular user's account, it may
>>> only be so if that user has supplied their credential. Any information
>>> available is already granted to that user, and an injection would not
>>> gain additional information.
>>> These security constraints exist in LDAP. We try to design UVM systems
>>> to make sure that poor programming against LDAP or SQL..(etc) doesn't
>>> jeopardize the information outside that programmer's domain.
>>> I'd like very much to be shown where we are wrong about this. Feel
>>> free to show us a functioning vulnerability. I'll be very pleased to
>>> be shown to be wrong, and SAA will be pleased to improve the security
>>> of our systems.
>> I doubt many people would worry about their identity being stolen
>> because they left a Zoo shell open because they're simply not aware of
>> that possibility. The directory page gives you a big fat warning, though
>> I don't know whether it's on every page that leads to accessing that
>> information. Meanwhile, the Zoo shell doesn't give you any warning that
>> people can grab a boatload of your personal information fast just by
>> typing ldapsearch uid=`whoami`
>>> My purpose here is not to discredit the seriousness of injection
>>> attacks. Rather, I'd like to publicly state my own feeling about the
>>> risk this presents to UVM's LDAP security -- that the risk is rather
>>> small -- in order to combat the risk that FUD could creep into this
>>> great IT community at UVM.
>> Yes, very small for injection, but there are also other kinds of risk
>> just by the nature of the data accessible to the user.
>>> Ben