1. 25
  1.  

  2. 8

    When the second malicious commit was made under my own name, I reviewed the logs of our gitolite installation, in order to determine which account was actually used to perform the push. However, while all adjacent commits were accounted for, no git-receive-pack entries for the two malicious commits were present, which means that these two commits bypassed the gitolite infrastructure entirely. This was interpreted as likely evidence of a server compromise.

    This to me reads like a very good defense of git-receive transparency logs. It would make it any malicious pushes towards the repository tamper evident, along with any omissions, with who, when and where. I don’t know if anyone else has deployed it yet but kernel.org has done so for their repositories.

    https://korg.docs.kernel.org/gitolite/transparency-log.html

    https://git.kernel.org/pub/scm/infra/transparency-logs/gitolite/git/

    I have some intentions to try do the same when Arch Linux moves from svn to git in the future.

    1. 6

      The implementation has been moved towards using parameterized queries, to be more confident that SQL injections cannot occur.

      I find it sad that this is done only now…

      1. 4

        Assuming they did properly quote the values before inserting them into the SQL string (a big assumption), I find it actually much sadder they were apparently running on an outdated OS and PHP version and not using proper password hashing.

        1. 3

          A lot of PHP’s infra are made of quite old applications before best practice was as common as it should be. People were too busy and no one was sponsoring the boring work of keeping these kinds of things up to date.

        2. 4

          The master.php.net system, which is used for authentication and various management tasks, was running very old code on a very old operating system / PHP version Previously, passwords were stored in a format compatible with HTTP Digest authentication (essentially a plain md5 hash),

          Whelp that tells a lot already.

          1. 3

            While we don’t have any specific evidence for this, a possible explanation is that the user database of master.php.net has been leaked, although it is unclear why the attacker would need to guess usernames in that case.

            To me, guessing usernames is an indication for some kind of credential stuffing.