8 ms·

He should have sat on the password. He should have watched for PRs, and started pushing updates immediately after they had received approval, and then merging.

He should have sat on the password. He should have watched for PRs, and started pushing updates immediately after they had received approval, and then merging. Instead, he panicked and kicked out all the maintainers, who realized the intrusion only 10 minutes after he gained access. And all he did was add `rm -rf /*` to build scripts, and the N word to the readme. The malicious commits: https://github.com/gentoo/gentoo/commit/e6db0eb4 https://github.com/gentoo/gentoo/commit/e6db0eb4 https://github.com/gentoo/gentoo/commit/afcdc03b https://github.com/gentoo/gentoo/commit/afcdc03b https://github.com/gentoo/gentoo/commit/49464b73 https://github.com/gentoo/gentoo/commit/49464b73 https://github.com/gentoo/gentoo/commit/fdd8da2e https://github.com/gentoo/gentoo/commit/fdd8da2e https://github.com/gentoo/gentoo/commit/e6db0eb4 https://github.com/gentoo/gentoo/commit/e6db0eb4 https://github.com/gentoo/gentoo/commit/c46d8bbf https://github.com/gentoo/gentoo/commit/c46d8bbf https://github.com/gentoo/gentoo/commit/50e3544d https://github.com/gentoo/gentoo/commit/50e3544d

