Glad I could be of use.
Benjamin Coddington wrote:
> 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.
>> 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
>>> 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,
>>> 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.