Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Snippets
  • Register
  • Sign in
  • A AWL
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3
    • Issues 3
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DAViCal ProjectDAViCal Project
  • AWL
  • Issues
  • #18
Closed
Open
Issue created Dec 02, 2019 by Andrew Bartlett@abartlet

[SECURITY] LSIDLogin() is insecure and can allow user impersonation

LSIDLogin() has this header:

* This is all horribly insecure, but its hard not to be.

However it excels at that more than could ever be imagined.

If, say when LDAP authentication is used, and for new users, the usr->password is known (eg "" or *), then the validation used for the lsid cookie can be spoofed.

The reason is that

      list( $x, $salt, $y) = explode('*', $validation_string);
      $my_validation = session_salted_md5($usr->user_no . $usr->username . $usr->password, $salt);

contains only known or easily guessed inputs for this case. This is the case for user_no, as this is a simple number and DaviCal (for example) displays it in an internal page. Usernames are easily guessed and are likewise known to other users.

The salt should provide the security, but is is selected by the user, so the user can simply choose any value when computing their attack.

Finally, the whole design of the lsid cookie is flawed, there is no way to time out sessions, they last forever. This means that the logout relies on the browser being honest and destroying the cookie, there is no way to invalidate a cookie once issued, other than to change the password. Therefore if the cookie is stolen (eg JS XSS attack etc) then it can be re-used forever.

The fix should be to cut LSIDLogin() down to a no-op.

I'm more than happy to provide further explanation and to move this to a more appropriate forum if there is one.

Assignee
Assign to
Time tracking