noobermin 8y ago
He was likely not a person trying to do serious damage more than trying to have fun.
- justinclift 8y ago
  Putting "rm -rf /*" in every ebuild seems like a pretty clear indication of malicious intent. Can't really picture anyone doing that as a "just trying to have fun" thing.
  - giancarlostoro 8y ago
    forgot --no-preserve-root for it to really take effect properly.
    - ryan-c 8y ago
      I believe rm -rf /* will work without --no-preserve-root
      - IntelMiner 8y ago
        GNU rm I believe requires the --no-preserve-root flag these days, to prevent that command from happening by accident
        justinsaccount 8y ago
        The shell expands /* , not rm. It expands to /bin /etc /lib and such and is not covered by the sanity check.
  - Buge 8y ago
    Yes, but malicious intent for the purpose of having fun watching the reaction. Not malicious intent for the purpose of personal gain, long term access, or government intelligence.
    - Stratoscope 8y ago
      Having "fun" by ruining quite a few people's day. Malicious is malicious.
      - AlfeG 8y ago
        Looks like a student joke. I just dont know how many files were deleted in such a jokes during education )
    - ISL 8y ago
      It's the sort of "fun" that can land the malicious actor in prison.
      - emn13 8y ago
        Almost anything can land you in prison for years, nowadays. But that doesn't mean there's no difference in impact. Gentoo can count themselves as extraordinarily lucky precisely because there is a difference, between getting hit by a troll rather than a white-collar criminal.
    - dalore 8y ago
      So chaotic neutral? If going by DnD.
      - justinclift 8y ago
        More chaotic evil. Personally I'm pretty close to chaotic neutral - varies over time, sometimes true neutral, sometimes chaotic good - and just outright attempting destruction of unknown third parties seems pretty far towards the "evil" side of things.
fpgaminer 8y ago
I don't think it's appropriate to give advice to bad actors. Certainly everyone should be aware that silent attacks can and do occur. However it seems like a bad idea to post on a public forum ideas for how to better inflict damage.
- sbarre 8y ago
  Security through obscurity never works. We should all be talking about the worst things that can be done, so we can make sure we are protected from them.
  - pps43 8y ago
    Good security should not depend on obscurity, but it does not mean that security through obscurity never works. It's still better than complete transparency.
    - craftyguy 8y ago
      > It's still better than complete transparency. I consider it worse, since it's too easy for people to become content with it.
      - zrm 8y ago
        > I consider it worse, since it's too easy for people to become content with it. It's not just that. For a given vulnerability, there is an amount of time before the good guys discover it and fix it, and an amount of time before the bad guys discover it and exploit it. Obscurity makes both times longer. In the case where the good guys discover the vulnerability first, there is no real difference. In theory it gives the good guys a little longer to devise a fix, but the time required to develop a patch is typically much shorter than the time required for someone else to discover the vulnerability, so this isn't buying you much of anything. In the case where the bad guys discover the vulnerability first, it lengthens the time before the good guys discover it and gives the bad guys more time to exploit it. That is a serious drawback. Where obscurity has the potential to redeem itself is where it makes the vulnerability sufficiently hard to discover that no one ever discovers it, which eliminates the window in which the bad guys have it and the good guys don't. What this means is that obscurity is net-negative for systems that need to defend against strong attackers, i.e. anything in widespread use or protecting a valuable target, because attackers will find the vulnerability regardless and then have more time to exploit it. In theory there is a point at which it may help to defend something that hardly anybody wants to attack, but then you quickly run into the other end of that range where you're so uninteresting that nobody bothers to attack you even if finding your vulnerabilities is relatively easy. The range where obscurity isn't net-negative is sufficiently narrow that the general advice should be don't bother.
Buetol 8y ago
Forcing any commit to be a PR merged by another dev would have solved it
- rich-and-poor 8y ago
  Do you know of any companies that do that? That seems like a big hassle.
  - rdnetto 8y ago
    This is standard practice where I work due to SOX compliance. (No pushing directly to master, all PRs need at least one other person's approval). In practice it's not an issue, since PRs are good practice anyway.
    - rich-w-big-ego 8y ago
      Yes but you can push to PRs after approval and then merge them.
      - dewey 8y ago
        You could revoke push permissions on that branch after the PR is requested though - there are probably tools that do that already.
  - kace91 8y ago
    For mine every feat/fix/refactor is a new branch which then requires 2 approvals to get merged, among other things (style guide enforced as linting, minimum test coverage threshold, etc ). Tbh it's cool, coming from a previous job at a startup where version control meant just zipping the project from time to time.
    - jimwalsh 8y ago
      This is what happens where I work as well.

noobermin 8y ago

He was likely not a person trying to do serious damage more than trying to have fun.

justinclift 8y ago
Putting "rm -rf /*" in every ebuild seems like a pretty clear indication of malicious intent. Can't really picture anyone doing that as a "just trying to have fun" thing.
- giancarlostoro 8y ago
  forgot --no-preserve-root for it to really take effect properly.
  - ryan-c 8y ago
    I believe rm -rf /* will work without --no-preserve-root
    - IntelMiner 8y ago
      GNU rm I believe requires the --no-preserve-root flag these days, to prevent that command from happening by accident
      - justinsaccount 8y ago
        The shell expands /* , not rm. It expands to /bin /etc /lib and such and is not covered by the sanity check.
- Buge 8y ago
  Yes, but malicious intent for the purpose of having fun watching the reaction. Not malicious intent for the purpose of personal gain, long term access, or government intelligence.
  - Stratoscope 8y ago
    Having "fun" by ruining quite a few people's day. Malicious is malicious.
    - AlfeG 8y ago
      Looks like a student joke. I just dont know how many files were deleted in such a jokes during education )
  - ISL 8y ago
    It's the sort of "fun" that can land the malicious actor in prison.
    - emn13 8y ago
      Almost anything can land you in prison for years, nowadays. But that doesn't mean there's no difference in impact. Gentoo can count themselves as extraordinarily lucky precisely because there is a difference, between getting hit by a troll rather than a white-collar criminal.
  - dalore 8y ago
    So chaotic neutral? If going by DnD.
    - justinclift 8y ago
      More chaotic evil. Personally I'm pretty close to chaotic neutral - varies over time, sometimes true neutral, sometimes chaotic good - and just outright attempting destruction of unknown third parties seems pretty far towards the "evil" side of things.

fpgaminer 8y ago

I don't think it's appropriate to give advice to bad actors. Certainly everyone should be aware that silent attacks can and do occur. However it seems like a bad idea to post on a public forum ideas for how to better inflict damage.

sbarre 8y ago
Security through obscurity never works. We should all be talking about the worst things that can be done, so we can make sure we are protected from them.
- pps43 8y ago
  Good security should not depend on obscurity, but it does not mean that security through obscurity never works. It's still better than complete transparency.
  - craftyguy 8y ago
    > It's still better than complete transparency. I consider it worse, since it's too easy for people to become content with it.
    - zrm 8y ago
      > I consider it worse, since it's too easy for people to become content with it. It's not just that. For a given vulnerability, there is an amount of time before the good guys discover it and fix it, and an amount of time before the bad guys discover it and exploit it. Obscurity makes both times longer. In the case where the good guys discover the vulnerability first, there is no real difference. In theory it gives the good guys a little longer to devise a fix, but the time required to develop a patch is typically much shorter than the time required for someone else to discover the vulnerability, so this isn't buying you much of anything. In the case where the bad guys discover the vulnerability first, it lengthens the time before the good guys discover it and gives the bad guys more time to exploit it. That is a serious drawback. Where obscurity has the potential to redeem itself is where it makes the vulnerability sufficiently hard to discover that no one ever discovers it, which eliminates the window in which the bad guys have it and the good guys don't. What this means is that obscurity is net-negative for systems that need to defend against strong attackers, i.e. anything in widespread use or protecting a valuable target, because attackers will find the vulnerability regardless and then have more time to exploit it. In theory there is a point at which it may help to defend something that hardly anybody wants to attack, but then you quickly run into the other end of that range where you're so uninteresting that nobody bothers to attack you even if finding your vulnerabilities is relatively easy. The range where obscurity isn't net-negative is sufficiently narrow that the general advice should be don't bother.

Buetol 8y ago

Forcing any commit to be a PR merged by another dev would have solved it

rich-and-poor 8y ago
Do you know of any companies that do that? That seems like a big hassle.
- rdnetto 8y ago
  This is standard practice where I work due to SOX compliance. (No pushing directly to master, all PRs need at least one other person's approval). In practice it's not an issue, since PRs are good practice anyway.
  - rich-w-big-ego 8y ago
    Yes but you can push to PRs after approval and then merge them.
    - dewey 8y ago
      You could revoke push permissions on that branch after the PR is requested though - there are probably tools that do that already.
- kace91 8y ago
  For mine every feat/fix/refactor is a new branch which then requires 2 approvals to get merged, among other things (style guide enforced as linting, minimum test coverage threshold, etc ). Tbh it's cool, coming from a previous job at a startup where version control meant just zipping the project from time to time.
  - jimwalsh 8y ago
    This is what happens where I work as well.