You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This query identifies cases in which a LDAP connection doesn't use a secure (TLS) channel.
Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing
Result(s)
Provide at least one useful result found by your query, on some revision of a real project.
The provided result does not actually get flagged by the query, since it is taking the value from a custom setting that hasn't been established (here) (The query itself works since quick eval'ing the sink works). How should this kind of situations when the parameter may be a remote server be undertaken?
@jorgectf: I'm sorry, I didn't understand your previous comment. Is/was there a vulnerability in debnet/common-framework that this query would find? If so, please could you provide a link to the corresponding fix commit?
@jorgectf: I'm sorry, I didn't understand your previous comment. Is/was there a vulnerability in debnet/common-framework that this query would find? If so, please could you provide a link to the corresponding fix commit?
Hi Kevin, thanks for your reply.
The project doesn't get flagged by default as the LDAP host is defined here and so I haven't reported the finding.
A secure connection would use ldaps:// or call start_tls(). Since there's no call to start_tls(), this project can be used to test the sink of the query, as most of the projects out there use a custom setting (like the mentioned repo) to set the LDAP host. That's the main point of my previous comment; should this query flag empty LDAP hosts without a start_tls() (or alike) call? Feel free to post a comment on the query PR.
Activity
jorgectf commentedon Mar 18, 2021
The provided result does not actually get flagged by the query, since it is taking the value from a custom setting that hasn't been established (here) (The query itself works since quick eval'ing the sink works). How should this kind of situations when the parameter may be a remote server be undertaken?
ghsecuritylab commentedon May 25, 2021
Your submission is now in status SecLab review.
For information, the evaluation workflow is the following:
SecLab review > FP Check > CodeQL review > SecLab finalize > Pay > Closed
kevinbackhouse commentedon Jun 22, 2021
@jorgectf: I'm sorry, I didn't understand your previous comment. Is/was there a vulnerability in debnet/common-framework that this query would find? If so, please could you provide a link to the corresponding fix commit?
ghsecuritylab commentedon Jun 22, 2021
Your submission is now in status Generate Query Results.
For information, the evaluation workflow is the following:
SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed
jorgectf commentedon Jun 22, 2021
Hi Kevin, thanks for your reply.
The project doesn't get flagged by default as the LDAP host is defined here and so I haven't reported the finding.
A secure connection would use
ldaps://or callstart_tls(). Since there's no call tostart_tls(), this project can be used to test the sink of the query, as most of the projects out there use a custom setting (like the mentioned repo) to set the LDAP host. That's the main point of my previous comment; should this query flag empty LDAP hosts without astart_tls()(or alike) call? Feel free to post a comment on the query PR.However, as mentioned in the PR, I've rewritten the previous LDAP modeling in github/codeql#5444, so I'd like to wait until the last PR gets reviewed, merged and will port this query to
ApiGraphsand make it coverldap2as well.Could we put this submission on hold until github/codeql#5444 gets merged and github/codeql#5445 rewritten?
Thanks for your time.
kevinbackhouse commentedon Jun 22, 2021
@jorgectf: No problem. Just @ me when you have made more progress and I'll take another look.
jorgectf commentedon Jun 22, 2021
Thanks @kevinbackhouse!
jorgectf commentedon Jul 22, 2021
github/codeql#5445 (comment) @kevinbackhouse I've just rewritten the query :)
ghsecuritylab commentedon Aug 26, 2021
Your submission is now in status FP Check.
For information, the evaluation workflow is the following:
SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed
ghsecuritylab commentedon Aug 26, 2021
Your submission is now in status CodeQL review.
For information, the evaluation workflow is the following:
SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed
ghsecuritylab commentedon Sep 23, 2021
Your submission is now in status SecLab finalize.
For information, the evaluation workflow is the following:
SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed
ghsecuritylab commentedon Sep 23, 2021
Your submission is now in status Pay.
For information, the evaluation workflow is the following:
SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed
xcorail commentedon Sep 23, 2021
Created Hackerone report 1350076 for bounty 337293 : [321] [Python] CWE-522: Insecure LDAP Authentication
ghsecuritylab commentedon Sep 23, 2021
Your submission is now in status Closed.
For information, the evaluation workflow is the following:
SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed
jorgectf commentedon Sep 24, 2021
Thank you @kevinbackhouse @xcorail 🙏